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.

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.

Now, things are getting even more interesting:

GitHub

fix(zygisk): Fix Zygisk on GrapheneOS Android 14 by pixincreate · Pull Request #7606 · topjohnwu/Magisk

The discussions have been done in these places: 2023112600 build of GrapheneOS causes bootloop if Magisk is installed as system server crashes ch...

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.

I should have done this from the beginning:

GitHub

avbroot/README.md at master · chenxiaolong/avbroot

Tool for manipulating and re-signing Android A/B OTAs - chenxiaolong/avbroot

Yes, OTA updates must be patched manually but I'm sure I can create some automation to make it easier.

Ok, my first impression about #GrapheneOS after finally installing it onto a Pixel 6 is a mild disappointment. Yes, it still is much, much better than the stock Android, no doubt about that. Unless you desperately need Google Wallet, I do recommend installing it. However, it has several major problems, and being publicly represented by ignorant buffoons is definitely one of them: > It's not clear why people don't listen to our official responses explaining that changing IMEI does not mean identifiers are not provided to the cellular network and other things we've explained here. Because, despite being official, the responses are plain incorrect, no? They are based on nothing but your assumptions. I, for instance, verify any successful IMEI change methods for any new platform on the carrier's personal account page. If it shows another model (or "Unknown" in case of zeroed-out IMEIs) then it works. Just admit that you're too lazy to find a working way of manipulating Exynos 5123 NVRAM data. It's not a matter of anyone's beliefs. It's not a conspiracy theory. It all can be verified. And we also can see the same exact picture about their responses why they don't support root access. As if the people who need GrapheneOS are just as stupid as those who cling to stock. Yes, rooting comes with a security risk. But at least give an option to those willing to take that risk and in return get full control over their own devices bought with their own money. Users must be protected from manufacturers, not vice versa. What's next, disabling su/sudo in desktop Linux distros "for the greater good"? Screw that. A hardfork is coming if they don't listen to us.

Good lightweight ebook formats must get wider recognition. This is one of them:

AMB - Ancient Machine Book format

The kind of proof I'm looking for is: "Look, here's how we access the radio. Here's the set of AT commands. Here's the NVRAM layout. Here's where the IMEI is stored. Here's what happens when we try to overwrite it. Here's the demonstration that it gets restored from OTP/efuse areas". Then I'll believe it. After I try replicating the same process myself. Until that, the claims are empty.

No, I don't deny the fact the #GrapheneOS devs are really good specialists who know what they're doing. They surely are. But if they truly believe in what they said and don't have a solid base for their claims, then it means they are pretty naive and don't even try to think outside the box. They don't doubt the dogmas imposed by authorities. Yes, existing device certification standards explicitly require that IMEIs must be immutable and resistant to any possible way of tampering. But this just isn't true anymore, they are stored in NVRAM/EFS areas (sometimes encrypted but still rewriteable), they might even be populated in a different place than the factory that actually manufactures that hardware. That's normal OEM process nowadays, nothing crazy. What really happens afterwards (if the certification process even gets to this point, which I suspect it often doesn't, they are usually only interested in proper radio frequency ranges and output power) is that the vendor demonstrates that there's no way to edit those identifiers in the stock production OS config. That's it. So, once again, do GOS devs have a **proof** that it can't be done, or is this just an assumption based on what the Big Brother told them?

I guess the last smartphone where the IMEI was truly uneditable was Nokia 808 PureView. Although I guess some workarounds could be put even there, but again, "security though obscurity" and hardware boxes.

If it can't be done, I need to see a solid proof that it can't be done. "Trust me bro, they won't allow you to do this because regulations" is not a proof.

Looked this up on their forum — not sure if any actual developers responded to the questions but whoever responded there is a bunch of pussies. "Oh, but why would you do this if your IMSI/MSISDN/ICCID are still the same?" "Oh, it's illegal" "Oh, use a Mudi router with a blue-merle opkg to randomize IMEIs" etc. No real answers. But then, I found the official response, and it's quite silly, to put it mildly: > Spoofing the IMEI shown in the OS is not changing the IMEI used for cellular, and is not useful beyond fooling yourself. Changing the IMEI used for cellular is not possible with modern cellular radios, which are required by regulations to prevent changing it. Changing it requires a cellular radio exploit, which would imply not patching the radio or using a device with an insecure cellular radio. Changing the IMEI doesn't provide anonymity. There are multiple other hardware identifiers. What planet do these guys live on? "Changing the IMEI used for cellular is not possible with modern cellular radios, which are required by regulations to prevent changing it"? Really? All big three of baseband vendors (Qualcomm, MediaTek, Unisoc) don't seem to give a fuck about those regulations and rely on "security through obscurity" instead. I doubt that whoever is behind Google Tensor does any different regarding hardware identifiers, as this would increase their production costs. They might, however, place them in some qfuse-like OTP area, I can neither confirm nor deny that as of now. By the way, some carriers do show you which IMEI (or, rather, phone model) they see in their personal cellular account page. You can easily verify who's been fooled in this case. I won't join the #GrapheneOS forum unless I really have to, but whatever they wrote on this topic looks like deliberate or accidental misinformation. The only relief I feel at this point is that if this is an official answer, then there's 90% probability this just was not researched well enough for Tensor-based Pixels. Just give me root and enough time to find out the truth.

Gonna tinker with #GrapheneOS on the weekend, as it surely is better than the stock Pixel's Android, but here's what they say about IMEI editing on the official website: > It is not possible to change the IMEI on a production device and GrapheneOS cannot add support for it since the hardware doesn't support it. Does the hardware really not support it (e.g. IMEI is flashed somewhere in the one-time write area) or is this just not researched well enough?

Three simple text-based steganography ideas: 1. Substituting aeiocx letters with their Cyrillic counterparts if the cover text is Latin-based, and vice versa. Implemented a long time ago in one of my scripts. 2. Encoding message bits in word lengths: 0 if even, 1 if odd. Can be based on simple Markov chains but may need some AI assistance if the cover text is not required to be gibberish. 3. Hashtag-based encoding: e.g. 4 predefined lengths can encode two bits. The message can be encoded in alphabetically sorted hashtags and then they can be shuffled. Also, the word pool can be fully pre-picked manually to match your post topic.

A viable FOSS set for any degoogled Android: - Launcher: KISS Launcher - App sources: F-Droid + FFUpdater + Obtainium - File manager: Amaze - Keyboard: Thumb-Key (unless you have a physical one) - Browsers: Mull/Mulch, Firefox Focus, Tor Browser (all via FFUpdater), Pocket Gopher, Buran - Email client: K-9 Mail - Camera: Open Camera - OTP app: Aegis - CLI environment: Termux - Media players: VLC, Xmp Mod Player, Clipious - Communications: Conversations, aTox, Element, Linphone, Jitsi Meet - Crypto wallets: Unstoppable, Monerujo, Ywallet - Smartwatch interaction: Gadgetbridge, Casio G-Shock Smart Sync - Utils: Orbot, Orientation Faker, Wasted

World's most powerful nation is procrastination.