This fragment is about to be reported (you'll remain on this page):
You can enter a comment to clarify the mistake if you would like to:
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.
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.
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.
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: . 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):
. Usually that field is 2 (word) or 4 (double word) bytes long.
Those bytes look exactly like the string’s length, right? We need to do a quick conversion to check this supposition: hit F11 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 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 .
However, Intel byte order is most widely used (one place using big-endian that I know about are network transfers).
…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!