Update: Folks, I’ve encountered two issues that are going to delay the next part of this subseries by a bit. First, the OpenZDK Client for Debugging seems to have been erased from the internet. I can still build programs, but this means that I will have to write my own network based debugger. I’ve written small, simple windows debuggers before, so this should be a fun challenge, but it will take a while.
Second, to prepare for my position this summer, I’m learning Android Linux kernel exploitation. This will be very helpful for Zune exploitation, but it will also take a large chunk of my time. …
This concept is kind of a shaky basis for a full article, so I decided to make it a mini article.
Those who read my last article will remember that while fuzzing Windows Media Player for Pocket PC, I ran into trouble restarting the program:
At the time, I accepted this as an inherent difference in Windows CE resource allocation. Recently, however, I discovered that was not the case. I managed to successfully extract Windows Media Player for Pocket PC and started reverse engineering it. What I found intrigued me.
A short while after I posted my last article, tragedy struck. My Windows CE 2.11 palmtop broke traveling between floors in my building.
Fortunately, I had a backup plan. My HP iPAQ Pocket PC was ready to go.
My palmtop breaking may have actually been a good thing, because it meant that I was finally free of Windows CE 2.11 and ready to move on to a more modern OS, Pocket PC 2003.
Pocket PC 2003 sports modern features like:
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!), …
Author’s Note: I’ll be cross posting this article here and on augustomalnalysis.home.blog. I’m transitioning away from Medium due to the premium membership requirements for readers.
I decided to make this article after struggling to set up simulated networking on my own malware analysis lab due to outdated guides. I realized that an updated guide may help some people. This guide is also related to an upcoming series where I demonstrate static analysis, dynamic analysis, and memory analysis of kernel mode rootkits.
This guide requires:
I want to preface this article by saying that if you’re like me, new to malware analysis and on a budget, studying without access to course materials may not be the best option for you. The best way to pursue the SANS GREM certification without a source of funding for the course is to apply for the SANS Work Study program for the FOR610 course. In exchange for assisting the course instructor, you will be allowed to evaluate the course and attempt the certification exam. You will also be provided copies of the books and course materials, which cannot be acquired any other way due to SANS policy on sharing of course materials. …
Author’s Note: When I say that shellcode is ASCII formatted, I’m referring to functions that accept ASCII strings. Two of the characters used in this shellcode are not valid ASCII characters, but they’ll get past strcpy and most other ASCII string functions that are just looking for a null terminator.
I’ve decided to make this part of the series an interlude because it wanders a bit outside of the scope of the main series. While I may not be able to apply the shellcode I’ve developed in this article to Windows CE 2.11 Unicode filtered buffers, I figured it would still be useful to release it. This is because this shellcode can be adapted for use in vulnerable text buffers on SH3-based embedded machines running Windows CE 3.0 .NET to 4.5. This covers a variety of equipment including older models of popular voting machines (I don’t want to mention brand names but some are still in use, check for surplus on eBay), warehouse barcode scanners (eBay), oscilloscopes (wherever oscilloscopes are sold), and PDA’s (try a thrift store). …
Author’s Note: This shellcode was produced as part of a PoC exploit for the buffer overflow found in this article:
This is a long article, but I figured some people may only be interested in the principles behind analyzing parameters to create shellcode, the shellcode itself, or the difference between this shellcode and other Windows CE shellcode. For this reason, I broke up the article into sections with bolded headers. I hope you enjoy it!
I decided to include the word “philosophy” in the title because like the vast majority of shellcode examples for Windows CE (three out of the four in existence, now four out of five), this example is not actionable in the majority of cases. However, it can easily be transformed into actionable shellcode. This is because my example is not in Unicode (Windows CE 2.0–3.0) or ASCII (Windows CE 3.0 .NET — Present) string format. For this reason, it will only work in cases where the input is being copied into memory. …
Welcome back to SH3 exploit development! Sorry if this part of the series is a bit more informal than the last few. I’m very excited and I want to show you all everything. I’m just going to get into it, I found another buffer overflow that overwrites the PC, but this time there’s also ample space in memory to store shellcode, and I can actually point to it!
This isn’t the only program I’ve been testing while I’ve been gone. Freeware Windows CE 2.11 programs seem to be lousy with buffer overflows. There’s no SEH and program exception handlers can be bypassed without much effort. The main obstacle in is that the vast majority of these buffer overflows are Unicode filtered. …
Author’s note: This article is part of an ongoing series on Windows CE SH3 exploit development, and is focused on the continuation of research and clearing up mistakes from this article:
I was for part 3 of this series to be a post where I cleared up some of the mistakes and misinformation I spread last time due to my limited knowledge of the SH3 architecture and RISC exploitation in general, then triumphantly presented my skeleton (pre-shellcode) exploit and talked next steps. …