lcq2.github.io Personal page where to dump sparse knowledge

x86 finds its way into your iPhone

Introduction

In one of my several lives, I’m supposed to be a vulnerability researcher working on baseband exploitation. As every vulnerability researcher knows, being up to date with recent developments is of utmost importance for the success of your job. So of course, after Apple announced its new, shiny, big, bigger and biggest line of iPhone smartphones, I downloaded some OTA firmwares from ipsw.me and started to look into the new baseband firmware.

What I discovered sent a shiver of horror down my spine, the kind of horror that only playing Doom at nighttime, alone in your room, without lights, can produce. Bear with me and I’ll tell you what I found…

NOTE: this is just some preliminary analysis and I’m not going to describe anything related to baseband rerversing, it’s not the scope of this document.

Who/What/Where?

The baseband cpu is a standalone core that lives in your phone and is responsible for managing 2g/3g/4g/cdma/5g wireless communications. Given the absurd complexity of these standards, today a baseband cpu must be very powerful and enough general purpose, so the days of custom FPGA based IPs are long gone, at least for the main part. A lot has been said and written about basebands on modern smartphones, so I won’t repeat it. For our purpose, you just need to know that usually basebands are implemented using embedded friendly CPUs, like for example ARM (Cortex-M, Cortex-R or something inbetween), Qualcomm Hexagon (a kind of general purpose, VLIW dsp) or other more or less known architectures.

Apple is nothing special in this regard, up until the iPhone8/iPhoneX, they used to have two different basebands, one for CDMA markets and one for everything else. The CDMA one was based on Qualcomm Hexagon dsp, while the GSM one was based on Intel XMMxxxx architecture. For those that like to play around with iPhone firmwares, you might have seen MAVxxx and ICExxx files in the ipsw, well those two files contain the firmware respectively for Qualcomm based devices (MAV) and Intel based ones (ICE).

As you may know, Apple decided to drop Qualcomm and now they’re using exclusively Intel based basebands, so we will concentrate on this.

The old Intel baseband

Let’s take a look at the old generation of Intel baseband, the one used up to iPhoneX. If you download an ipsw GSM firmware and unzip it (ipsw files are just zip files), there will be, amongst other things, a “Firmware” folder. Inside this folder you will see a couple of files: “ICE17-1.04.52.Release.bbfw” and “Mav17-1.91.00.Release.bbfw”. The version will change of course, these are for iPhone8 with iOS 11.4beta3. Those files are again zip files and we’re interested in ICE17-xxx, let’s unzip it and see the contents:

John-MacBook-Air:ICE user$ ls -al total 76800 drwxr-xr-x 16 user staff 544 Sep 14 11:08 . drwxr-xr-x@ 15 user staff 510 Sep 14 11:08 .. -rw-r--r--@ 1 user staff 9098 Apr 20 03:29 2GFW.elf -rw-r--r--@ 1 user staff 753552 Apr 20 03:29 3GFW.elf -rw-r--r--@ 1 user staff 13358 Apr 20 03:29 AudioFW.elf -rw-r--r--@ 1 user staff 274 Apr 20 03:29 Debug_info.elf -rw-r--r--@ 1 user staff 1031 Apr 20 03:29 Info.plist -rw-r--r--@ 1 user staff 5146700 Apr 20 03:29 LTEFW.elf -rw-r--r--@ 1 user staff 0 Oct 30 2017 Options.plist -rw-r--r--@ 1 user staff 423592 Apr 20 03:29 RFFW.elf -rw-r--r--@ 1 user staff 30633772 Apr 20 03:29 SYS_SW.elf -rw-r--r--@ 1 user staff 1834194 Apr 20 03:29 TDSFW.elf -rw-r--r--@ 1 user staff 83170 Apr 22 12:26 bbcfg.bin -rw-r--r--@ 1 user staff 73496 Apr 20 03:28 ebl.bin -rw-r--r--@ 1 user staff 163836 Apr 20 03:28 psi_ram.bin -rw-r--r--@ 1 user staff 163836 Apr 20 03:29 restorepsi.bin

lot of stuff here. People familiar with embedded firmware reversing, will set their eyes on “psi_ram.bin” and “ebl.bin” of course. A quick hex dump of their content, will immediately reveal that they contain ARM code. As a matter of fact, “psi_ram.bin” is the stage0 bootloader, that will load “ebl.bin” at some address and jump to its entry point. ebl.bin will then load all other files and jump to the main firmware, contained in SYS_SW.elf. Just to be sure, let us fire IDA and open psi_ram.bin for example, load address does not matter, just set it to 0:

ROM:00000000 CODE32 ROM:00000000 6C 04 00 EA B loc_11B8 ROM:00000000 ; --------------------------------------------------------------------------- ROM:00000004 6C 69 48 55 DCD 0x5548696C ROM:00000008 01 51 FE FF DCD 0xFFFE5101 [...] ROM:000011B8 10 40 2D E9 STMFD SP!, {R4,LR} ROM:000011BC 1D 0D 00 FB BLX sub_463A ROM:000011C0 08 41 9F E5 LDR R4, =0x80400 ROM:000011C4 00 00 A0 E3 MOV R0, #0 ROM:000011C8 04 00 84 E5 STR R0, [R4,#4] ROM:000011CC 05 3A 00 FA BLX sub_F9E8 ROM:000011D0 01 00 50 E3 CMP R0, #1 ROM:000011D4 37 00 00 0A BEQ loc_12B8 ROM:000011D8 F4 10 9F E5 LDR R1, =0x230000 ROM:000011DC 08 00 84 E2 ADD R0, R4, #8 ROM:000011E0 00 30 A0 E3 MOV R3, #0 ROM:000011E4 00 21 04 E3 MOV R2, #0x4100 ROM:000011E8 27 3B 00 FA BLX sub_FE8C ROM:000011EC ROM:000011EC loc_11EC ; CODE XREF: ROM:000012CC↓j ROM:000011EC 00 20 A0 E3 MOV R2, #0 ROM:000011F0 8E 0F 84 E2 ADD R0, R4, #0x238 ROM:000011F4 02 10 A0 E1 MOV R1, R2 ROM:000011F8 DB 3B 00 FA BLX sub_1016C ROM:000011FC D4 10 8F E2 ADR R1, aBootrom ; "bootrom" ROM:00001200 00 00 A0 E3 MOV R0, #0 ROM:00001204 F3 3B 00 FA BLX sub_101D8 ROM:00001208 01 00 A0 E3 MOV R0, #1 ROM:0000120C E4 3B 00 FA BLX sub_101A4 ROM:00001210 C8 00 8F E2 ADR R0, aPsiPsiStartup ; "psi: PSI Startup"

nothing strange here, it’s your standard embedded ARM boot code, with some custom setup related to this specific SoC. Moving on, psi_ram will load ebl and jump into it, you can find the code yourself, is not that complex. The important thing is, this is ARM code.

The new Intel baseband…the horror…the horror…

Waking up this morning, I wanted to analyse the new baseband firmware, to get an idea of what changed and where. So I downloaded a random OTA for the new iPhones from ipsw.me, in particular: https://ipsw.me/otas/iPhone11,2 , which should be the new iPhone Xs. I went through the usual stages (downloading, unzipping, unzipping, unzipping, copying, etc…), I load psi_ram.bin into IDA, I select ARM little endian, and…huge chunk of undefined data. I press “C” like an idiot for about 200 times, I reload the file multiple times, I try another IDA version, I try to disassemble the bytes with Capstone, I DISASSEMBLE THEM MANUALLY, nothing…all I got was invalid code. So I went back to sleep because obviously it was not a good day.

I wake up again after about an hour, I download again the ipsw for the same model and I go through all the same steps as usual. Still invalid code. My first guess was that the code is encrypted, so I use some random tool to analyse the entropy, nothing, it’s very low. Ok, you cannot trust tools these days, so I wrote my own script to calculate the entropy and again, is too low to be encrypted and anyway, it was also clear by a quick “eye” analysis, even though you should not trust your eyes that much.

I stare at the screen for several minutes, thinking what the fu** is going on. But of course, as a reverser you should never give up, so I try EVERY POSSIBLE RISC ARCHITECTURE I KNOW, and trust me, there’s a lot of them (no I mean, A LOT, I reversed everything from Dreamcast SH4 to Fujitsu/Siemens running inside my Nikon D90), and…

Nothing, all I get is garbage. My next guess is: ok then, it’s encrypted with some entropy-preserving algorithm. I try some cryptoanalisis approaches I know, even though is not my main job and I’m no expert at it, still nothing.

I make another coffee and I start to think, in my mind, as a joke: fuck it, this is x86 because Intel has gone insane. I start to laugh maniacally at the idea, but you know, I had tried everything, so I reopen “psi_ram.bin” and I leave the default “MetaPC” architecture in IDA, and…

seg000:0000143A sub_143A proc near ; CODE XREF: sub_12EC+6F↑p seg000:0000143A ; sub_160B+182↓p seg000:0000143A seg000:0000143A var_4 = dword ptr -4 seg000:0000143A seg000:0000143A push esi seg000:0000143B mov [esp+4+var_4], eax seg000:0000143E lea edx, [esp+4+var_4] seg000:00001441 push 44h ; 'D' seg000:00001443 push edx seg000:00001444 push 25h ; '%' seg000:00001446 call sub_2644 seg000:0000144B add esp, 0Ch seg000:0000144E pop ecx seg000:0000144F retn seg000:0000144F sub_143A endp

I could not believe my eyes…I was looking at embedded x86 code running inside a baseband processor. I thought that it was just random chance, that somehow I ended up with valid x86 code, so I look at another function (note: IDA automatically resolved most of the code) and….

seg000:0000DFD0 sub_DFD0 proc near ; CODE XREF: sub_DF4D+7A↑p seg000:0000DFD0 seg000:0000DFD0 arg_0 = dword ptr 4 seg000:0000DFD0 seg000:0000DFD0 mov eax, [esp+arg_0] seg000:0000DFD4 lgdt fword ptr [eax] seg000:0000DFD7 mov ax, 10h seg000:0000DFDB mov ds, eax seg000:0000DFDD assume ds:nothing seg000:0000DFDD mov es, eax seg000:0000DFDF assume es:nothing seg000:0000DFDF mov ss, eax seg000:0000DFE1 assume ss:nothing seg000:0000DFE1 mov ax, 18h seg000:0000DFE5 mov gs, eax seg000:0000DFE7 assume gs:nothing seg000:0000DFE7 jmp far ptr 8:0FF90DFEEh seg000:0000DFE7 sub_DFD0 endp

holy sh*t…lgdt…mov ds, eax…jmp far ptr 8:xxx, you can’t get more x86 than this. This is no coincidence, this MUST be valid x86 code…I was totally speechless, and partially in awe, because this reminds me of my younger days when I was writing bootloaders and operating systems that run in protected mode.

But my rational part told me “hey, probably they just decided to boot the system with an embedded x86 mcu, OBVIOUSLY the main firmware still runs on ARM”, so I turn my attention to “SYS_SW.elf”, the main firmware. I look at the ELF header, and it says ARM…good. I load it in IDA, and I get garbage…AGAIN!!!! I think “what.the.fuck” and I try to load it with MetaPC again and…BOOM, valid x86 code! Random snippet:

seg000:010029E4 seg000:010029E4 seg000:010029E4 sub_10029E4 proc near ; CODE XREF: seg000:0001016C↑p seg000:010029E4 ; seg000:00010175↑p ... seg000:010029E4 push esi seg000:010029E5 push edi seg000:010029E6 push ebx seg000:010029E7 push ebp seg000:010029E8 mov edi, [esp+14h] seg000:010029EC cmp edi, 8Ah seg000:010029F2 lea eax, ds:218DB44h[edi*8] seg000:010029F9 mov esi, [eax] seg000:010029FB mov ebp, [eax-4] seg000:010029FE jb short loc_1002A05 seg000:01002A00 push 0FFFFFFFFh seg000:01002A02 pop eax seg000:01002A03 jmp short loc_1002A68

this is awesome…

Conclusions

Nothing really, I just found this funny and wanted to share. If you ever felt like you missed an x86 core in your life, now you have one (or several? I still need to investigate) always with you, so you won’t feel alone ever again. I still did not have time to analyse the other models, but my guess is that they’re also running on x86.

What will happen next? Are we going to get a z80 inside our phones? Why not a 6502? Hell, I would love to run C64 basic interpreter natively inside my phone….

No really, I’m not criticizing Apple or Intel for using an x86 core, I don’t really care, but…my PERSONAL opinion is that something is going really wrong in this world.

References

Things you may find useful on the subject, in no particular order: