View source for Trek-3.4.03


== Trek Baseband 3.4.03 ==

----

'''iPhone 4S'''

Chip ID: 0x5a00e1.

Internal Chip name: qsc6695.

Full Internal Chip name: q6695-SSMFTSZ-4307. (Found in DBL.mbn)

OS Bootloader version: Q62xx-OSBL.



== Trek Firmware ==

----

The internal name for the baseband firmware is Trek.

Trek can be extracted from an iOS firmware image (ipsw file).

Trek does not seem to be encrypted and therefore can easily be reverse engineered.

At the bottom of each file you can see a code signing certificate, as the firmware needs to be code signed just like Apple iOS firmware does.

All baseband chips up to today are produced by Qualcomm.

The architecture of the chip seems to be ARM as I already expected.

The baseband chip is completely separated from iOS and is only referenced through the kernel and through the bbupdater utility.

CommCenter seems to be a highlevel framework on top of the baseband providing an interface that iOS can work with.

The filesystem used by the baseband seems to be YAFFS (Yet Another Flash FileSystem)

== Firmware Structure ==

As mentioned above, the baseband firmware is not encrypted and when taken from iOS Firmware it will be named ending with a .bbfw (Basebandfirmware) extension.

However when running file on that firmware image you can see that it's just a zip file, just like ipsw files are thus extracting it gives us new, unencrypted files:

- Info.plist

- Options.plist

- amss.mbn (The baseband operating system)

- dbl.mbn (Assumably, factory DFU bootloader)

- osbl.mbn (The Bootloader that bootstraps the normal operating system of the baseband)

- restoredbl.mbn (The restore bootloader)


'''Info.plist''' 

----

contains some basic information about the chip id and firmware version, it can be compared to the BuildManifest.plist file in iOS firmware.


'''Options.plist'''

----

I haven't figured out what this is for yet but as the name suggest it is mostlikely for configuration purposes.


'''AMSS.mbn'''

----

This file is what I believe the baseband operating system, file reports that it consists of ARM code.

At the bottom of the file the codesignature can again be found.

It also seems to contain the filesystem for the nand which is all unencrypted thus pretty interesting.

The filesystem will be explained further on this wiki when I have time for it.

What's the most remarkable are strings revealing how to enter specific device modes:

Hold * key   to reset &  log abort
Hold # key   to enter    dload mode

The dload mode is probably download mode, it is probably comparable to iBoot's communication where you can upload files into iBoot's memory/

For those looking for vulnerabilities in the baseband firmware one string already made me raise a flag.

The baseband seems to support the parsing of property list files.

Because property list files define a type, a user controlled modded type might lead to type confusion bugs.



'''OSBL.mbn'''

----

OSBL reveals a lot of information about the architecture and internal names and hardware identifiers of the baseband chip.

It also contains references to sourcecode files that tell us that the baseband firmware was written in C, as expected.

OSBL is what I believe an abbreviation of Operating System Bootloader.

By just looking at the strings of the file you can determine a few serial numbers that this firmware is meant for and the name of the chip:


MT29F4G16ABC

MT29F4G08ABC

MT29F2G16ABD

MT29F2G08ABD

KFN4G16Q2A-DEB8


Q62xx-OSBL (The bootloader build version, I think)

QSC6695 (The name of the chip as used internally at Qualcomm, if you look it up you can find some chinese suppliers that sell it.)


The strings also reveal the following source code structure:

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\dload\target\qsc6695\src\dloadarm.c


C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_elf_loader.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_elf_loader_if.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_sec_elf_loader.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_sec_elf_loader_if.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_clobber_prot.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_clobber_prot_local.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_flash_dev_if.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_hash_if.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_auth_if.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\shared\src\boot_fsbl_config_if.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\common\target\qsc6695\src\boot_pbl_accessor.c


C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\shared\src\osbl_mc.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\shared\src\osbl_loader.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\shared\src\osbl_error_handler.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\shared\src\osbl_hash.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\shared\src\osbl_shared_seg.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\target\qsc6695\src\osbl_stubs.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\target\qsc6695\src\osbl_hw_init.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\target\qsc6695\src\osbl_mc_target.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\target\qsc6695\src\osbl_target.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\secboot2\osbl\target\qsc6695\src\osbl_sahara.c

C:\BWA\TrekBaseBandFW-240\srcroot\core\boot\amssboot\target\qsc6695\src\boot_shared_progressive_boot_block.c


Looking at these you might get a better idea of the bootstages of the iPhone baseband.


'''DBL.mbn'''

----


This debugging bootloader, in my thoughts a DFU mode seems to be able to make ROM dumps as well.

- mav_core_dump.bin

- mav_hsic_dump.bin

- mav_nor_dump.bin

- sdram_dump.bin

- iram_dump.bin

These are all strings that reveal these dumps can be generated taken from the start of this bootloader.

What also is interesting is the information revealing the hardware ID in a lower section just after the codesignature:


07 0000 SHA11

06 0000 MODEL_ID1

05 00002000 SW_SIZE1

04 0023 OEM_ID1"0

03 000000000000000F DEBUG1"0

02 005000E100230000 HW_ID1"0

01 0000000000000000 SW_ID1

Maverick1

Onur Tackin0


This image also mentions HS-USBCORE (HighSpeed USB-Core)