Archive: winceroms.odp inflating: content.xml Dissecting Windows Mobile roms Willem Hengeveld http://xs4all.nl/~itsme itsme@xs4all.nl Windows Mobile roms What are these roms? Where to find these roms? What is in these roms? What are your scripts for? # Some questions you may ask your self roms Not actually ROM, but NAND or NOR flash Until 2003 : NOR strataflash Since 2003 : NAND diskonchip onenand # Not readonly, but stored in block erasable memory ( flash ) Where to find these rom images Firmware updater loaded from flashcard Usb updater Sometimes obfuscated or encrypted Extract from device Various c++ tools written to access See itsutils pdocread, psdread Access usually through activesync Sometimes via bootloader commands # Updaters # - from vendor support site # - from operator support site # - often encrypted / obfuscated in some way # - often signed # Extracted # - windows ce roms not signed # - texas instruments bb not signed # - qualcomm baseband is usually signed What data is in the rom Baseband OS Application OS Bootloaders Splash images Applications Config data Protected data like imei, simlock, etc. User data # Usually the baseband and app cpu share one flashchip. # But not everything is accessible from the app OS. # A MPU restricts access to the baseband section #Example layout of data stored in the app part of flash XIP Originally: eXecute In Place Pocketpc: 5 – 10 XIP sections Signatures in XIP chain Windows mobile: just 1, containing kernel Format documented in romldr.h # Originally used for executing directly from NOR flash. # Now the bootloaders and kernel are copied to # Fixed offsets from flash in ram, and exec from there. #How is IMGFS structured Perl scripts For decoding updaters For xip blocks For imgfs data For decoding simlock data For analyzing fat filesystems For decoding cab's For decoding baseband images ... # Stuff i wrote decoders for. # The greyed items i will not talk about here. goal Figure out meaning of every byte in rom image Extract executables for analysis Create my own rom images Careful not to brick too many phones My focus was mostly on HTC devices Splitting updaters When starting with an updater Need to strip several layers Obfuscation Encryption Signatures Block remapping Depends very much on device + vendor Fileformat undocumented #Always need to reverse engineer. #The obfuscation + encryption #* educated guesses #* IDA #Fileformats #* by looking at the bytes and trying to make sense of it. Splitting updaters HTC's Pocketpc 2003 + smartphone 2002 splitrom.pl HTC smartphone 2003 typhoonnbfdecode.pl HTC ppc 2005 + sm 2005 and later nbh2dbh.pl + dbhdecode.pl #Other phones i wrote firmware splitters for: # iphone # Imate 810f # Eten m700 # Jornada 928 # Samsung sgh i900 Split result After splitting the updater you get several files Bootloaders Baseband rom Splash images Windows CE OS rom More depending on the device XIP decoding dumprom.cpp dumpxip.pl Modifying Some bash + makexip.pl, chainedit.pl, drparse.pl Not very well documented # Tools for XIP blocks IMGFS Decoding rdmsflsh.pl Modifying (from mamaich) AddFile.exe, DelFile.exe bin only, sometimes crashes editimgfs.pl cpp_editimgfs.cpp # Tools for IMGFS blocks dumpxip.pl Reconstructs .exe and .dll's Readable for IDA, may not really exec. #What is special about reconstructing .exe files from xip modules dumpxip.pl Needs to call decompression lib Which is in a win32 dll ( or .lib ) Not easily reverse engineered No standard algorithm ( like gzip, pkzip, zlib ) Initially using Win32::API Later using my own .xs module #I added cdecl calling convention to Win32::API for this. #Reason for using .xs, was lots of unexplained crashes, #Which later turned out to be bugs in the dll itself. CompressUtils.xs First version directly linked to .lib from SDK Windows only Second version Runs on macosx <=10.5 Use 'dllloader' – emulates LoadLibrary No change to the xs code. Note: needs to run within a 32bit x86 perl. #For macosx 10.6 i tried various IPC mechanisms, #Which all were way too slow. dllloader Implements LoadLibrary + GetProcAddress Takes win32 executable extracts sections Processes relocation info Processes imports Replaces trivial imports (like LocalAlloc) with own implementation. This works fine for dlls which don't have many dependencies. Writing a decoder Separate decoding from use ( like reencoding, printing ) Decoder should return hash with parsed fields. Verify if values fall in expected range. Create hierarchy of decoders mirroring fileformat Use standarized internal representation Utf-8 for strings Perl time values for timestamps ints in numeric scalars #General tips for writing a fileformat decoder Source code http://xs4all.nl/~itsme/projects/xda/ http://xs4all.nl/~itsme/projects/perl/ Not (yet) on CPAN Questions?