Awesome, this is exactly what I was looking for. Thank you!
Zzombiekitty527
- a day ago
- Joined 7 days ago
Since switching to Graphene and starting research on Android development, I've come to realize that very few Android apps are audited for their network activity. This is bad for everyone, although fortunately Graphene OS provides a toggle for blocking network traffic. As a security hobbyist Id also like to look under the hood a bit more.
I want to make a daemon (or call a preexisting one) to monitor this traffic and get it sent to logs. This daemon would ideally be able to intercept incoming network traffic before sending data back to the requestor. I was wondering anyone had any insight on Android's native daemons, and how I could go about accomplishing this.
de0u I'm trying to get an eng build because of its extra leniency when dealing with certain things and dlkm. I want to port NetHunter to the Pixel 8a (I already have a working build) but ran into issues while flashing the new eng build. I'm open sourcing my work as well, once it's done.
If the goal is to flash an up-to-date GrapheneOS with an old bootloader, that might be the source of the problem. I believe that every now and then a new OS release requires a new bootloader release.
This is what I'm trying to figure out right now. It's true that an OS needs a new bootloader every once in a while, but is there difference between 'user' (for production builds) and 'eng' (for debug builds) bootloaders for the same release of Android? I know that my bootloader is the same because fastboot 'flashall' is designed to check if it's the correct version when flashing a new OS. Apparently 'flashall' is designed to make sure everything is compatible, but I still keep seeing bootloops, despite fastboot not throwing any critical errors. I have the correct bootloader for the 'user' release of the same Android version.
de0u Well, to be honest I tried to ask this in off-topic at first lol. But everything comes from the Graphene OS build guide up until that point. For the flashing part, I used this official documentation: https://source.android.com/docs/setup/test/running.
Quite honestly, this documentation is almost useless because it only talks about fastboot flashall -w. Since this failed for me, I was experimenting with different partitions like this https://source.android.com/docs/core/tests/vts/vts-on-gsi. Which is how I got the root adb shell on a user build.
I figure that this might by no man's territory. But if there's someone out there who can help me or point me towards some improved fastboot documentation, it would be helpful. I really want to avoid flashing the new bootloader unless necessary; I've bricked an old phone in the past doing this through trial and tribulation. I'm no stranger to fastboot and the bootloader, but the situation seems unique with Pixel series and the new A/B slots - a lot has changed since the Nexus days. I noticed my bootloader says things like 'secure-boot PRODUCTION' and 'nos-producetion: yes', I'm not sure if this would prevent me from running a non-production debug/eng build.
I only know I can get back to stock with Android Flashtool or the web installer as long as I don't mess with the bootloader. In general I've been leaving that alone. Worst case scenario, I think I can flash the 'eng' bootloader to the other slot and test it first without bricking my phone.
de0u The lunch command was akita-cur-eng while inside the repo for 2025032500 by the way (I forgot to mention). Some of the images are working if I flash them individually with the stable images on grapheneos.org (for example the recovery).
- Edited
@de0u No problem, here's a more precise description of what's happening:
I Installed 2025032500 update for Pixel 8a. Unlocked bootloader and rebooted to fastboot.
ran "fastboot flashall -w" in fastboot. Everything flashes successfully (see the logs below)
$ fastboot flashall -w -------------------------------------------- Bootloader Version...: akita-15.2-12862154 Baseband Version.....: g5300o-241205-250127-B-12973597 Serial Number........: 46011JEKB00414 -------------------------------------------- Checking 'product' OKAY [ 0.000s] Checking 'version-bootloader' OKAY [ 0.000s] Checking 'version-baseband' OKAY [ 0.001s] Setting current slot to 'a' OKAY [ 0.105s] [liblp] Partition system_a will resize from 0 bytes to 1492357120 bytes [liblp] Partition system_dlkm_a will resize from 0 bytes to 11038720 bytes [liblp] Partition system_ext_a will resize from 0 bytes to 510648320 bytes [liblp] Partition product_a will resize from 0 bytes to 763224064 bytes [liblp] Partition vendor_a will resize from 0 bytes to 756035584 bytes [liblp] Partition vendor_dlkm_a will resize from 0 bytes to 26292224 bytes Sending 'boot_a' (65536 KB) OKAY [ 1.377s] Writing 'boot_a' OKAY [ 0.275s] Sending 'init_boot_a' (8192 KB) OKAY [ 0.173s] Writing 'init_boot_a' OKAY [ 0.037s] Sending 'dtbo_a' (16384 KB) OKAY [ 0.346s] Writing 'dtbo_a' OKAY [ 0.062s] Sending 'vendor_kernel_boot_a' (65536 KB) OKAY [ 1.433s] Writing 'vendor_kernel_boot_a' OKAY [ 0.267s] Sending 'pvmfw_a' (1024 KB) OKAY [ 0.024s] Writing 'pvmfw_a' OKAY [ 0.012s] Sending 'vendor_boot_a' (65536 KB) OKAY [ 1.401s] Writing 'vendor_boot_a' OKAY [ 0.263s] Sending 'vbmeta_a' (8 KB) OKAY [ 0.001s] Writing 'vbmeta_a' OKAY [ 0.007s] Erasing 'userdata' OKAY [ 0.142s] Erase successful, but not automatically formatting. File system type raw not supported. Erasing 'metadata' OKAY [ 0.014s] Erase successful, but not automatically formatting. File system type raw not supported. Sending sparse 'super' 1/14 (254972 KB) OKAY [ 5.485s] Writing 'super' OKAY [ 0.986s] Sending sparse 'super' 2/14 (254972 KB) OKAY [ 5.443s] Writing 'super' OKAY [ 0.953s] Sending sparse 'super' 3/14 (254972 KB) OKAY [ 5.421s] Writing 'super' OKAY [ 0.929s] Sending sparse 'super' 4/14 (254972 KB) OKAY [ 5.426s] Writing 'super' OKAY [ 0.965s] Sending sparse 'super' 5/14 (254972 KB) OKAY [ 5.426s] Writing 'super' OKAY [ 0.940s] Sending sparse 'super' 6/14 (254972 KB) OKAY [ 5.454s] Writing 'super' OKAY [ 0.923s] Sending sparse 'super' 7/14 (254972 KB) OKAY [ 5.428s] Writing 'super' OKAY [ 0.959s] Sending sparse 'super' 8/14 (254972 KB) OKAY [ 5.458s] Writing 'super' OKAY [ 0.937s] Sending sparse 'super' 9/14 (254972 KB) OKAY [ 5.407s] Writing 'super' OKAY [ 0.925s] Sending sparse 'super' 10/14 (254972 KB) OKAY [ 5.400s] Writing 'super' OKAY [ 0.946s] Sending sparse 'super' 11/14 (254972 KB) OKAY [ 5.401s] Writing 'super' OKAY [ 0.924s] Sending sparse 'super' 12/14 (254972 KB) OKAY [ 5.388s] Writing 'super' OKAY [ 0.953s] Sending sparse 'super' 13/14 (254972 KB) OKAY [ 5.397s] Writing 'super' OKAY [ 0.953s] Sending sparse 'super' 14/14 (161564 KB) OKAY [ 3.432s] Writing 'super' OKAY [ 0.611s] Erasing 'userdata' OKAY [ 0.094s] Erase successful, but not automatically formatting. File system type raw not supported. wipe task partition not found: cache Erasing 'metadata' OKAY [ 0.013s] Erase successful, but not automatically formatting. File system type raw not supported. Rebooting OKAY [ 0.000s] Finished. Total time: 93.094s- When the device reboots, I it gets stuck on the Graphene OS boot animation, without loading into the OS. My only option here is to force reboot the phone and completely reflash to a known stable build.
I'm not sure what exactly is causing this, but I highly suspect that something is happening to cause it when I flash the 'super' partition. After the first 'frozen boot screen' I actually tried flashing boot.img, vendor_boot-debug.img, and vbmeta.img seperately and it works totally fine. The vendor_boot-debug.img was kind of interesting, because it gave me root adb shell access on a 'user' build when I didn't have it before (cannot use adb root on production builds). Didn't know this was a thing until now. Anyways, soon as I tried to flash 'system.img' on top of this setup, I started having the same issue that I described in the notes above. I suspect it's either that I'm missing something about properly flashing the super partition (i.e. system partitions), or perhaps my bootloader is not equipped to flash debug builds (with ro.secure = 0). Idk if the bootloader makes any difference, but it's the only other thing I can think of - I used the same bootloader from the 2025032500 stable build because my debug build is based on this version.
I'm having trouble flashing my userdebug build after following the build guide and install guide exactly. Im flashing from the stable branch of 2024032500 to the userdebug version of the same release that I built using the guide. Idk why but after using flashall it automatically reboots and then gets stuck on the Graphene OS boot logo for a long time. Any fixes or ways to debug this? Everything in fastboot seems fine during flashing, but when I boot up the build it takes more than 5 minutes so I had to force restarted back to the bootloader and flash a stock user build. Still tryna flash this other build, idk why it's not working.