1. Computer
2. Delphi

Never return PChar in Delphi

This is a follow-up on my previous post «Trouble with UTF8Encode» where I've run into a trouble I didn't feel was solvable. Surprisingly enough I've run into the solution in turn much sooner than I expected.

Intro

Several days ago I was putting my SQLite wrapper for Delphi 7 in real-life use rather than a demo application and have during the process had stumbled upon a very weird behavior: it kept doing something that prevented SQLite from opening a database. It wasn't something serious, I thought, perhaps I've locked it in some place earlier. However, as I've moved through the code I was understanding that there was no such place.
In the end, after more than an hour of debugging and commenting things out all around the weirdness has hit the apex: everything worked fine if I'd add an extra character used in some completely different part of program and it would say «Cannot open the database» if I'd remove it.

And then I made some change that made sqlite3.dll crash with an Access Violation. «Whoa,» I thought, «thi is no more my app; what's wrong with this thing?». And I've fired up IDA Pro.

«…»

1. Hacking
2. Stage Once

Epilogue

A parting word and a list of things you can test your newly acquired skills on :)

What can I say now? If you've reached this point and managed to make the program work – you're a real man :)

There are still a lot of places to apply your newly acquired knowledge and skills to. ScenarioRunner has a few Easter eggs hidden inside. I strongly suggest you either keep on messing with it or, if you feel like you need some more exciting stuff, get a visual novel and try to reverse its script formats.
You can pick something from the list of my tools at http://vn.i-forge.net/tools/ so if you've run into a problem during reverse-engineering you could ask me for a hint (either via comments here or by e-mail).
However, I'd advice to deal with ScenarioRunner while there are yet things to discover.

Here's what you can do with ScenarioRunner.exe on your own:

• Remember that suspiciously-looking string «opcode %.2x»? Actually, if you look over the entries under Names subview of IDA (click on Name column to sort the list) you'll find other interesting strings (they should have also been listed in Strings subview but IDA either doesn't catch Delphi strings or it doesn't catch Unicode strings).
  For example, aReadStrOfLenD – what's this for? Why none of them show up anywhere? You can investigate this – maybe it will help you in tracking down crashes in ScenarioRunner or give some insight into its innerworkings, who knows?
• You can undertake a challenge of understanding every opcode function. We've already got the notion of 04 opcode and I'm sure you've understood a few others but there are at least 3 of them left – and also that strange 06 case branch – what is it for?
• Try to translate every other string in runme.dat – there are 6 lines in total, including 2 question strings. We've already translated the first line. There's a surprise awaiting you when you modify one of the remaining lines – you'll need to dig into disassembly or put deduction in action to solve it :)
• Just for fun, try quickly finding out how to make ScenarioRunner.exe execute an arbitrary scenario file, with any name other than runme.dat.
• Can you make your own custom scenario (or modify existing one) so that it would do things you want it to do? I made this runme.dat from scratch in a hexed – can you do something similar? It will likely require knowledge of most opcodes – and it'll be a lot of fun :)
• And an ultimate challenge – try writing a complete decompiler of ScenarioRunner's scenario files and even a compiler if you want. Or at least try to make a translation tool like those on my page – which will extract texts from a script into a text file and update texts inside the script based on lines in a text file.

«…»

1. Hacking
2. Stage Once

Part 5 – the final act

Unwinding the loop reaching the top.

And the last step to the win… to the top of Olympus!

I assume you did find that place where that number gets used in some obscure operations. It looks like this:

Now it's time for some last tips before you fly on your on. Let's take a look at EDX in the line with «>» in front – clearly, it's 0x12, exactly that number we were trapping for. I got curious and peeked at memory at [ESP+0Ch+var_C] – well, nothing like our bytecode from runme.dat, that 0x12 is all alone there.
But it was copied from our bytecode, which we can confirm because we put hardware breakpoints on places originating from runme.dat – so we don't care why it ended up here separated from its pals. And now it got copied to EDX and something was called – we need to see what that function does.

Luckily for us, the code seems well-written so the functions are small and this one looks particularly small – just step inside (F7) to confirm this. Actually, it only runs 6 instructions including RET – how handy!
Here's how it looks in our case:

«…»

1. Hacking
2. Stage Once

Part 4 – getting to the Crash Point

We're getting really close to solving the problem with string of different length!

And then Olly the Mighty stood up and said: «I am the king of this mountain!».

I assume that you already have OllyDbg (it's free). I am using v1.1, although there's v2.0 already but it still doesn't have all the features v1.1 has so I'm waiting.
Let's open it up and load ScenarioRunner.exe in it.

Since we've already analyzed quite a lot of code with IDA this task will be a piece of cake for us. Copy the address that IDA shows in disassembly listing on the left of JMP instruction (case statement start), for me it's 00413743. Hit Ctrl+G in Olly and put in there.

We see something similar. Even more, since Olly doesn't show the code as a graph we even see the case table right under the JMP instruction – remember that sidenote on case and IF statements?

«…»

1. Hacking
2. Stage Once

Part 3 – finding Clues and The Case

How to find our way in megabytes of asm code? And how do games actually execute scripts? Answers are here!

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.

«…»

1. Hacking
2. Stage Once

Part 2 – IDA assembly

Getting serious now - launching IDA and learning an introduction lesson into assembler language (ASM).

Alright, here we are. Debugger is an incredible thing that allows us to read people's minds… Ahem, yes sorry for being a little offtopic :)

Let's get and unpack IDA Pro somewhere and load ScenarioRunner.exe into it. It will show a dialog box about its file type, hit Enter.

Most of the time I use IDA because it has much better capabilities than OllyDbg when it comes to giving names to memory locations, functions, etc. – Olly doesn't have any of this.
However, Olly has very good breakpoint logging, plus patching functions and many other features that IDA lacks (or is limited in) so sometimes I use Olly as well – we'll use it too in later chapters.
However, at the beginning I use IDA.

After a few sec IDA will disassemble the exe, you'll notice it has finished when a bulb on the right of the third panel row from the top changes color from yellow to green.

«…»

1. Hacking
2. Stage Once

Part 1 – the Bruteforce

Preparatory stage - our first try where we attempt bruteforcing a scenario.

VN hacking. That's a very interesting and broad theme, much because of its puzzles that sometimes actually make our mind work very hard :) I'll try to show you the basics of RCE and hacking overall in this chapter.

The test script interpreter is here. Download it now but try not to look at the source code yet :)

What we need now is a hex editor. If you don't have one I suggest you get 010 editor (a trial will do for now) – some time ago I used WinHex but it sucks when working in Japanese locale – it almost becomes unusable. I tried this packed-with-features tool and it turned out to be quite good.

So let's begin.

«…»

1. Hacking
2. Stage Once

«Stage Once» – a Visual Novel hacking tutorial

A full-scaled guide to hacking a simple scenario runner requiring no initial knowledge of what Reverse Code Engineering is.

I became interested in visual novels (and anime) much earlier than I became interested in hacking them for translation purposes. This happened near September of 2008 (I still remember the month because that's the time school year starts lol).
When this happened I suddenly found that I'm able to understand those messy lines of what seemed like totally unmanagable assembler code beforethat came out of OllyDbg almost scaring me to faints. I've set up a page with my visual novel (or shortly – VN) tools which is still located here, although I'm planning to significantly improve it some day.

I wrote this tutorial to one of my Internet friends with whom we had intensive chat for several months (which resulted in more than 200 forum posts, some of which were 60-90 KiB in size – pure ANSI). This guide is intended to give an all-round view of how reverse-engineering (RCE) is performed. It requires no knowledge learnt beforehand – maybe except for more or less common mechanics of how computer works and what WinAPI is. You don't even have to be able to write assembly code – you'll learn this and more things as you go through the pages.

It's ironical that none of people (by the time of this writing – two) whom I've send this guide to actually completed it – albeit they've asked themselves if I can teach them some hacking stuff. In fact, I don't know if they have started at all, haha… Well, nobody is to be blamed for this, of course.
But, still, I would highly appreciate any feedback that you might drop in the comments!
Or if you prefer forums – welcome to ours :)

Oh, and yes, if you spot a typo or a mistake while reading the tutorial please select it in your browser's window and press Ctrl+Enter – it'll send a message to me so I can fix it. Thanks!

«…»