One of the members of an ARG I play recently started talking about an old piece of equipment he'd purchased, which supposedly had been used by phone repair technicians to do their work. The equipment in question is an Itronix T5000, which has an in-built modem, speedy 486 processor, and 640KB of RAM. Kilobytes, folks. This was the 90s. You know, incidentally, I fondly remember having 640KB of RAM in my very first computer, and having to juggle peripherals.

Anyways, unfortunately for our friend, when he powered the device on, this is what he saw:

Our friend Mister Argent managed to offload all of the device's files to USB using an available restore feature. He just didn't know how to proceed. Fortunately for him, when it comes to binaries from the 90s, I'm your guy. Now, it's been a few years since my last encounter with something of this nature, and I hadn't realized that most of the tools we used to use for reversing no longer function on today's platforms. A simple strings of the files gave me nothing useful. Interesting, sure, but nothing useful to solve our primary predicament. There is a PASSWORD.DAT file in the collection but it's clearly not plaintext and here specifically, I am nothing more than a hobbyist, and definitely no cypherpunk. I would need to reverse this binary to get anywhere. It didn't take me long, however, to remember the only game I spend time playing these days -- which also happens to be a binary from the 90s -- and more importantly, the platform I use to play it: DOSBox.

If you've never heard of DOSBox, it is basically what you're thinking it is after my description above: An emulator for DOS applications. The thing about DOSBox that makes it special -- besides being the key to many glorious, wonderful games from the 90s that you couldn't otherwise play -- is that the creator has built in a very useful debugger.

I'm a die-hard Linux Mint user, since I can't stand Ubuntu's Unity UI almost as much as I can't stand Michael Shuttleworth. One of the nice things about Linux Mint -- besides the fact that it hasn't immediately jumped into the systemd assimilation chamber -- is that it uses Ubuntu as a base, and therefore has its repositories available for consumption. DOSBox is available in Ubuntu's default repository (and probably in other default distro repos), but if you want to use the debugger, you've got to compile it with a special option, which means building from source. On LM/Ubuntu, you're going to need a few things in order to compile. If you're adventurous, you probably already have build-essential, autoconf, and automake. If not:

sudo apt-get install build-essential autoconf automake

Either way, you're going to need to get the DOSBox dependencies:

sudo apt-get build-dep dosbox

When you're compiling DOSBox for its debugger, you need a curses library. You'll need to install one to continue. Thanks to this answer on Stack Overflow, resolving this on Linux Mint/Ubuntu is a cinch:

sudo apt-get install lib32ncurses5-dev

Next, download the source and extract the source (sorry for the SourceForge link):

wget "http://downloads.sourceforge.net/project/dosbox/dosbox/0.74/dosbox-0.74.tar.gz"
tar -xvf dosbox-0.74.tar.gz

Next we'll build our awesome DOSBox debugger, but something you should know here is that DOSBox actually comes with two "levels" of debugging capability. Compiling with --enable-debug will get you most of the debugging features, but there are a few important ones you'll want the convenience of by compiling with --enable-debug=heavy. Most importantly, this "heavy" debugger enables the heavycpu command, which is a hardcore CPU logger that makes following code a lot easier:

cd dosbox-0.74
./autogen.sh

At this point, we're going to need to modify the source a little bit to prevent some errors in the actual compilation. Thanks to this helpful post by the DOSBox author, we know exactly what we need to change in the source to prevent the error. Let's create a little patch file to do the work for us. Create a new file in the dosbox-0.74 directory:

vim ./dosbox-0.74.patch

Paste the following contents into the editor:

diff -rupN dosbox-0.74/include/dos_inc.h dosbox-0.74.patched/include/dos_inc.h
--- dosbox-0.74/include/dos_inc.h	2010-05-10 10:43:54.000000000 -0700
+++ dosbox-0.74.patched/include/dos_inc.h	2015-07-07 14:52:42.057078234 -0700
@@ -28,6 +28,8 @@
 #include "mem.h"
 #endif
 
+#include <stddef.h>
+
 #ifdef _MSC_VER
 #pragma pack (1)
 #endif
diff -rupN dosbox-0.74/src/cpu/cpu.cpp dosbox-0.74.patched/src/cpu/cpu.cpp
--- dosbox-0.74/src/cpu/cpu.cpp	2010-05-12 02:57:31.000000000 -0700
+++ dosbox-0.74.patched/src/cpu/cpu.cpp	2015-07-07 14:52:23.641077942 -0700
@@ -30,6 +30,7 @@
 #include "paging.h"
 #include "lazyflags.h"
 #include "support.h"
+#include <stddef.h>
 
 Bitu DEBUG_EnableDebugger(void);
 extern void GFX_SetTitle(Bit32s cycles ,Bits frameskip,bool paused);
diff -rupN dosbox-0.74/src/dos/dos.cpp dosbox-0.74.patched/src/dos/dos.cpp
--- dosbox-0.74/src/dos/dos.cpp	2010-05-10 10:43:54.000000000 -0700
+++ dosbox-0.74.patched/src/dos/dos.cpp	2015-07-07 14:52:11.929077757 -0700
@@ -31,6 +31,7 @@
 #include "setup.h"
 #include "support.h"
 #include "serialport.h"
+#include <stddef.h>
 
 DOS_Block dos;
 DOS_InfoBlock dos_infoblock;
diff -rupN dosbox-0.74/src/ints/ems.cpp dosbox-0.74.patched/src/ints/ems.cpp
--- dosbox-0.74/src/ints/ems.cpp	2010-05-10 10:43:54.000000000 -0700
+++ dosbox-0.74.patched/src/ints/ems.cpp	2015-07-07 14:51:59.081077554 -0700
@@ -32,6 +32,7 @@
 #include "setup.h"
 #include "support.h"
 #include "cpu.h"
+#include <stddef.h>
 
 #define EMM_PAGEFRAME	0xE000
 #define EMM_PAGEFRAME4K	((EMM_PAGEFRAME*16)/4096)

Now save the file and exit, and apply the patch you have just created:

patch -p1 < ./dosbox-0.74.patch

Finally, compile DOSBox:

./configure --enable-debug=heavy
make

I've already got DOSBox installed, and so I chose not to install over it with my debugger-enabled version. But if you don't care, go ahead and place your newly-built debugging DOSBox version into your executables directory:

sudo make install

Awesome! We've got a bitchin' debugger! The second part of this story will cover the password discovery process using our fresh-from-source DOSBox debugger.