Windows CE SuperH3 Exploit Development Part…0: A Statement and a Fresh Start
It’s been quite a long time, friends. As you can probably tell by reading the previous articles series was the start of my reverse engineering journey. I started it back when I was still studying malware analysis in preparation for the GREM. I had always been fascinated by Windows CE PDA’s, and I was aching to learn more about this “exploit development” thing I kept hearing about. With very little knowledge I managed to do some things that I still, with all that I’ve recently learned, find a bit impressive. I managed to learn a long forgotten machine language write RISC shellcode before I learned how to write x86 shellcode proper. I managed to learn enough right after making a fool out of myself one week to sounding semi-competent the next. I was able to learn the basics of exploit development in an environment that few exploit researchers had ever delved into, and this helped me pick up material quickly as I delved into the world of x86 Windows exploit development. However, due to starting college, preparation for an exploit development related certification that required knowledge in other areas (I won’t reveal what it is until after I pass the test, but let’s just say it‘s name ends with “CE”. My first attempt is this weekend!), and general discouragement after dealing with failed attempt after failed attempt, I had to put the project on a rather long hiatus.
This is not the part where I announce that I’m moving on. That would be premature. I love esoteric RISC processors, I love Windows CE, I love early 2000’s technology, and I’ve been aching to put my new knowledge of fuzzing, remote exploitation, and file format exploits to the test. I can’t give up until I have a zero day or two in hand. Instead, I’ve been preparing in secret. Shortly after my next chemistry exam this series will resume, and with my new knowledge of exploit development and a few tricks I’ve been hiding up my sleeve, I hope to start finding and exploiting zero days in Windows CE SH3 applications for the HP Jornada 690.
Now, I’ve made some predictions in past articles that turned out to be wrong, some glaring mistakes, and some bold claims that I found myself unable to deliver on. So what makes this attempt different?
Well, besides what I’ve learned studying exploit development for the better part of the year, here are some of the things I’ve been working on:
One thing I really failed on in past attempts was determining ahead of time whether an exploit was feasible or not. Unicode exploits in Windows CE using the SH3 instruction set are not feasible. I can say that with almost absolute certainty, unless your payload is a NOP sled (0090). Because most Windows CE functions only support Unicode, this will restrict my exploits to file format exploits and network based exploits, two places where I know Unicode cannot be used in many cases.
In future installments of this series, I will be targeting network server applications such as TFTP servers, HTTP servers, and other servers using common, well documented protocols. I plan to start targeting clients as well, but server exploits are a good place to start. My file format based exploits will, in turn, mostly be targeting well known file formats such as zip, icon, font, and media files. I am stretched a bit thin this year as is, and while there is some flexibility on the network protocol side because I am fairly proficient in Wireshark, I do not intend to spends weeks reverse engineering mysterious file formats again.
Another good thing that I can ensure by sticking to file format and remote exploits is that at the end of the day, I have something I can upload to GitHub and send to exploit-db. I want scripts, I want reproducible vulerabilities, and I want semi-realistic attack scenarios. No more GUI text box crashes, I like my exploits exploitable.
In terms of the type of exploits I will be attempting, they will likely all be variations of stack based buffer overflows. I was originally planning to move the series towards heap overflows. This was, as many might have guessed, a terrible, terrible idea for a novice exploit developer experimenting on a system where very few details about the heap and heap exception handling exist.
New Product Information
I picked up a copy of “Inside Microsoft Windows CE”, a truly fascinating look into the minds of the developers of early versions of Windows Compact Edition. It’s sort of like a “Windows Internals” book, but with a lot of information that gives insights into not only Windows CE, but the design of Windows NT from the perspective of a team tasked with creating a version of Windows that fits into just a few megabytes. It gives interesting details about the different OS components, the network stack, and the vast differences between CE and NT drivers. It also gives a detail that might be of note to an exploit developer, such as the fact that the Structured Exception Handler in CE was copied almost wholesale from Windows NT. This is something I did not know on previous attempts. I was operating off of the assumption that SEH wasn’t a factor. Windows CE SEH is intended for heavy use in server applications, so this will likely come into play in later installments. In the meantime, I continue to research the structure of Windows CE SEH and how it can be used to facilitate exploits.
I recently found this series that was started in August by a Microsoft dev, outlining SH-3 assembly language and it’s features. This will be very useful as I plan to start writing an SH-3 shellcode assembler in python soon.
Tools are ultimately not why I failed in the past, but they did play a big role in delaying my efforts. I have recently acquired an IRDA device that may allow me to use a primitive version of WinDBG. This would be huge, as I would be able to attach to running processes, opening up a whole new realm of exploits. I would also be able to read memory I was not previously able to read, run queries faster, and identify structures such as parts of the SEH that I may run into trouble trying to reverse engineer on my own. I’ve had endless hardware compatibility issues, but hopefully I’m approaching a successful installation. You’ll know that I succeeded if the tool shows up in future articles!
I decided to save this one for last because I’ve had success writing SH3 shellcode in the past. It wouldn’t be very exciting if I lead with my advances in doing the thing I didn’t mess up in past attempts. However, I’m hoping folks will like my new payloads.
Through a lot of research on Windows CE developer forums and online hangouts, some reverse engineering of Windows CE 2.11 libraries, and a little bit of luck, I managed to write and test the C version of a small payload that can put a thread into “god mode”. The best way I can describe it is the Windows CE equivalent of “setuid(0)”, with a few Windows CE-specific changes. I am not able to directly copy files from the flash memory module without a few additional commands that, while accessible in god mode, might make shellcode prohibitively large, but I get kernel mode access and OS debug features. Password theft and a few other cool tricks are possible, but for demonstration purposes my planned payload will probably just send a few messages using kernel mode functions. I have yet to write the assembly version of this payload and I may have to reconstruct some code lost in a transfer from one laptop to another, but more on this will be coming soon.
Other payloads I’m planning long term include a downloader that downloads the Windows CE 2.11 version of netcat and opens a reverse shell, but that’s a ways off. Process based reverse shells don’t exactly work as well in this system due to differences in the process functions in Windows CE, but there are many ways of getting a shell. That egghunter is also still coming, don’t think I’ve forgotten about it, I just want to do some more research into the available memory searching functions in CE before I write that. Many functions in CE have analogues in NT but work very differently, and those differences become important when performing low level tasks.
I’m very excited to be back, excited to get my hands dirty again, and excited to pursue activities I enjoy to manage some of the stress of pursuing an engineering degree. Thank you all so much for joining me on this journey, and let’s hope I can get the train moving again soon!