▲ 146 points
back
24 comments
Just reading this post was a lot of work. I can't imagine how these people find the time and patience to work this out from scratch.
Its also a show of how incredibly complex phones are where just the nfc chip has its own bootloader and firmware and update protocol.
Some patience is required, yes. But mostly you're driven by the challenge itself. There is a beauty in working with raw bytes. No worrying about maintainability or code reuse, no layers of abstraction - just finding the right combination that solves the problem. Abstraction comes later as you understand the space and see the patterns.
And yeah, seemingly every modern chip has ended up with its own ARM processor with some undocumented firmware blob, to provide its "hardware" functions. Better than bespoke state machines, I guess.
One of the ways the S3 (and I think S4) can self-brick is that the flash controller table gets corrupt, so its firmware goes into a boot loop (making the flash chip disappear to the main processor). Someone did a similar reverse engineering trek to unbrick S3s that have fallen victim to this bug. I just wish the chip registers were documented in the datasheet, and the firmware more open. I've got a bricked S4 with some concert pics that I'll get around to hacking on some day...
> As I had replicated this vulnerability, I disclosed it to Samsung, as it was likely they would want to remediate it. Remediation was performed by them on all newly manufactured chips, as well as chips currently in development, as of April 2020
facepalm. The NFC chip firmware integrity is assured by it being loaded from the application processor. Signature schemes that prevent users from running their own code on devices they own are unjust, and you're doing nobody any favors by reporting bugs in them (apart from the power-hungry manufacturers pushing this junk). The author has basically obsoleted their own code on future models.
The concept of professional release has been used against consumers so often I wonder why people still do it.
I've always wondered this as well. Often times I wouldn't even know where to start investigating things like this.
The biggest issue I run into when investigating something like this is the community centric lingo. Go over to any one of the forums around a specific topic - you'll spend days just attempting to figure the language. I'm still attempting to decipher all the android rooting/flashing terms the community uses over on the XDA forum.
Which Android phones can safely be rooted these days, if any?
Everytime one of my friends says they rooted their phone, I ask them how. And the answer is always "I was on some website, downloaded some binary and executed it". So as I understand it, they make themselfes completely vurnurable to somebody from the internet who made that root binary.
The rooting process is actually very standardized. On most of the phones you just have to patch a su manager tool called Magisk[1]. Its open-source and been under a lot of eyes.Also the dev works at apple and is a community favorite.
Custom roms are a lot more risky, there are 100s of different flavors made by relatively unknown developers and even though they are technically open source, I find it highly unlikely that none of them contain malware. I mean you can introduce a memory corruption bug in few handful characters, these custom roms are practically unauditable.
> Custom roms are a lot more risky, there are 100s of different flavors made by relatively unknown developers and even though they are technically open source, I find it highly unlikely that none of them contain malware. I mean you can introduce a memory corruption bug in less than few characters, these custom roms are practically unauditable.
Depending on your phone and threat model, it's not obvious that this is worse than the alternative. Given that there have been phone manufacturers that outright shipped malware, and most phones stop getting security patches after a few months and then steadily accrue CVEs, it may be better to chance a 3rd-party ROM.
A number of phones have official support for LineageOS (popular FOSS custom OS very close to stock FOSS Android), in which case installing the OS is a simple and straightforward process with no extra binaries required except those published by the LineageOS project. It's very common to also use the TWRP recovery but actually the process is a bit easier with the official LOS recovery.
After that root is provided with Magisk, which is also open source. And you could also install the Google software package if you want at this stage to get Play Store / etc.
Plus, with LOS you get guaranteed security & version updates for Android for years and years and years. Unfortunately firmware blobs for the hardware are provided by the OEM, and while LOS tries to keep them updated sometimes they are a bit old, and updates for those will eventually end when the OEM stops providing updates.
Echoing sibling comment: AFAIK, all Motorola Moto series phones officially support unlocking the bootloader (with a minor dance to register and get an unlock code from Motorola), which you do with adb, after which you just use adb/fastboot to rewrite recovery (or just directly boot an alternate recovery, which you can do without flashing it) and then you can flash a custom ROM and/or Magisk, the rooting solution of choice.
My Motorola MotoZ has a process that involves loading some token generated from motorolas site using the standard ADB tools.
If you intent to purchase a phone for the purpose of installing custom rom on it, you might want to get a phone with a snapdragon chip. Other chips such as mediatek often has increased risk of bricking when you mess something up, and thus not many rom developers are willing to tinker with those phones, which means less variety of custom roms available for those phone models.
Almost all of them. The code for actually unlocking the bootloader is generally open or at least described, and you basically just need to flash TWRP then Magisk which you can both compile.
To my recollection, those three phones (Well, there are multiple SKU's) have the ability to emulate magnetic stripe cards as well, in order to use Samsung Pay on older terminals without contact-less payments.
Samsung calls it "Magnetic Secure Transmission" as I recall. I wish they would advertise it more because it was honestly the greatest feature on that phone in my eyes, but everyone assumes it's exactly the same as Apple Pay. Retailers were shocked every time I used it (though in some cases they refused to even let me try).
I'm personally glad to be off Samsung products again now, but I was really disappointed when my spouse switched to a model without MST.
There's a wiki page:
https://en.wikipedia.org/wiki/Magnetic_secure_transmission
And it seems LG has a similar technology they call Wireless Magnetic Communication (WMC).
Yep, this was the technology they acquired with LoopPay.
and they quit including it in the samsung watches :-(
This is an incredible deep dive. I’ve had the fortune of seeing some of the people from pentest partners at a talk at my university, and it was one of the most interesting talks of my degree. I wish more people outside the security community played with all levels of the stack a bit more. It’s incredible to see what people can come up with.
There has never been a better time to dive into embedded development! The tools are cheap and easy to get a hold of and the amount of learning resources available is mind boggling. Poking around at the hardware level is neither difficult nor expensive, and you can get started at your desk with any of the zillion Arduino-style kits out there. You can leverage your existing development skills in the physical realm and it's all kinds of fun!
This is masterful work. I love the move from the now well understood s6 to the s9 in blind fashion.
I just can't believe how dumb it was to put a memory read command into the older NFC chip! Maybe nobody thought about security back then?
Well beyond my level and like the hacking of network protocol of video cam here, learn a lot. One minor thing to note is how c code is still ruled here as expected in embedded space.
And one annoying thing is how some of the constant like 4 and size of (which some is 4) is used Interchangably. Also some init of the Array has data but actually is a read into Array. Just to confuse reader ?
One of the claims is that whilst iphone and most Android were hacked if one paid, pixel is safe. True ?
This is such an amazing write-up. Thank you for all your work and for taking the time to document this.