d4
Luxferre
d451865ead7381ba902a27a34a2f8587b3a08b60fe3f10f8fbf33745241ecc8b
Yes, that one. A voice from outside the echo chambers. If you like my projects and ideas you can donate me with Monero (XMR): 86neopbgniu1bQ4EXL7oU6V6nFQE8VGebBpNbUVHWzPuFG1LH2Ca84eHFkqgNnEkC7ERrf4uXV2PXeMGREKXPYrb8qBFjzR

Hmm. The devinfo partition does indeed store both Pixel 6 IMEIs in plain ASCII. They can be found after "imei1" string and zero byte and after "imei2" string and zero byte respectively. Patching any of them in the devinfo image, regardless of whether or not /mnt/vendor/efs/nv_protected* files are deleted afterwards, causes the device to report both IMEIs as 000000000000000 to both the OS and the network (which shows "Unknown Unknown" in place of the phone model in the carrier's account page). Other places to properly patch the IMEIs in addition to the devinfo partition are still being researched.

The journey is still far from the end, but, according to some "experts" from the #GrapheneOS forum, even this couldn't be possible because, you know, ReGuLaTiOnS.

Did you know that POSIX standard specifies offset display support for "strings" utility? https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/strings.html

Very useful for pure-shell-based patching of some text in binaries (in combination with dd, of course)

OK, temporary IMEIs working. Not every time (those damn AT command timeouts or whatever) but I did see another model on my carrier's page. #GrapheneOS spokespeople were wrong, and it's just the beginning of my quest.

The Graphene Saga: part 1 https://hoi.st/posts/2024-03-11-the-graphene-saga-part-1.txt

Ok, I might have found at least something regarding IMEI editing in Pixel 6.

The most interesting part is that I **had to** use my carrier's personal account page to verify the change is successful (by viewing which phone model the carrier detects), because whatever is displayed at `*#06#` or `*#*#info#*#*` does not change with this hack. So my method is going to only change whatever the network sees. Exactly the opposite to what those buffoons were stating.

Stay tuned.

Found a nice onion-enabled shell service, finally the one where free limits look reasonable: https://www.thc.org/segfault/

Of course, one can never be fully sure what they are really monitoring, so be careful.

Modern Android's toybox shell has AWK preinstalled. That's pretty good.

Of course, Termux has AWK too, but that's not as interesting as the fact that Exynos 5123 has a third hidden IMEI. Of course it's unused in Pixel 6, but demonstrates a theoretical possibility of putting a second physical SIM slot in addition to the first one and eSIM.

The truth is very close. I hope this Saturday wasn't spent for nothing.

I mean, are they probably afraid that someone is going to have a degoogled AND rooted AND hostile work environment\* ready Android flavour to just enjoy their devices while being in full control of them?

\* I mean an environment enforcing Intune Company Portal and other similar anti-freedom bullshit

I'm not an Android developer. I don't want to become an Android developer. I don't want to know how to build various crap for Android 14, or any Android beyond 6, for that matter. I deeply hate Java and any other similarly square-holed programming languages with long names, tons of boilerplate and mandatory semicolons (the only language that gets a pass for them from me is pure C). I deeply hate any XML-based build systems and all the bloatware around them. It's all a complete mess at this point.

Yet I, instead of trying to relax on the weekend, have to (re)learn all this just to be able to make one FOSS project work on another because the developers of both of them turned out to have an extremely assholian attitude. And then, if/when everything works as expected, I'll also have to spend some time and resources to host my own forked repo (of course it won't be on GitHub or even SourceHut) and the release APK as well. And it will be a one-time effort, I physically won't be able to patch out any further versions anyway.

All this because I want my smartphone to function like a full-featured pocket PC, not like a consumeristic black box. Is this so hard to understand?

The simplest and most reliable way of dropping some short text from PC to Android (as long as they are in the same LAN) is:

1) Run Termux and note your current IP with ifconfig.

2) Run nc -l -p [someport] on the Termux side.

3) Run echo 'yourtext' | nc [android_ip] [thatport] on the PC side.

4) Quit nc on the Termux side and copy whatever you received from the terminal window.

Of course, with longer texts, you can just redirect the output to a file and use cat instead of echo on the PC side. You can also install Termux:API Android package (and termux-api from Termux itself) to leverage termux-clipboard-set command to automate the last step.

Criminal psychopaths have taken over most world's governments, not only yours. The only positive side of this is that more people may start to see how obsolete the concept of a state itself already is.

Patching Magisk to make Zygisk work with current GrapheneOS would be a more constructive move though.

On Pixel 6, I don't need root just for the sake of it. I need it for two specific things: exploring the baseband/EFS and running crosvm. Crosvm is the closest we can have to a Qubes-like experience on such devices as of now. Any excuses that we shouldn't have it "because security" are just pathetic.

Technically, Graphene does let you have root (there is an avbroot approach I shared earlier). But Magisk, on Graphene, doesn't let you have working Zygisk which is required to conceal the fact you're using root from some stupid but necessary apps.

Replying to Luxferre

Now, things are getting even more interesting: https://github.com/topjohnwu/Magisk/pull/7606

Did we really come to this? I mean, really? That's your fight for freedom?

Did we end up in a situation where we, users, have to patch everything out ourselves because the devs can't work together constructively? Whose side are they on?

P.S. No, ZygiskNext doesn't seem to work correctly either with the PIF module either.

* neither with the PIF module nor with PIFnext.