Did you call us? We are – the Imported Ones!

Strings are beacons but there's also another thing – imported functions. Imported functions also connect us to the program source code, although in a bit more subtle way than strings because we don't exactly see them on the screen but rather feel them being used somewhere in the core hehe
Tables of imported functions are number one target for exe protectors – they implement some tricks so debuggers and disasms like IDA and Olly won't see those functions… without extra effort at least.
This table is simply an array of DWords – Pointers to each function's first instruction – thus, target for CALL (in rare cases JMPs can be used in place for CALLs – this is usually the behaviour of Delphi's compiler).

For example, a program draws something on screen – some text. And the text that this program outputs just doesn't look good when used in another language – particularly, this is often an issue with Japanese games which use monospaced square fonts – for Western languages they look unnatural at best.
So we want to replace the standard font it uses. We know that there's an API function CreateFont() which among other things accepts the name of font to create. We search for it, fix the name – and voila! The game displays neat font for our language.

Another bit of info regarding functions. On Windows there are two versions of almost each system function: ending on «A» and on «W» (e.g. TextOutA and TextOutW). «A» stands for ANSI while «W» stands for Unicode (also called «Wide» because each symbol takes up 2 bytes instead of 1). In NT 5.0+ all functions ending on «A» AFAIK are just wrappers for «W» since the OS core operates solely on Unicode.
Functions that don't have any suffix after it are used in VS header files to easily switch between A/W versions by defining a directive like UNICODE. In system DLLs such functions don't exist.

Let's get more specific to our problem. We need to find a function that is the interpretator's loop – since general idea of a script interpreter is to have a loop which reads instructions from a script, have some switch..case block (or in Delphi this is just case) and… well, we'll see what's next once we find that.
At least we'll know what functions does the engine support and what their opcodes are (in a few words, opcode is an index of a function which that interpreter recognizes and eventually «interprets»).

To give you an idea here's a sample interpreter's loop written in PHP (as a compromise between C++ and Delphi :P):

function RunScript($script) {
  $pos = 0;
  while (strlen($script) > $pos) {
    switch ($script[$pos++]) {
    case 0:
      WriteConsole('A message: ', ReadStrFrom($script, $pos));
      break;
    case 1:
      $varName = ReadStrFrom($script, $pos);
      SetVar($varName, ReadConsole());
      break;
    case 2:
      $scriptName = ReadStrFrom($script, $pos);
      RunScriptNamed($scriptName);
      break;
    ...
    default:
      throw new Exception('Unknown command opcode '.ord($script[$pos]));
    }
  }
}

Of course, better code would use named constants instead of magic numbers (opcodes), encapsulated script traversing and so on but the above code is just an example anyway.

I suggest this approach: we find calls to ReadFile, set BPs on them and watch something to happen.

Open Imports tab (Open | Subviews | Imports) and type on a keyboard first chars of the function name (if you press F1 you'll get some help on IDA's lists, they have a few handy features like searching by Alt/Ctrl+T)… Aha, gotcha.
Let's press Enter – IDA has transferred us to that function's record in the import table – but since we need code that refers to it, not that record let's press Ctrl+X – great, here's… only one place? That's strange but it's Delphi after all and I mostly deal with C* programs.

Go to that part. Ah, we see some kind of a wrapper function: asmJMP DS:__imp_ReadFile. We need some real code so let's find what refers to this function, then – Ctrl+X. We got another two matches, great. Go to both and set BPs there.

For some reason there's also a second entry in the imports table for ReadFile – I dunno why there are both of them, maybe it's some compiler trick but that's not a problem – set a BP there too.

By the way, one wonderful feature in IDA is its Graph view. It doesn't work for first-level «functions» (for the reason they are not functions) but most of functions are subroutines so it will work most of the time. If you're not in Graph view yet try pressing Space – if IDA complains just keep on trying each time you enter a new function and eventually it'll show up a bunch of nice code blocks.

Now I have 3 BPs set. Let's roll! F9. Catch! Let's review what we need to find once again: it should somehow hint on connection with runme.dat. Let's see which arguments ReadFile has… file handle, buffer and bytes to read are those beacons.
File handle is, sure, the best connection we can have since it's an unique ID of any file but to match it to a real file on disk we'll need to know the ID of that real file – it's returned by CreateFile and is different each time. We can set BPs on CreateFile calls, note when it is called with lpFileName = '...\runme.dat' and note down somewhere the file handle it returns (btw, do you remember that functions usually return their result in EAX register?).

OllyDbg has very handy Handles window for this kind of things – there you can see all handles opened by the program (as numeric values) and their string representations – and not only for CreateFile but for other functions too. However, we're in IDA now so let's carry on with it.

However, this is complex and we're either lazy (lazy programmers, duh) or we just want to avoid doing more steps than necessary (since that's something we can always make up for). At first we'll examine other signs – we have bytes to read argument left, and also buffer. Well, let's try bytes to read.

Let's see, our first catch has hFile = 0x4C (doesn't tell much) and nNumberOfBytesToRead = 0x0142. Let's hit Shift+/ and open IDA's calculator, which can also be used for base conversion (although 010 editor's tool is more convenient to use). Let's enter 0x0142 = 322 in decimal, which I suspect… Eureka! Check the size of runme.dat – it's exactly 322 bytes. How handy, the program reads the whole file into the buffer (so it seems).

Well, to tell the truth, you'll rarely get such a coincidence – at least not on the first call to ReadFile, because files usually have some kind of header and signature, which are a dozen of bytes in size. But if you keep on watching ReadFile calls you may eventually find that a program reads some large chunk of data – and if you compare it with size of some file you might see that it differs only in a few tens of bytes.

We got lucky, our test subject is naive and goes straight into our arms reading that whole script into the memory

Now it's time to track down what it's gonna do with all that data it has just read.

The exe is paused before ReadFile call – let it fly by F8 but before you do that open the register that's PUSHed as lpBuffer in a new window of IDA – right-click on the register name and use the context menu or just set the cursor on it and hit Ctrl+Enter (if you press just Enter it will open it in the same code window). You can go back any time by using Esc.

Now we're looking at the memory area that will have the contents of the file read into it. Let's finally press F8 – we'll instantly see that that area is now filled with data – our precious scenario bytecode. It's just about time we use hardware breakpoints.

Hardware breakpoints allow us to set BPs without modifying the program's code (even in memory). Since normal BPs are set by writing asm instruction INT 03 before a command to break on they can in some cases be real break points since the program doesn't execute this code, it only reads from that location (such as a string in memory – it doesn't run string's byte values as an asm code, it only accesses them).
Hardware BPs are CPU's prerogative and a number of BPs you can set at once depends on your CPU type. Generally you can count on at least 4 hardBPs – usually even more, near 8.
Still, 4 are usually enough since you can put normal BPs on executable code without any limits.
Also note that unlike softBPs hardBPs are triggered after the trapped statement or inside it (if it's a complex command like REPE MOV* – in simple MOV or CMP they're triggered after the instruction).

Don't forget to delete BPs that were set in memory locations after the debugged program terminates (unless it's global app memory but that's not important in our simple case) – since memory addresses usually change each time program starts you'll need to re-set all memory BPs each time you start it from the debugger.

Go to that buffer window you've previously opened and set the cursor somewhere inside that lpBuffer (or on its first byte), click F2 – IDA will likely check hardware BP flag for you already. Mode should be Read.
We don't need anything anymore from the BPs set on ReadFile calls so you can remove them – although I suggest simply disabling them (from their context menu) so you can get back to them quickly if necessary. You can open Breakpoints tab by Ctrl+Alt+B or by Debugger | Breakpoints | Breakpoint list menu command.

Now press F9 and wait until something happens… Here we go – «Hardware breakpoint... has been triggered». That's great, let's see what we've got here…

REPE MOVSD. Well, that looks scary but it's simply an asm instruction that copies a block of memory from one location to another. If you want some info, e.g. how many and to where does this instruction copy open up the docs I've uploaded (N-Z.pdf – that's Intel's manual) and search for that instruction there (I use simple FoxitReader's Search since the links in PDF's contents only work for A-M.pdf).

We can now undertake a challenge of setting BPs on every REPE instruction we get unless we hit something useful or run out of hardBPs but we'll go another route – let's just press (or better hold) F8 unless we find something of interest. This way (holding F8) we'll go up the call tree towards the root because we won't go into new functions (we're not holding F7) but will return from all subroutines gradually. On the road we need to keep our eyes open so we can catch something of value.

…after nearly five functions I got tired of this so I decided to press F9 again – maybe we'll find something faster in another part. IDA has shown me the same function again, just another branch. Okay, let's be more patient this time…

After a dozen of returns I stumble upon some Graph which looks like a case statement.

See those boxes going from one root and then joining together on the bottom? If you think about it, that's exactly how a case statement can be visualized.

IDA has even identified it for us (Olly can do this too, although not like these neat colorful blocks) by putting comments like «switch jump» all around the disassembled code.

Can it be the interpreter's loop we're looking for?

Let's look at the comments and strings we have in this function. Hmm…

You can use Ctrl+Wheel Up/Down to zoom, «1» for 100% zoom and W to fit-window zoom.

Well, so far the code doesn't tell me much about its purpose. One thing that looks interesting for me is a referenced string that says «opcode %.2x» – btw, let's take a note where it is used and why we don't see it in the console output.

I've got an idea, I'll disable all BPs for now and set one in the beginning of this func… no, rather at the case's beginning – like IDA says, it's here:

asmJMP     off_41374A[EAX*4] ; switch jump

A word on case statement mechanics and why it can't accept strings as keys in compilable languages.
You might think that case statement is exactly the same for computer as a series of IF statements is – and thus you might wonder why a compiler says that it can't take a string as a case variable. I also thought case was the same as if+if+if+... but for compilers it's totally different. Each case label is actually an index in a «jump table». Such a table is simply an array of addresses. Since a case statement accepts integer values, you can use those values as indexes for that array-of-addresses – thus there's no need to compare anything more than one time, no need to compare anything at all – just call asmJMP caseArray[caseValue] – and you're done!
In the above code fragment, for example, off_41374A is nothing else than base address of that array – and EAX is caseValue, which should be multiplied by 4 because every address in 32-bit CPUs is also DWord – in another words, 4 bytes in size.

So we put a BP there and hit F9. Let's look at EAX register (you can either look at it in General registers window or wait until IDA shows you a hint when you put a mouse over EAX).

Once IDA has shown you that memory hint you can use Wheel Up/Down to show more/less lines.
You can also hover over many other places – like values in General registers tab.
Also, be sure not to hover on off_41374A[EAX*4] statement – only on the separate string «EAX» (somewhere in the code above or below) – otherwise IDA will calculate address (off_41374A + EAX * 4) and show hint for that location rather than the value of EAX.

IDA shows that EAX = 0x01. This doesn't tell us anything, probably yet. Let's roll back a little and review how EAX gets this value. What we see is (try to guess what it does before reading on):

asmCODE:00413735 CALL    sub_413AA0
CODE:0041373A XOR     EAX, EAX
CODE:0041373C MOV     AL, BL
CODE:0041373E CMP     EAX, 6           ; switch 7 cases
CODE:00413741 JA      short loc_4137B5 ; default

Firstly, we clear EAX by XOR, then we set its lower part (AL) to some value of BL (as you remember BL is a low-word of 16-bit register BX which is itself a part of 32-bit register EBX). We need to track how BL is set.
But before we go further let's rename the function we're in now – I named it «$InterpretInstruction».

…And now let's take a break and breathe in deeply a few times.

What do we need to do? I mean, what's our goal with this program? We want to change script lines and as we do this it crashes. So we need to (or must, if we're pressed by the editor) find why.
To think about it, I've almost rushed into finding which function actually sets that instruction byte into the place – but that's not necessary to know. One thing we really need to know is what to do with that code, not to find which one of those zillion disassembled functions picks that code from bytecode stream.
Interestingly, we might eventually find that function on our way but doing so now is not required and will be a waste of time. That's IMO.

So we'll skip to the next part. Let's assume that we have found the interpreter's case statement. We can verify it in a few ways but since it's a tutorial I'll show you how Olly can help us with its great BP logging functions.

Let's turn the page of our enlightenment to the new level now…

Part 4 – getting to the Crash Point »