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.

See runme.dat in the Scenario Runner’s directory? That’s a «scenario» that it runs. Run the EXE. The scenario is simple, as well as the interpreter itself – it outputs a string, then asks you a question and depending on your answer it will either ask you the same question again or output a message and exit.

Your job is to change the strings it outputs – that’s what we do when we need to translate a game, for example.

We’ll go brute force for the start. Open runme.dat in a hexed. You can clearly see some strings like «Make me laugh!» and others. What if we change one of them?

Edit the first string – I made it «Do not cry…» – in this case we have an extra «!» left from the old string – delete it. The file will become 1 byte shorter.

When you edit in a hexed there are two areas where you can do this – on the left you should enter hex values (0-9, a-f) while on the right you can enter letters and other symbols normally. Since we need to enter a «human» string it’s more convenient to do that on the right side.
Btw, you can switch between two sides by means of Tab.

Also, note that there are two modes – overwrite and insert. You can switch between them as you usually do in normal text editors – by pressing Insert key.

Run the exe. Oh huh, we get some exception and also we see that it output some «☺» – while it’s good to stay positive it’s not exactly what we expected to see :)

We probably forgot to update something, for example, a string length. Naturally, the app should know how long the string is. How would it learn that?

Remember about two general types of strings – C-style and Pascal-style. As you know, C-style don’t have any length field, the length is determined on run-time by finding a char with code #0: 32 33 34 00. Pascal-style don’t use null-chars, it rather includes string length before the actual string, which makes string processing much faster (for the cost of having an additional length field but it’s a very low cost):
03 00 32 33 34. Usually that field is 2 (word) or 4 (double word) bytes long.

We need to look around to find where the problem is. Can you do that on your own? :)

Here’s what we have got: 0E 00 44 6F 20 6E 6F 74 20 63 72 79 2E 2E 2E.

Those 0E 00 bytes look exactly like the string’s length, right? We need to do a quick conversion to check this supposition: hit F11 (Tools | Base Converter) and enter 0E in the hex field – it’s 14 in decimal notation. Actually, you could also do this by setting a pointer before 0E and looking at the Inspector under Unsigned Short.
If you’re using a different hexed or something else prevents you from using a desktop notation convertor tool you can use an online base convertor such as this one at i-Tools.org.

A quick intro about how numbers are stored in memory and other locations.
One thing I found confusing about them in the beginning was that they are stored in reversed order, e.g. if we have a 2-byte number and it’s 255 it will look like FF 00 in machine representation, not like 00FF as we’d write it.
In fact, this is called a little-endian or Intel byte order and there’s also big-endian byte order which will look like our normal notation, that is, as 00 FF.
However, Intel byte order is most widely used (one place using big-endian that I know about are network transfers).

By the way, before doing anything on your subject make sure to backup original files in case you mess them up too much – this is always a good habit to acquire.

Update that length and run the script. Wow, that’s cool, we now got a working script! Yahoo!

…well, not exactly as it turns our after a bit of investigation – the script works normally when the second choice is made on the branch, otherwise it will crash. It says that the bytecode is corrupted…

Now I’ll leave you to explore the script with the hexed on your own so you can try to find where the trouble is. When you’ve used up all your deductions carry on to the most fascinating part – debugging :D

Survey (started May 2013): if I were to write an e-book specifically targeting VN translations would you buy it?
I'm a bot • No, I’d just DL it • Yes, for $5 • Yes, for $10 • Yes, for $15 • Yes, for any reasonable price (up to $40).
Please be honest!

Part 2 – IDA assembly »