Breaking Samsung Firmware, or Turning Your S8/S9/S10 into a DIY ?Proxmark?

Many Qualcomm Snapdragon CPUs support this outright, and with root access on a phone one can use the following command to put their device in this mode:On Broadcom chipsets, this can be slightly more complicated, requiring kernel patches and custom firmware blobs, however there is publicly available information about how to pull this off.Many Android-based security tools support this functionality outright, however it is also possible to create your own setup using chrooted environments to utilise these features.On all of my rooted phones I place a Debian-based chroot into the core data partition. Research on this chip and its capabilities online showed that a key feature of it was securely updating the firmware, meaning that there was likely to be a firmware binary somewhere in the filesystem of the phone.I managed to purchase the chips themselves online, however I decided I wanted to do all of my reverse engineering from the phone, and did not end up using them for the project.When you are looking at hardware communication on an Android device, it is pretty much the same as looking at it on any embedded Linux device. In NCI, these functions are most likely to contain interesting or exploitable features, as they have no documented standards.A good example of these are the following commands, utilised by Samsung’s S3FWRN5 to set frequency values for communication.Firmware updates for all NFC chips I have looked at all use their own protocols. IOCTLs for setting mode were identified from the original kernel source.This allowed for assessment of specific functionality including the fact that some command sent subsequent data payloads beyond the original command, as noted with the signature and SHA-1 hashed sent at the start of updates.Firmware updates were found to have a specific sequence, using incrementing numbered commands:These were again confirmed by looking at the kernel source.The construction of this protocol and the sequence used meant that the SHA-1 hash of the firmware was verified at the end of the update process. This was proven, by reading incrementing addresses in memory.Using this command, one could dump the bootloader, firmware, RAM and hardware registers.Stitching memory from address 0x00000000 together incrementally allowed for generating of a binary file containing the bootloader in full, and showed that it was 8KB in size, and followed the same structure as any standard Cortex-M chipset. Initially I attempted to place this value directly in the firmware being sent, however this was not effective.It was easy to stop the code which receives I2C commands, as shown above with commands 0, 1, 2 and 6 being available before firmware updates have been performed.Lastly, the RSA public key was noted, which is easily spotted as a large number of high entropy bytes follows by 0x00010001 (65537) the exponent traditionally used for RSA keys.I wanted to find a memory corruption exploit in this bootloader, so that I could deploy custom firmware. Unlike standard QEMU, which runs as an application, Unicorn allows for emulating via libraries which can be used in C or Python, and allow for hooking each step of the emulation process.Initial setup of Unicorn Engine for my firmware was simple: I mapped all valid memory, loaded my bootloader at address 0x00000000 and set the program counter to the reset vector.The simplicity of this was aided by the fact that the bootloader did not use threads and used an infinite loop for checking I2C commands.There were a few complications however. There were a few opportunities in this, including the usage of 16-bit values for payload sizes, which was larger than the 8KB of RAM available on the chip, and the usage of chunked additional data after commands during updates.The most likely area where I believed there would be the possibility of memory corruption was in the firmware update initialisation function. I found that this allowed increasingly large amounts of data to be sent using this command until eventually the emulated bootloader hit an exception due to memory being out of bounds, accessing memory outside the 8KB of RAM on the chip.This likely meant that I had found a buffer overflow vulnerability, which would allow me to override the stack and manipulate the Link Register values currently stored in it. Eventually, I found a file called “/proc/nfclog” which contained data about when IOCTLs were performed and the sizes of payloads being sent to the chip.With this, I could trace the new firmware update process, which allowed me to note that at the start of firmware updates, the hash chunk being sent was of size 0x24. This means that I would likely hit any Link Register values as soon as possible, and any modified registers were unlikely to cause issues.As I didn’t know where I needed to jump to in the bootloader, because I hadn’t seen it yet, I decided to take a brute-force approach.Starting from 0x0001, the lowest address on the chip, I flooded the stack, and then attempted to execute the firmware as I had in the S3FWRN5. This meant that I could call functions from within functions in my custom C code, allowing me to implement as much functionality as needed, but also more easily gain addresses in the code relative to my custom functions.At its most basic form, this tool compiled my C functions, dumped them into the firmware payload, and overwrote my desired functions.I decided to overwrite a vendor-specific NCI function “2F 24” as I found I could send arbitrary-length parameters to it, and that it didn’t serve any meaningful function on the device that I could see.I searched for where the NCI response may be set up, which started with “4F 24”, I searched using regex in IDA for “MOVS.*#0x24” which took me to one function call, which was definitely the function I needed to modify.Brief analysis showed me that “sub_119BE” sent I2C responses, so I elected to overwrite “sub_11A76”, as this would allow me to modify the response data and disallow anything else from doing so.I wanted to be able to receive parameters, such as addresses for memory reads, but at this stage I had no idea where they would be stored in RAM. I decided to modify it to match the S3FWRN5’s exploit.As I knew I could write custom firmware, I decided to use arbitrary emulation of NFC tags as an initial example of what could be done.The chips support common 13.56MHz protocols, such as ISO14443a and ISO14443b, and in reader mode supported a large number of tag types based on these standards. I then went through them in sequence and removed ones that did not affect the NFC communication.I found that the last command sent was the RF discover command, and that I could modify this to only act as an ISO14443a tag and nothing else.I’d need to learn a lot about the intricacies of the hardware capability of the chip, so started to perform analysis of the firmware I was working with. Using my previous arbitrary read command, I dumped all of the memory in 0x40020000, as this was likely to handle NFC communication on the chip, and each hardware peripheral is addressed individually.Looking at these addresses while the phone was on an NFC reader showed the NFC WUPA (0x52) command, used in enumeration, meaning that this was the right hardware address for communication. This allowed me to know what static memory was accessed and led me to the function which set up these values in the firmware.I overrode this function with my own C function, called it from this newly created function to perform all other hardware setup, and then modified to the SAK, ATQA and UID values as I wanted them.I used the proxmark to read the phone using this custom firmware, and noted that this was successful.Next, I wanted to override the full communication of the chip. Searching for the RATS value as a comparison yielded four results, one of which was the state machine for NFC communication in the firmware.Following this function provided me information about how responses were performed, and allowed me to write C code to perform this for myself.I overrode the state machine so that I could add my own functionality.I implemented a basic read command, done on most Mifare tags using 0x30 as the command value, with a block and then a CRC.