Windows CE初探
创建时间：2004-11-05 更新时间：2004-12-06
文章属性：原创
文章提交： san (san_at_xfocus.org)
整理：san
创建：2004.10.17
更新：2004.11.09
--[ 1. ARM简介
从Platform Builder来看，Windows CE支持相当多CPU，但现在市场上实际销售的PDA几乎全部采用ARM芯片。ARM是一个RISC构架的32位微处理器，它一次有16个可见的寄存器：r0-r15。其中r0-r7是通用寄存器并可以做任何目的；r8-r12也是通用寄存器，但是在切换到FIQ模式的时候，使用它们的影子(shadow)寄存器；最后这三个是特殊寄存器：
r13 (sp) - 堆栈指针
r14 (lr) - 链接寄存器
r15 (pc/psr) - 程序计数器/状态寄存器
IDAPro和调试器里都是用别名表示。和其它RISC指令类似，ARM指令主要有分支（branch）指令、载入和存储指令和其它指令等，除了载入和存储指令，其它指令都是不能直接操作内存的，而且载入和存储指令操作的是4字节类型，那么内存地址必须要求4字节对齐，这也是RISC指令和CISC指令差异比较大的地方，在操作字符串的时候相对就比较麻烦。ARM指令一个很有趣的地方就是可以直接修改访问pc寄存器，这样如果写shellcode的话就不必象SPARC或PowerPC一样需要多条指令来定位自身。
另外Windows CE默认使用的字节序是little-endian。
--[ 2. Windows CE核心结构
Windows CE是一个32位的操作系统，所以其虚拟内存的大小是4GB（2的32次方）。Windows CE把这4GB虚拟内存空间分为低地址2GB和高地址2GB。应用程序使用的地址空间是低地址2GB，高地址2GB专供Windows CE内核使用。在Windows CE 3.0源码的PRIVATE/WINCEOS/COREOS/NK/INC/nkarm.h头文件里有一些有趣的信息：
/* High memory layout
*
* This structure is mapped in at the end of the 4GB virtual
* address space.
*
* 0xFFFD0000 - first level page table (uncached) (2nd half is r/o)
* 0xFFFD4000 - disabled for protection
* 0xFFFE0000 - second level page tables (uncached)
* 0xFFFE4000 - disabled for protection
* 0xFFFF0000 - exception vectors
* 0xFFFF0400 - not used (r/o)
* 0xFFFF1000 - disabled for protection
* 0xFFFF2000 - r/o (physical overlaps with vectors)
* 0xFFFF2400 - Interrupt stack (1k)
* 0xFFFF2800 - r/o (physical overlaps with Abort stack & FIQ stack)
* 0xFFFF3000 - disabled for protection
* 0xFFFF4000 - r/o (physical memory overlaps with vectors & intr. stack & FIQ stack)
* 0xFFFF4900 - Abort stack (2k - 256 bytes)
* 0xFFFF5000 - disabled for protection
* 0xFFFF6000 - r/o (physical memory overlaps with vectors & intr. stack)
* 0xFFFF6800 - FIQ stack (256 bytes)
* 0xFFFF6900 - r/o (physical memory overlaps with Abort stack)
* 0xFFFF7000 - disabled
* 0xFFFFC000 - kernel stack
* 0xFFFFC800 - KDataStruct
* 0xFFFFCC00 - disabled for protection (2nd level page table for 0xFFF00000)
*/
typedef struct ARM_HIGH {
ulong firstPT[4096]; // 0xFFFD0000: 1st level page table
PAGETBL aPT[16]; // 0xFFFD4000: 2nd level page tables
char reserved2[0x20000-0x4000-16*sizeof(PAGETBL)];
char exVectors[0x400]; // 0xFFFF0000: exception vectors
char reserved3[0x2400-0x400];
char intrStack[0x400]; // 0xFFFF2400: interrupt stack
char reserved4[0x4900-0x2800];
char abortStack[0x700]; // 0xFFFF4900: abort stack
char reserved5[0x6800-0x5000];
char fiqStack[0x100]; // 0xFFFF6800: FIQ stack
char reserved6[0xC000-0x6900];
char kStack[0x800]; // 0xFFFFC000: kernel stack
struct KDataStruct kdata; // 0xFFFFC800: kernel data page
} ARM_HIGH;
其中KDataStruct的结构非常重要而且有意思，有些类似Win32下的PEB结构，定义了系统各种重要的信息：
struct KDataStruct {
LPDWORD lpvTls; /* 0x000 Current thread local storage pointer */
HANDLE ahSys[NUM_SYS_HANDLES]; /* 0x004 If this moves, change kapi.h */
// NUM_SYS_HANDLES == 32 : PUBLIC/COMMON/SDK/INC/kfuncs.h
0x004 SH_WIN32
0x008 SH_CURTHREAD
0x00c SH_CURPROC
0x010 SH_KWIN32
0x044 SH_GDI
0x048 SH_WMGR
0x04c SH_WNET
0x050 SH_COMM
0x054 SH_FILESYS_APIS
0x058 SH_SHELL
0x05c SH_DEVMGR_APIS
0x060 SH_TAPI
0x064 SH_PATCHER
0x06c SH_SERVICES
char bResched; /* 0x084 reschedule flag */
char cNest; /* 0x085 kernel exception nesting */
char bPowerOff; /* 0x086 TRUE during "power off" processing */
char bProfileOn; /* 0x087 TRUE if profiling enabled */
ulong unused; /* 0x088 unused */
ulong rsvd2; /* 0x08c was DiffMSec */
PPROCESS pCurPrc; /* 0x090 ptr to current PROCESS struct */
PTHREAD pCurThd; /* 0x094 ptr to current THREAD struct */
DWORD dwKCRes; /* 0x098 */
ulong handleBase; /* 0x09c handle table base address */
PSECTION aSections[64]; /* 0x0a0 section table for virutal memory */
LPEVENT alpeIntrEvents[SYSINTR_MAX_DEVICES];/* 0x1a0 */
LPVOID alpvIntrData[SYSINTR_MAX_DEVICES]; /* 0x220 */
ulong pAPIReturn; /* 0x2a0 direct API return address for kernel mode */
uchar *pMap; /* 0x2a4 ptr to MemoryMap array */
DWORD dwInDebugger; /* 0x2a8 !0 when in debugger */
PTHREAD pCurFPUOwner; /* 0x2ac current FPU owner */
PPROCESS pCpuASIDPrc; /* 0x2b0 current ASID proc */
long nMemForPT; /* 0x2b4 - Memory used for PageTables */
long alPad[18]; /* 0x2b8 - padding */
DWORD aInfo[32]; /* 0x300 - misc. kernel info */
// PUBLIC/COMMON/OAK/INC/pkfuncs.h
0x300 KINX_PROCARRAY address of process array
0x304 KINX_PAGESIZE system page size
0x308 KINX_PFN_SHIFT shift for page # in PTE
0x30c KINX_PFN_MASK mask for page # in PTE
0x310 KINX_PAGEFREE # of free physical pages
0x314 KINX_SYSPAGES # of pages used by kernel
0x318 KINX_KHEAP ptr to kernel heap array
0x31c KINX_SECTIONS ptr to SectionTable array
0x320 KINX_MEMINFO ptr to system MemoryInfo struct
0x324 KINX_MODULES ptr to module list
0x328 KINX_DLL_LOW lower bound of DLL shared space
0x32c KINX_NUMPAGES total # of RAM pages
0x330 KINX_PTOC ptr to ROM table of contents
0x334 KINX_KDATA_ADDR kernel mode version of KData
0x338 KINX_GWESHEAPINFO Current amount of gwes heap in use
0x33c KINX_TIMEZONEBIAS Fast timezone bias info
0x340 KINX_PENDEVENTS bit mask for pending interrupt events
0x344 KINX_KERNRESERVE number of kernel reserved pages
0x348 KINX_API_MASK bit mask for registered api sets
0x34c KINX_NLS_CP hiword OEM code page, loword ANSI code page
0x350 KINX_NLS_SYSLOC Default System locale
0x354 KINX_NLS_USERLOC Default User locale
0x358 KINX_HEAP_WASTE Kernel heap wasted space
0x35c KINX_DEBUGGER For use by debugger for protocol communication
0x360 KINX_APISETS APIset pointers
0x364 KINX_MINPAGEFREE water mark of the minimum number of free pages
0x368 KINX_CELOGSTATUS CeLog status flags
0x36c KINX_NKSECTION Address of NKSection
0x370 KINX_PWR_EVTS Events to be set after power on
0x37c KINX_NKSIG last entry of KINFO -- signature when NK is ready
/* 0x380 - interlocked api code */
/* 0x400 - end */
}
Win32下可以通过PEB结构定位kernel32.dll的基址，然后通过PE文件结构查找Windows API。在Windows CE下，coredll.dll的作用相当于Win32的kernel32.dll，由于KDataStruct结构开始于0xFFFFC800，偏移0x324的aInfo[KINX_MODULES]是一个指向模块链表的指针，通过这个链表能否找到coredll.dll模块呢？让我们来看一下模块的结构：
// PRIVATE/WINCEOS/COREOS/NK/INC/kernel.h
typedef struct Module {
LPVOID lpSelf; /* 0x00 Self pointer for validation */
PMODULE pMod; /* 0x04 Next module in chain */
LPWSTR lpszModName; /* 0x08 Module name */
DWORD inuse; /* 0x0c Bit vector of use */
DWORD calledfunc; /* 0x10 Called entry but not exit */
WORD refcnt[MAX_PROCESSES]; /* 0x14 Reference count per process*/
LPVOID BasePtr; /* 0x54 Base pointer of dll load (not 0 based) */
DWORD DbgFlags; /* 0x58 Debug flags */
LPDBGPARAM ZonePtr; /* 0x5c Debug zone pointer */
ulong startip; /* 0x60 0 based entrypoint */
openexe_t oe; /* 0x64 Pointer to executable file handle */
typedef struct openexe_t {
union {
int hppfs; // ppfs handle
HANDLE hf; // object store handle
TOCentry *tocptr; // rom entry pointer
}; // 0x64
BYTE filetype; // 0x68
BYTE bIsOID; // 0x69
WORD pagemode; // 0x6a
union {
DWORD offset;
DWORD dwExtRomAttrib;
}; // 0x6c
union {
Name *lpName;
CEOID ceOid;
}; // 0x70
} openexe_t;
e32_lite e32; /* 0x74 E32 header */
// PUBLIC/COMMON/OAK/INC/pehdr.h
typedef struct e32_lite { /* PE 32-bit .EXE header */
unsigned short e32_objcnt; /* 0x74 Number of memory objects */
BYTE e32_cevermajor; /* 0x76 version of CE built for */
BYTE e32_ceverminor; /* 0x77 version of CE built for */
unsigned long e32_stackmax; /* 0x78 Maximum stack size */
unsigned long e32_vbase; /* 0x7c Virtual base address of module */
unsigned long e32_vsize; /* 0x80 Virtual size of the entire image */
unsigned long e32_sect14rva; /* 0x84 section 14 rva */
unsigned long e32_sect14size; /* 0x88 section 14 size */
struct info e32_unit[LITE_EXTRA]; /* 0x8c Array of extra info units */
struct info { /* Extra information header block */
unsigned long rva; /* Virtual relative address of info */
unsigned long size; /* Size of information block */
}
0x8c EXP Export table position
0x94 IMP Import table position
0x9c RES Resource table position
0xa4 EXC Exception table position
0xac SEC Security table position
0xb4 FIX Fixup table position
} e32_lite, *LPe32_list;
o32_lite *o32_ptr; /* 0xbc O32 chain ptr */
DWORD dwNoNotify; /* 0xc0 1 bit per process, set if notifications disabled */
WORD wFlags; // 0xc4
BYTE bTrustLevel; // 0xc6
BYTE bPadding; // 0xc7
PMODULE pmodResource; /* 0xc8 module that contains the resources */
DWORD rwLow; /* 0xcc base address of RW section for ROM DLL */
DWORD rwHigh; /* 0xd0 high address RW section for ROM DLL */
PGPOOL_Q pgqueue; /* 0xcc list of the page owned by the module */
typedef struct _PGPOOL_Q {
WORD idxHead; /* head of the queue */
WORD idxTail; /* tail of the queue */
} PGPOOL_Q, *PPGPOOL_Q;
} Module;
模块结构偏移0x08是指向模块名字的指针，偏移0x04指向链表里的下一个模块，通过这个模块名字可以在模块链表里找到我们需要的coredll.dll。而偏移0x7c就是该模块的虚拟基址，偏移0x8c是导出表的相对地址。Windows CE使用的PE结构和Win32是一样，那么有写Win32 shellcode经验的朋友自然会想着从coredll.dll的基址按照PE结构顺藤摸瓜来搜索函数地址。但是我们用EVC实际调试时发现coredll.dll找到的基址是0x01F60000，而这个地址的内存是没有分配的（调试器里都是问号），可以访问的地址是从0x01F61000，这和IDAPro反汇编coredll.dll（从rom文件中dump出来，wince下系统在使用的文件连读的权限都没有）出的起始地址一样。Windows CE可能为了节省内存，没有加载文件最开始的0x1000字节头结构。不过没有关系，因为我们已经从模块结构得到该模块的导出表相对地址，直接从导出表就可以查找函数地址了。
--[ 3. Windows CE演示实例
Ratter/29A的WinCE4.Dust代码可能是为了减少体积，他给出的方法是把要搜索函数的序数索引硬编码到程序里，然后根据导出表的地址定位导出地址表，再用硬编码的序数索引来算出函数地址。这种方法让人感觉挺别扭的，虽然代码减少了，可是通用性可能会打折扣，象编写Win32 shellcode一样通过函数名来搜索的方法可能更通用一些。下面的代码就是实现这样的功能。
; armasm test.asm
; link /MACHINE:ARM /SUBSYSTEM:WINDOWSCE test.obj
CODE32
EXPORT WinMainCRTStartup
AREA .text, CODE, ARM
test_start
; r11 - base pointer
test_code_start PROC
stmdb sp!, {r0 - r12, lr, pc}
bl get_export_section
adr r2, mb
bl lookup_imports
mov r0, #0
adr r1, text
adr r2, text
mov r3, #0 ; MB_OK
mov lr, pc
mov pc, r9 ; MessageBoxW
bl get_export_section
adr r2, tp
bl lookup_imports
mov r0, #-1
mov r1, #0
mov lr, pc
mov pc, r9
; basic wide string compare
wstrcmp PROC
wstrcmp_iterate
ldrh r2, [r0], #2
ldrh r3, [r1], #2
cmp r2, #0
cmpeq r3, #0
moveq pc, lr
cmp r2, r3
beq wstrcmp_iterate
mov pc, lr
ENDP
; output:
; r0 - coredll base addr
; r1 - export section addr
get_export_section PROC
stmdb sp!, {r4 - r9, lr}
ldr r4, =0xffffc800 ; KDataStruct
ldr r5, =0x324 ; aInfo[KINX_MODULES]
add r5, r4, r5
ldr r5, [r5]
; r5 now points to first module
mov r6, r5
mov r7, #0
iterate
ldr r0, [r6, #8] ; get dll name
adr r1, coredll
bl wstrcmp ; compare with coredll.dll
ldreq r7, [r6, #0x7c] ; get dll base
ldreq r8, [r6, #0x8c] ; get export section rva
add r9, r7, r8
beq got_coredllbase ; is it what we're looking for?
ldr r6, [r6, #4]
cmp r6, #0
cmpne r6, r5
bne iterate ; nope, go on
got_coredllbase
mov r0, r7
add r1, r8, r7 ; yep, we've got imagebase
; and export section pointer
ldmia sp!, {r4 - r9, pc}
ENDP
coredll DCB "c", 0x0, "o", 0x0, "r", 0x0, "e", 0x0, "d", 0x0, "l", 0x0, "l", 0x0
DCB ".", 0x0, "d", 0x0, "l", 0x0, "l", 0x0, 0x0, 0x0
; basic string compare
bstrcmp PROC
bstrcmp_iterate
ldrb r9, [r7], #1
ldrb r10, [r8], #1
cmp r9, #0
cmpeq r10, #0
moveq pc, lr
cmp r9, r10
beq bstrcmp_iterate
mov pc, lr
ENDP
; r0 - coredll base addr
; r1 - export section addr
; r2 - function name addr
lookup_imports PROC
stmdb sp!, {r4 - r6, lr}
ldr r4, [r1, #0x20] ; AddressOfNames
add r4, r4, r0
mov r6, #0 ; counter
lookup_imports_iterate
ldr r7, [r4], #4
add r7, r7, r0 ; function name ponter
mov r8, r2 ; find function name
bl bstrcmp
addne r6, r6, #1
bne lookup_imports_iterate
ldr r5, [r1, #0x24] ; AddressOfNameOrdinals
add r5, r5, r0
add r6, r6, r6
ldrh r9, [r5, r6] ; Ordinals
ldr r5, [r1, #0x1c] ; AddressOfFunctions
add r5, r5, r0
ldr r9, [r5, r9, LSL #2] ; function address rva
add r9, r9, r0 ; function address
ldmia sp!, {r4 - r6, pc}
ENDP
mb DCB "MessageBoxW", 0x0
tp DCB "TerminateProcess", 0x0,0x0,0x0,0x0
ALIGN 4
; Dear User, am I allowed to spread?
text DCB "H", 0x0, "e", 0x0, "l", 0x0, "l", 0x0, "o", 0x0, " ", 0x0
DCB "W", 0x0, "i", 0x0, "n", 0x0, "C", 0x0, "E", 0x0, "!", 0x0
DCB 0x0, 0x0, 0x0, 0x0
ALIGN 4
LTORG
test_end
; the code after test_end doesn't get copied to victims
WinMainCRTStartup PROC
b test_code_start
ENDP
; first generation entry point
host_entry
mvn r0, #0
mov pc, lr
END
代码还是比较傻，如果能把Win32 shellcode的hash引入可能代码会更好看一些。Ratter/29A在WinCE4.Dust虽然还只是个概念病毒，但是病毒的基本技术它都已经具备了，所以不难相信不久就会有更多的Windows CE病毒。如果作者不怀好意，用KernelIoControl把系统引导入BootLoader模式，那么对于很多非专业的用户来说无疑象遭遇CIH病毒一般可恶。
通过上面的代码不难相信很容易就能写出Windows CE下的shellcode，Seth Fogie在最近的defcon等会议上提到Windows CE下缓冲区溢出，随着PDA网络化程度越来越高，以及和手机的结合，相信Windows CE下的缓冲区溢出不久就会流行起来。不过Windows CE下缓冲区溢出可能会遭遇几个问题：
1. Windows CE是一个Unicode环境，它可能会把用户输入的数据转成Unicode格式。
2. 要在Windows CE上写解码shellcode可能会有些问题，首先arm没有xor指令，另外还有可能遭遇指令缓存的问题。不是很清楚Windows CE对软中断指令swi怎么支持。
3. 不同厂商不同版本的PDA可能存在这样那样的差异，导致攻击程序无法通用。
不过Windows CE现在已经发展的很成熟了，可以进来看看。
--[ 4. 参考资料：
1. ARM ASSEMBLER
http://www.heyrick.co.uk/assembler/index.html
2. misc notes on the xda and windows ce
http://www.xs4all.nl/~itsme/projects/xda/
3. Windows CE 3.0 Source Code
http://msdn.microsoft.com/embedded/prevver/ce3/download/source/default.aspx
4. Details Emerge on the First Windows Mobile Virus
http://www.informit.com/articles/article.asp?p=337071
历史记录：
1. 2004.11.09修正搜索API代码的一个错误。
广告时间：
本文将进一步扩充整理，作为XFocus Security Team的《网络渗透技术》（暂定名）一书中《Windows CE平台缓冲区溢出利用技术》一节。XFocus Security Team将在 安全焦点技术研究版对本书做全面技术支持。