Here's what I'm doing.

Having already beaten Star Wars: Knights of the Old Republic II, I wanted to go back through and see a few different storylines.  Thing is, I don't want to waste my time actually beating the game again.  Turns out there are some cheat codes that can be entered and you can do stuff like give yourself uber strength and constitution and all those other characteristics.  These codes can be found here (note: beat the game first, it really isn't that hard :P)

Anyway, having done that, I'm running into a problem.  When I land at the Telos polar region where the hidden Jedi base is, I'm getting stuck.  Atton and Kreia aren't getting locked up in the cells as they're supposed to, and when I try to talk to Atton, he gives me these odd "Cheat Node" options:

[img]http://www.armabot.net/pub/kotor2.jpg[/img]

The first option initiates the conversation with Atris.  The second option does nothing.  Talking to Kreia does nothing.  After you talk to Atris, you come back to them and find Kreia meditating and Atton lying on the ground as if dead.  However, talking to Atton results in the same options; Kreia still does nothing.

Long story short, there are several problems:
1.) I can't disassemble swkotor2.exe.  It patches its own memory through (I believe) a file called Patchw32.dll, which is never directly referenced as far as I can tell.  I think it might be auto-loaded through the PE header because when I load swkotor2.exe into IDA, some memory locations can't be found (on jump instructions), but when I execute the program in the debugger, IDA detects that memory previously thought to say one thing now says something else.
2.) I can't start the program in the debugger successfully; it says that a security file can't be found (I presume it has problems loading Patchw32.dll).

I'm looking for the part of the file that determines whether it says "Cheat Used" in the picture when you're loading a game.  I suspect that if I can set a break-on-access there in WinDbg (which also cannot run swkotor2.exe, but is okay if I attach after load), I might be able to change that value so that it doesn't think I cheated.

Any thoughts as to how I can start?  I'm decent with disassembly, but my debugging skills at this low-level are very limited, and despite having read "Hacker Disassembling Uncovered" a couple times, I still don't quite grasp rewriting process memory.

Check if the exe is compressed/encrypted. Many copy protections do that. If that's the case, the easiest solution is to download an unpacked and cracked exe for the game which will then be easily debuggable.

[quote author=Adron link=topic=11388.msg109880#msg109880 date=1114459662]
Check if the exe is compressed/encrypted. Many copy protections do that. If that's the case, the easiest solution is to download an unpacked and cracked exe for the game which will then be easily debuggable.
[/quote]

It seems like the EXE *is* compressed/encrypted already -- there are a lot of db statements in IDA.  I guess I want to figure out how to decrypt/uncompress the EXE myself.

Unless this is a different patchw32.dll then it has nothing to do with copy protection. Patchw32.dll is used to upgrade the game itself when a new patch is released. However this is from a different game but I suspect the same is true.

You might try Ollydbg and the HideDebugger plugin for it which will hide the debugger from IsDebuggerPresent as well as some other ways of detecting the debugger. This would allow you to load the game with the debugger.

[quote author=MyndFyre link=topic=11388.msg109904#msg109904 date=1114468446]
It seems like the EXE *is* compressed/encrypted already -- there are a lot of db statements in IDA.  I guess I want to figure out how to decrypt/uncompress the EXE myself.
[/quote]

Decrypting / uncompressing an EXE protected by a copy protection scheme is not a good task for a "newbie" such as yourself. If you decide to do it all by yourself, you'll have to spend a lot of time studying it and may still not succeed.

I would definitely use an already unpacked exe; there are tools used to unpack the exes, written by people who spent the time needed to figure out the protections. The code used in the exe itself is typically hand-written assembly, designed to be hard to debug and hard to understand.

Well -- good news.  After replaying the discussion paths about 50 times, I got the right sequence to make the actual storyline happen rather than what was happening.  So it's moot.  :)