LabyREnth Mobile 6 Walkthrough

This challenge starts with a file named OGMob.86p. The file extension might be familiar to you, but it wasn’t for me. Taking a look at the file header below we can see some clues. TI86 probably refers to the calculator, and the reference to Asmide86 further supports this. Now I should point out that while some people seem to have fond memories of their TI calculators, I do not. This challenge did not change my position. Why was this included in a Mobile track? Well, I don’t know for sure.

Before we move on, it’s worth pointing out that there are also a few interesting strings near the start of the file.

My personal preference is to do my analysis statically in IDA, repeating a cycle of exploring and documenting code as I go. Your preferences may be different, but follow along and we’ll also get to some debugging options.

We should try tossing this thing into IDA and start poking around. Get it loaded, select the Zilog Z80 processor, and use the defaults otherwise.

2016-07-24 12_25_12-Load a new fileIDA does a reasonably good job of determining an entry point, shown below. But it’s also not surprisingly made some mistakes.

It was unnecessary, but I also went ahead and built my own simple hello world program using Asmide86. This allowed me to confirm the correct entry-point, if IDA had guessed incorrectly.

Our next problem is that many of the addresses, highlighted above, don’t exist within our image. These are probably library functions of some sort, but not knowing anything about programming for TI calculators, it’s time to hope that Google turns something up. Sure enough, we score this file. You would normally include it when writing your TI86 programs, so it contains the constants we need.

Armed with this information we can begin documenting our database. Before we can start labeling these locations, we need to create a new segment (named ‘ext’ below) in our database so that IDA has something for us to label. Label the locations in this new segment to improve the IDA disassembly at call sites. You’ll notice I also relocated the target program, and I’ll explain how I arrived at this location in a moment.

IDA Segments

Without relocating the main program, you would have a problem at the line highlighted above. We previously loaded our application with defaults, and started at address 0. Unfortunately this is a problem because of absolute addressing at call sites. You could deduce your way to the correct alignment without too much effort, but I opted to discover the image base address using an emulator and debugger.

By searching for Ti86 emulators I came across WabbitEmu, although there appears to be no shortage of emulators floating around. I picked this one because it ran on Windows, had a built-in debugger, could transfer programs, and could run user-supplied ROM images. This seemed to address all of my needs in a single package.

WabbitEmu doesn’t provide the actual TI86 ROM, and I’m not entirely sure about the legality of sharing it so I won’t link to it here, but it’s not hard to find. Fire up the emulator with a TI86 ROM image, transfer the OGMob program by dragging and dropping it into the emulator, and launch the program with the command  Asm(OGMob) . Once you do, you’ll be greeted by the following prompt.


You could start playing around with the debugger and stepping through code, but our primary objective here is to determine where this thing was loaded into memory. We can figure this out by dumping ram to a text file and searching for our target module. This is a function of the WabbitEmu debugger.

If you search for bytes taken from the program entry point, within the memory dump you should find the following region of RAM.


Now, I’m not at all qualified to explain how memory works on this architecture, but the impression I got by playing around with the debugger and Googling was that the memory dump is a linear dump of all of memory, but these are not the addresses used by the CPU. The CPU view of the address space is broken into four banks, and banks may be backed by either RAM or ROM data. Really all that matters is that you that you know that in this instance the CPU will map the addresses at 0xD700+ to memory at 0x1700+ (in the linear dump), so we should adjust our IDA database to reflect this new information. Once you’ve done this, you should have a clean disassembly with all absolute addresses falling within the segment you added for TI86 constants, or within our program image.

After the initial program prompt, you’ll find that the following code gets executed. By this point you should have given useful names to the constants in your IDA database, using the include file we discovered earlier. This code follows a relatively simple pattern of fetching a key (remember the includes file previously linked), and comparing it against an expected constant. If they match, it proceeds to fetch more keys and perform more comparisons.

The first check for the [Enter]  key is forgiving, and simply loops back to try again. The other checks are not as forgiving. At this point, with just the code shown above, you know that you must press [Enter]  followed by [Clear] . The pattern continues below.

Follow this through to it’s logical conclusion and you should arrive at the following.

This last check should be satisfied as long as you entered the appropriate key sequence [Enter][Clear](867[Sub]5309) . If you fail, you’ll be greeted by a screen that looks like random symbols. Failure_Screen

If you succeed, you’ll see the key drawn onto the screen.