The cover image is a 2.8M png, if the author is reading. I gave up my github account so cannot comment.
Now a ~300kB webp, thanks.
Also, fantastic write-up
61–70 of 181 posts
really like how this blog is written. a lot of writeups like this recently have been generated by an LLM, and it's quite distracting to read - this was a pleasant surprise. it strikes a good balance between technical and laid-back (yes i know the cover image is AI-generated, that's incidental to the content)
It's too bad people spend energy for generating them now.
Earlier quoted context omitted.
So for people with any practical needs what so ever (like banking): No. At this point Android isn’t meaningfully an open-source platform any more and it haven’t been for years. On the somewhat refreshing side, they are no longer being dishonest about it.
I don't think any vendor should be solving for "I want to do app RE and banking on the same device at the same time;" that seems rather foolish. These are sort of orthogonal rants. People view this as some kind of corporate power struggle but in this context, GrapheneOS, for example also doesn't let you do this kind of thing, because it focuses on preserving user security and privacy rather than using your device as…
Earlier quoted context omitted.
Overall: yes, but it will get much harder for apps which need attestation, which is sort of the point, for better or for worse. As far as I know you'll still be able to OEM unlock and root phones where it's always been allowed, like Pixels, but then they'll be marked as unlocked so they'll fail Google attestation. You should also be able to still take an app, unpack it, inject Frida, and sideload it using your _own_…
So for people with any practical needs what so ever (like banking): No. At this point Android isn’t meaningfully an open-source platform any more and it haven’t been for years. On the somewhat refreshing side, they are no longer being dishonest about it.
Firmware which requires updates to be signed with a manufacturer key can still be open source. As long as its code is available publicly, under a license which lets the user create derivative works, it meets the definition. You can still make a version of it that doesn't contain that check, you just can't install that version on the device you bought from the original firmware developer. Some FIDO keys (and I think Bitcoin wallets) do this.
Earlier quoted context omitted.
I don't think any vendor should be solving for "I want to do app RE and banking on the same device at the same time;" that seems rather foolish. These are sort of orthogonal rants. People view this as some kind of corporate power struggle but in this context, GrapheneOS, for example also doesn't let you do this kind of thing, because it focuses on preserving user security and privacy rather than using your device as…
GrapheneOS strongly recommends that you do not do it, but it will not stop you if you want to. You can root and leave your bootloader unlocked or create a custom user signed image with root support included. Plenty of user written guides out there how to do so.
That's Google, not GrapheneOS.
Earlier quoted context omitted.
It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow. This is the way most apps work if they have a default password the user is supposed to change.
The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline w…
Earlier quoted context omitted.
As far as I'm aware it is possible to use Frida without rooting, by using Objection https://github.com/sensepost/objection
> Patch iOS and Android applications, embedding a Frida gadget that can be used with objection or just Frida itself. This is the key thing, and the part that will change next year: previously, you could unpack, patch, and repack an APK with the Frida gadget and install it onto an Android device in Developer mode, while the device remained in a "Production" state (with only Developer mode enabled, and no root). Now, t…
tapo annoyingly is also one of the only cameras that doesn't have a still snapshot url after all these years and endless requests from many someone needs to make replacement firmware ffmpeg can fake it but takes a few seconds to grab from the video stream and of course you can't run ffmpeg from your browser (or wait, can you now?) ffmpeg -rtsp_transport tcp -i "rtsp://cameraname:camerapass@192.168.1.23:554/stream1" -…
Earlier quoted context omitted.
It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow. This is the way most apps work if they have a default password the user is supposed to change.
The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline w…
It is better than simple secret like 12345678 but it can go wrong too, like in the case of UPC UBEE routers where the list of potential passwords can be narrowed down to like ~60 possibilities using a googled generator [1] whilst knowing only the SSID.
It did require firmware reverse engineering to figure out [2][3] but applies to most devices I've encountered. User should ideally always change the default password regardless.
[1] https://upcwifikeys.com/UPC1236567
[2] https://deadcode.me/blog/2016/07/01/UPC-UBEE-EVW3226-WPA2-Re...
[3] https://web.archive.org/web/20161127232750/http://haxx.in/up...
Earlier quoted context omitted.
Overall: yes, but it will get much harder for apps which need attestation, which is sort of the point, for better or for worse. As far as I know you'll still be able to OEM unlock and root phones where it's always been allowed, like Pixels, but then they'll be marked as unlocked so they'll fail Google attestation. You should also be able to still take an app, unpack it, inject Frida, and sideload it using your _own_…
So for people with any practical needs what so ever (like banking): No. At this point Android isn’t meaningfully an open-source platform any more and it haven’t been for years. On the somewhat refreshing side, they are no longer being dishonest about it.
If e.g. Slack required attestation that would be a different story. I need that for work.