1. Hacking

ErgoHook: Genius ErgoMedia key mapper

Customizes all 36 keys on ErgoMedia 700 including those that the native software cannot reassign.

Yesterday I bought a replacement for my old Ergonomics 4000 from Microsoft (it was fine but after several years keys became tougher to press) – ErgoMedia 700 from Genius.

I was choosing between buying Ergonomics again or this ErgoMedia model and decided to try out something fresh – and the amount of buttons and a 4D-wheel have certainly largely contributed to this decision.

Imagine my er, disappointment after discovering that the native ErgoMedia program was only able to customize 15 buttons leaving other 21 overboard (that’s without the 4D-wheel that can’t be customized).

So I have attempted a quick reversing to see if this can be fixed. To my delight the answer was positive.

«…»

1. Visual Novels

Reversing «Kimi ga Aruji»

General overview of the game protection and some helpful files.

One of the readers of my visual novel hacking tutorial has asked me to check on the protection of «Kimi ga Aruji de Shitsuji ga Ore de» (君が主で執事が俺で). Here goes a brief technical overview and some handy files to help in the translation of this game for those who're interested.

Update: thanks to someone's comment it's now clear that Kimi uses an industrial cryptography which is the same both on its .nsa archives and nscript.dat. Here is located the tool for decrypting them – run it as shdecrkansa.exe arc.nsa decoded.nsa and use any standard NSA extractor like NSAOut from Insani.

nscripter.dat can be decoded in a similar manner except that you'll need to use a hex editor to apply bitwise XOR by key 0x84 on each of the decoded file byte.

And since this is symmetrical cryptography you can encode the edited files back into original format by passing it to decrkansa again.

«…»

1. Computer
2. Delphi

Hooking functions using prologue rewriting

Explains how to hook any WinAPI or other function using prologue rewriting technique in Delphi 7.

This article is written based on a test project that I had made before creating ApiHook – Win32 API hooking tool not so long ago. It demonstrates how to hook library functions – the technique that lies in the very core of ApiHook.

The basics

Let's start with the basic idea. Why we might want to hook, say, a WinAPI function?

Simply enough: if a target process calls that function it will essentially call ours. Then we can decide what we do: we can bypass the call normally but probably record some function arguments; we can also change the return value – for example, if you've hooked explorer.exe and want to hide certain files from the desktop; we can modify parameters to let the original function do something else that the target program intended to. We can even decide not to call any API function or call a different one – because we actually control the execution from the moment the target calls (our) function and until we return from it.

«…»

1. LOL!

Give users no chance to choose

This is a real screenshot resulted after my attempt to start ApiHook – Win32 API hooking tool in full DEP mode (for system and programs). Both buttons says «Yes» and «Yes» – the Microsoft’s way of asking user :)

1. My programs
2. Delphi

ApiHook – Win32 API hooking tool

A full-featured console WinAPI hooking tool written in Delphi 7. Freeware. Open source. Public domain.

ApiHook is a freeware (public domain) open-source program written in Delphi 7 for hooking library calls in Win32 systems. In fact, it can be used to hook any snippet of assembly code in a single EXE file as well but this needs a bit of source code tweaking.

ApiHook lets you track and view information about what functions and how exactly the target program calls. It is implemented in two parts: loader and library. The first injects the ApiHook library into the target process (starting it or attaching to an already running one) while the second does the actual work.

ApiHook lets you examine values of registers the called routine was passed and also capture its parameters (using stored asmESP value) and returned value through them.

The mechanics is simple: you write a script file specifying what actions must be performed when a specific function is called; actions receive the snapshot of the call-time registers and can log them, dump memory blocks or do something else.

«…»

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?

«…»