§ ¶Fixing games for dad
Occasionally, whenever I visit my parents, I end up fixing something on their computer. Yeah, I know what you're thinking, but it's a bit different. My dad's not the most technical guy in the world, but he tends to wait to ask me for help until after he's tried swapping the video card and reinstalling Windows, so the problems I get to look at are a bit more annoying than just clicking a checkbox somewhere. Hardware, he can usually figure out, but it's software that gives him real problems -- specifically, the casino games he likes to play sometimes don't work when he reinstalls them on different machines.
The first time, the problem was that the game was hanging on launch on a second machine. I had thought, bah, it's just an outdated video driver. Sure enough, the installed video driver was ancient, and I updated it, but still no-go. Eventually I ended up running the game under ntsd.exe and discovering that the game was stuck in a QueryPerformanceCounter() loop. It seems that the programmers that wrote the game figured that the 64-bit LARGE_INTEGER returned by QueryPerformanceCounter() always counted up at somewhere between 1-4MHz and hardcoded that fact in a weird way that the game hung in a speed regulation loop when run on an AMD Athlon. I just ended up hacking out a branch instruction in the EXE to fix it.
The second time, different game, checked the video driver again, no go. The symptom was a silent crash to desktop shortly after the game launched -- pretty user unfriendly, but not unusual for a game. I ran it again under NTSD, and I got a call stack with a module called ixvpd.dll on the stack. No clues on a web search. I checked the game vendor's website, and all I found was a lame "codec patch" that apparently "fixes" a codec compatibility issue by uninstalling ffdshow and avisplitter. (Sigh.) ixvpd.dll didn't have a version description block, but a strings search did reveal that it was a decoder of some sort, and renaming it did fix the problem. It turned out to be a poorly written DirectShow-based video codec that came with the software package from a webcam that my dad no longer uses, so I uninstalled that and that fixed the problem proper.
If you think about it, with issues like these, it's no wonder that average people just throw their hands up in the air and say their computer's broken. It's hard enough to tell what's going on if you are a programmer, much less if you're not.
Comments
Comments posted:
How exactly did you "hack out a branch instruction?" Did you use a debugger or disassembler? I'm just curious because I think stuff like that is extremely interesting and I'd like to be able to do it myself one day :D .
ionstream - 12 05 08 - 10:33
Hacking an instruction branch into a binary... that's pretty hard-core... I don't think there are that many programmers who could even identify that issue, much less hack in a solution.
TechMage89 - 12 05 08 - 12:46
Debugger, of course -- NTSD is the NT System Debugger. Sadly, it no longer ships with Vista, but you can get WinDbg.exe easily enough via the Debugging Tools for Windows package.
Finding an infinite loop is pretty easy, since you just have to attach the debugger and break into the process. Stepping out one level at a time until the debugger's step doesn't trip will find the top level loop. WinDbg makes this even easier because it will also decode indirect jumps to system calls, showing calls like QueryPerformanceCounter(). Patching out the branch in memory is then just a matter of either changing the opcode byte to either an unconditional branch or just NOPing out the whole instruction (90 hex).
Once you've figured out the code to patch, there are a few ways to patch the binary. The right way is to subtract the base load address of the module from the location of the patch, then looking up the Relative Virtual Address (RVA) in the section table dumped by DUMPBIN /SECTIONS, then looking up the raw disk offset of the section to determine the location on disk. The cheesy way is to just search for a large handful of instruction bytes in the vicinity. The lazy way is to get a debugger or hex editor that does this for you.
This is, of course, a fairly simplistic case -- in most cases the bug won't be nearly as readily apparent, or it may be impossible to patch the binary due to compression, encryption, or copy protection. An alternate solution that sometimes works is to use runtime patching instead, but that obviously involves a lot more work, and you're still screwed if there's some anti-patching mechanism like Punkbuster or Windows File Protection. Unfortunately, those kind of defensive techniques can also defeat otherwise benign and well-intentioned patches, too.
Phaeron - 13 05 08 - 00:42
For example, some of these anti-patching mechanisms use IsDebuggerPresent() to refuse to launch if a debugger is present. Luckily it can't make the process impossible to attach.
Yuhong Bao - 13 05 08 - 10:55
IsDebuggerPresent() is fundamentally useless as anti-debug-launch protection. Hint: DebugActiveProcessStop() and CREATE_SUSPENDED.
Phaeron - 13 05 08 - 23:31
For the cases where you really need work and find out what some code does, I can recommend
http://www.hex-rays.com/idapro/idadown.h.. , there is a free (for non-commercial) older version too (given the price and their "dislike" of selling personal licenses that version may actually be the only option).
Their graph viewer is crap though, you can use graphviz to create much nicer graphs (there should be some gdl2dot scripts to convert the graph format floating around on the 'net).
And I quite like
http://hte.sourceforge.net for editing, I do not know of another hex-editor with integrated assembler...
Reimar - 14 05 08 - 16:04
The first and (IMHO best) hexeditor with integrated assembler was Hacker’s View
http://www.hiew.ru/
Unfortunately he removed the last freeware version (6.11) from his site…
Daniel - 16 06 08 - 17:09
Comment form
Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
