Hacking Windows CE

Hacking Windows CEsan@nsfocus.comsan@xfocus.org

Structure OverviewWindows CE OverviewWindows CE Memory ManagementWindows CE Processes and ThreadsWindows CE API Address Search TechnologyThe Shellcode for Windows CESystem CallWindows CE Buffer Overflow DemonstrationAbout Decoding ShellcodeConclusionReference

Windows CE Overview(2)ARM ArchitectureRISCARMv1 -v6

Memory Management(1)Windows CE uses ROM (read only memory),RAM (random access memory)The ROM in a Windows CE system is like a smallread-only hard diskThe RAM in a Windows CE system is divided intotwo areas: program memory and object storeWindows CE is a 32-bit operating system,so it supports 4GB virtual address spaceUpper 2GB is kernel space, used by thesystem for its own dataPart 2/8

Memory Management(2)

Memory Management(3)Lower 2GB is user space0x42000000-0x7FFFFFFF memory isused for large memory allocations, suchas memory-mapped files0x0-0x41FFFFFF memory is divided into33 slots, each of which is 32MB

Memory Management(4)Slot 0 layout

Processes and Threads(1)Windows CE limits 32 processes being run at anyone timeEvery process at least has a primary threadassociated with it upon starting (even if it neverexplicitly created one)A process can created any number of additionalthreads (only limited by available memory)Each thread belongs to a particular process (andshares the same memory space)SetProcPermissions API will give the current threadaccess to any processEach thread has an ID, a private stack and a set ofregistersPart 3/8

Processes and Threads(2)When a process is loadedAssigned to next available slotDLLs loaded into the slotFollowed by the stack and default process heapAfter this, then executedWhen a process’ thread is scheduledCopied from its slot into slot 0This is mapped back to the original slotallocated to the process if the processbecomes inactive

Processes and Threads(3)Processes allocate stack for each thread,the default size is 64KB, depending on thelink parameter when the program iscompiledTop 2KB used to guard against stack overflowRemained available for useVariables declared inside functions areallocated in the stackThread’s stack memory is reclaimed when itterminates

API Address Search(1)Locate the loaded address of the coredll.dllstruct KDataStruct kdata; // 0xFFFFC800: PUserKData0x324 KINX_MODULES ptr to module listLPWSTR lpszModName; /* 0x08 Module name */PMODULE*/pMod; /* 0x04 Next module in chainunsigned long e32_vbase;of module *//* 0x7c Virtual base addressstruct info e32_unit[LITE_EXTRA]; /* 0x8c Array of extra infounits */0x8c EXP Export table positionPocketPC ROMs were builded with Enable Full Kernel ModeoptionWe got the loaded address of the coredll.dll and its exporttable position.Part 4/8

API Address Search(2)Find API address via IMAGE_EXPORT_DIRECTORYstructure like Win32.typedef struct _IMAGE_EXPORT_DIRECTORY{......DWORD AddressOfFunctions; // +0x1c RVAfrom base of imageDWORD AddressOfNames; // +0x20 RVAfrom base of imageDWORD AddressOfNameOrdinals; // +0x24 RVAfrom base of image// +0x28} IMAGE_EXPORT_DIRECTORY,*PIMAGE_EXPORT_DIRECTORY;

API Address Search(3)Export Directory0x1c“KernelIoControl”Names Ordinals Functionsaddress

Shellcode(1)test.asm -the final shellcodeget_export_sectionfind_funcfunction implement of the shellcodeIt will soft reset the PDA and open itsbluetooth for some IPAQs(Forexample, HP1940)Part 5/8

Shellcode(2)Something to attention while writingshellcodeLDR pseudo-instruction"ldr r4, =0xffffc800" => "ldr r4, [pc, #0x108]""ldr r5, =0x324" => "mov r5, #0xC9, 30"r0-r3 used as 1st-4th parameters of API,the other stored in the stack

Shellcode(3)EVC has several bugs that makesdebug difficultEVC will change the stack contents whenthe stack reclaimed in the end of functionThe instruction of breakpoint maybechange to 0xE6000010 in EVCsometimesEVC allows code modify .text segmentwithout error while using breakpoint.(sometimes it's useful)

System CallWindows CE APIs implement bysystem callThere is a formula to calculate thesystem call address0xf0010000-(256*apiset+apinr)*4The shellcode is more simple and itcan used by user modePart 6/8

Buffer Overflow Demo(1)hello.cpp -the vulnerable programReading data from the "binfile" of the root directory tostack variable "buf" by fread()Then the stack variable "buf" will be overflowedARM assembly language uses bl instruction to callfunction"str lr, [sp, #-4]! " -the first instruction of thehello() function"ldmia sp!, {pc} " -the last instruction of the hello()functionOverwriting lr register that is stored in the stack willobtain control when the function returnedPart 7/8

Buffer Overflow Demo(2)The variable's memory addressallocated by program iscorresponding to the loaded Slot,both stack and heapThe process maybe loaded into thedifference Slot at each start time, sothe base address always altersSlot 0 is mapped from the currentprocess' Slot, so its stack address isstable

Buffer Overflow Demo(3)

Buffer Overflow Demo(4)A failed exploit–The PDA is frozen when the hello programis executed–Why? •The stack of Windows CE is small•Buffer overflow destroyed the 2KBguard on the top ofstack boundary

Buffer Overflow Demo(5)A successful exploit -exp.cThe PDA restarts when thehello program is executedThe program flows to ourshellcode

About Decoding Shellcode(1)Why need to decode shellcode?The other programs maybe filter thespecial characters before string bufferoverflow in some situationsIt is difficult and inconvenient to write ashellcode without special characters byAPI address search method in WindowsCEPart 8/8

About Decoding Shellcode(2)The newer ARM processor hasHarvard ArchitectureARM9 core has 5 pipelines and ARM10core has 6 pipelinesIt separates instruction cache and datacacheSelf-modifying code is not easy toimplement

About Decoding Shellcode(3)A successful exampleonly use store(without load) to modifyself-codeyou'll get what you want after paddingenough nop instructionsARM10 core processor need more padinstructionsSeth Fogie's shellcode use this method

About Decoding Shellcode(4)A puzzled exampleload a encoded byte and store it afterdecodedpad instructions have no effectSWI does nothing except 'movs pc,lr'under Windows CEOn PocketPC, applications run in kernelmode. So we can use mcr instruction tocontrol coprocessor to manage cachesystem, but it hasn't been successful yet

ConclusionThe codes talked above are the real-lifebuffer overflow example in Windows CEBecause of instruction cache, the decodingshellcode is not good enoughInternet and handset devices are growingquickly, so threats to the PDAs and mobilesbecome more and more seriousThe patch of Windows CE is more difficultand dangerous

Reference[1] ARM Architecture Reference Manualhttp://www.arm.com[2] Windows CE 4.2 Source Codehttp://msdn.microsoft.com/embedded/windowsce/default.aspx[3] Details Emerge on the First Windows Mobile Virushttp://www.informit.com/articles/article.asp?p=337071[4] Pocket PC Abuse - Seth Fogiehttp://www.blackhat.com/presentations/bh-usa-04/bh-us-04-fogie/bh-us-04-fogie-up.pdf[5] misc notes on the xda and windows cehttp://www.xs4all.nl/~itsme/projects/xda/[6] Introduction to Windows CEhttp://www.cs-ipv6.lancs.ac.uk/acsp/WinCE/Slides/[7] Nasiry 's wayhttp://www.cnblogs.com/nasiry/[8] Programming Windows CE Second Edition - Doug Boling[9] Win32 Assembly Componentshttp://LSD-PLaNET

Thank You!san@nsfocus.comsan@xfocus.org