I was looking at a game from Shockwave and these seem to have interesting protection..

Bypassing the basic isdebuggerpresent I get the usual enter name/key. Interestingly it seems that the main exec (which is loaded in Ollydbg) loads a new thread which is the main name/key checking routine but this routine seems to stop any sort of debugging in the program.

I can't attach to it with ollydbg

W32Dasm simple tries to load and does nothing Doesn't crash or anything.

So the question becomes if the main program creates a new thread under attaches to it as if it is a debugger this would stop me from doing anything..

Ways around this? anyone

I tried to dump the new thread with LordPE but no luck. The New thread doesn't appear in the Memory listing in ollydbg

As a side issue I have also downloaded a java applet game from the same site and found the point where it checks if the game has been purchased. Did a bytecode change to set the flag to true and repacked the CAB file. Now I get errors but the main concern is the cab file originally was 112kb and now is 137kb.
Do java programs have a checksum built in or do I look for a checksum routine?

peterg70

Are you sure that it's a separate thread and not a separate process that is created? Otherwise the thread really should show up in Olly. And you mention that this "thread" attached to the original thread as a debugger? As far as I know threads in the same program cannot debug each other, you can only attach to other processes as a debugger.

If it's a thread, try to find the exact point where the thread is created (break on CreateThread), and see what funny business it performs on startup by tracing it. If it has any debug tricks they will probably be performed relatively near the start of the thread's code.

If it's a process, put a spinning jump at the EP of the target exe, and trace from there to find any anti-debug tricks.


About the java file, what tool did you use to change it? If you used anything else that a raw bytecode patch (e.g. something involving recompilation of the class file), the size of the class file might very well change. Also, if the cab-file uses any compression it is quite likely that the size will change when you repack it, since you might not be using the same algo and/or compression factor when repacking it as was originally used. Any change in the compressed data might of course also change the size even if all compression settings are the same, but a small patch should not change the size as much as you describe if the compression settings are identical though.

And no, there is no "built in" checksum in class files, but cab-files have built-in checksums, so you cannot patch them directly (they are mostly not compressed, so you can see the raw data of the class files inside them with a hex editor and be tempted to patch them directly) because they have checksums on all the data inside them, like most archive programs. Should be a simple CRC32 though, which should be easy enough to patch, but there is no real reason for this since a manual repack of the cab will set all checksums correctly, and if there is any external checksumming, either method will be caught anyway. In that case you must find and neutralize this external checksumming test.