Reversing a 16-bit NE File Part 1: Clumsy and Unprepared

A friend and I were reminiscing about the hacking we were doing around 15 years ago. It got me thinking about an old AOL cracking program called Sabotage. So I found a copy on an old AOL hacking website. It turns out it had a password so I decided to reverse it over the weekend. The password was available online so reversing it was just for kicks. The following is the tale of that diversion. Names have been changed to protect the innocent.

The program in question is Sabotage Cracker 3.3, available here: 

http://lenshellarchive.com/Progs/aolcrackers/crack.zip

The zip file contains an installer which I unpacked using Universal Extractor. Below is the screenshot showing the 3 folders contained in the installer with the files of each folder.

When we run Cracker.exe, we see the following:

Click OK with no password:

Try a password and fail, we see the following typed one letter at a time in the box, then the program quits.

OK, so far pretty unexciting. We should be able to get the password in no time. It was written in the mid 90's, how protected could it be?

16-bit, Your Tools Have No Power Here

Let's start with identifying what type of file it is with the file program in cygwin.

This is an New Executable (NE), which I have never heard of before this. The NE format was after the old DOS flat assembly format and before the 32-bit PE format.

Let's see what IDA Pro 6.5 can do with this. We should be able to get this done with a few jumps around the code, bada bing, we're done. Here's what we get:

The navigation bar which has been boxed in red shows that the almost the entire program is unexplored by IDA.

IDA correctly identifies it as a 16-bit NE file but only parses a total of 3 instructions correctly.

It's possible to go through the listing and convert the bytes to code or data, but I thought that there's an easier way.

I tried to get some other information statically but the following tools cannot process 16-bit executables: 

• PEView
• PE-Explorer
• CFF Explorer
• Dependency Walker
• PEiD
• Resource Hacker

IDA et al. you had your chance, c'mon OllyDbg, let's get this over with, I want to grab lunch.

                                     

Well right, Olly only handles 32-bit too, but let's see what it does anyways.

So it runs in Olly, but there's no code or memory being shown.

Task manager shows it listed in the applications when run:

Task Manager shows it listed in under Processes but it's indented with wowexec and has no Process ID (PID).

Process Explorer does not even list wowexec or cracker.exe.

However, it does list "ntvdm.exe", which I don't recognize. It turns out NTVDM is the compatibility layer that allows 16-bit executables to run on 32-bit Windows XP. It's a built-in virtual machine, which allows seamless execution of 16-bit executables.

A 16-bit exe run under Windows XP runs under the ntvdm.exe process. To debug a 16-bit process on XP, one must debug it through the ntvdm virtual machine. There is a debugging library built into Windows called VDMDBG.dll. There is an article on that here.  I could not find any debugger to debug the process using the VDMDBG functionality. I'm not sure if VDMBDG.dll implements all traditional debugger functionality like single-stepping.

I did find an article and some code in an article written in 1998. The code is for VDMDBGDemo.exe which demonstrates all the functionality of VDMBDG.dll. This functionality only includes enumerated 16-bit processes and listing modules they have loaded.

This is consistent with the functions exported by VDMBDG.dll.

There may be some undocumented functionality but I'm trying to do a breadth-first search for the easiest way to get a stupid password out of this program. 

Visual Basic 3.0 and Decompiling (from 1993)

A run of strings on the program gives us 15k+ strings, some are relevant, most not. But one of the first is VBRUN300, which is the name of the Visual Basic (VB) 3.0 runtime DLL.

VB 3.0 came out in 1993. There's a copy of a manual scanned and upload here. So this program may be about 20 years old. So this is half a reversing challenge, half an archeological expedition.

Some googling brings me to Dodi's Visual Basic 4 Decompiler, on an Angelfire website, which I didn't know was still around.

Here are the files the decompiler spits out:

Grep those files for the reject string "See Ya!":

Looking at frm1.bas:

We found the good boy string "Access Granted". I don't know Visual Basic, but I looked around a little and couldn't trace back the good boy message to any input string. Now I could learn VB fairly quickly to assist my hunt, but I decided to pause on this approach and return to dynamic analysis.

OllyDbg Round 2

So IDA and OllyDBG were kind of a bust the first time around. I looked into using Bochs emulator with IDA but it doesn't support 16-bit executables. This time I was going use OllyDbg and attach to the ntvdm.exe emulator and try to find my program.

Started Cracker.exe, then opened OllyDbg and attached to ntvdm.exe. After passing back a few exceptions the program is now running and waiting for input. OllyDbg says there is 3 threads. To figure out which one of the threads in ntvdm.exe is the one interacting with Cracker.exe, I click on the cracker window a few times to increase the User Time in OllyDbg. You can see it is the one that is non-zero with a value of 0.6309s. Now I switch to that thread context.

I open the memory map window, there is no sign of Cracker.exe. There is ntvdm and wow32. I know wow is Windows on Windows, another DLL having to do with emulation. I also remember seeing wowexec in the VDMDBGDemo program I showed earlier in the post. 

Next I go to WOW32 in the CPU window in OllyDbg and right-click->Search for Intermodular Calls. Within the listing of calls I look for anything that might interface with the text dialog box or the GUI. After fumbling around with placing breakpoints on a few function calls, I finally get a response on User32.SendMessageA.

I set a breakpoint on all calls to that. Now every time I enter text or click on a button, I hit a breakpoint.

Next I enter a password of "AAAA" and get the message "See Ya!", but one character at a time.

Looking at the stack I see a memory address of 0x0003852E. I know this isn't any known DLL by cross-referencing the memory window. This falls under the segment of 0x10000 with size 0x90000.

It's possible NTVDM always stores the 16-bit file in the memory range 0x10000 - 0xA0000. Running command.com spawns ntvdm.exe too. Checking the memory range 0x10000-0xA0000 returns ASCII that would suggest that command.com is also stored in the memory range. This is useful to know.

I follow that memory segment in the dump window and see some ASCII. I saved the dump to disk through right-click->Backup->Save data to file.

Then run that file through strings and search for "Pass".

We see the string "xSAAAr PassWord and Retry". This looks like my password of "AAAA" overwrote the string "Enter the PassWord and Retry". It also looks as if the string "See Ya!" is about to overwrite the same string. And hitting continue a few more times through the breakpoints does demonstrate that "See Ya!" ends up overwriting the original string. Just below we see the string of "leetness" which is the password.

I knew the password was "leetness" from the beginning so I did everything without using that knowledge, although at the end I wonder if I would have made the final connection seeing "leetness" in memory.

Here's your prize! You get to crack AOL accounts for AOL 2.5, 3.0, and maybe 4.0. I don't remember.

Other Approaches

 I tried Turbo Debugger for Windows 3.1 on a Windows 98 VM but I think there were some anti-debug mechanisms that Turbo Debugger was not equipped to handle or I wasn't trained enough with Turbo.

Conclusion and Future Work

So most 32-bit tools don't work on 16-bit executables, and 32-bit tools are mostly what I have experience with. On a positive note, 16-bit executables can be debugged through OllyDbg by attaching to ntvdm.exe. I hope that helps somebody.

I fumbled through this process but had fun taking a trip down memory lane. I'd like to gather a 16-bit toolset to better tackle this challenge and try again. I just read some good things about DOSBox and it's built-in debugger. Also, Open Watcom has 16-bit tools like a compiler and debugger. I tried them on WinXP but ran into the ntvdm emulation layer problem. So I'll be trying those on Windows 98.

Edit: another picture