Killing our tools.

[sna]

there is alot of confusion regarding these scarcely documented structures (TIB/TEB/PEB/PDB). partially thanks to the fact that they dont look the same under different windows versions.

in each Thread Environment Block there will be a pointer to the Process DataBase. see the Wine mailing lists for further discussions and information about the PDB. both the TEB and PDB vary slightly between win9x and winNT so you better know which system your code is executing under before you try to access either of these structure's members.

as for NT-based systems this code should work nicely:

mov * edx, fs:[18h] * * * *; linear address of TEB

mov * eax, [edx+30h] * * * ; pointer to PDB

movzx eax, byte ptr [eax+2]

test *eax, eax

jnz *__debugged

running on win9x, you would need to execute this instead:

PDB32_DEBUGGED * * equ 0001



mov * edx, fs:[18h] * * * *; linear address of TEB

mov * eax, [edx+34h] * * * ; pointer to PDB

mov * eax, [eax+20h] * * ; 32-bit flags

test *eax, PDB32_DEBUGGED

jnz * __debugged

cheers, sna

[AndreaGeddon]

about TEB TIB PEB PDB etc
if you need docs just download kdex2x86.dll, !load it into ntsd and then use the command !strct to have mapping af a lot of internal structures
Bye
AndreaGeddon

[doug]

lame anti-IDA trick (v 4.30)

put junk in the PE header for the "Debug" field. Something that's outside the image.. IDA will crash on this.

I believe that was fixed in later versions.

This trick is used in some protectors, like x-protector.

[+Malik]

I have to say the strangest Anti olly trick ive ever seen was an application that scrambled the display of Olly, though it done this in such a way it made an uttermess of the display. i think the author could have taken the way he effected the text buffers much further by actualy reading threw the Debug data to find point that are critical to its protection and alter some values, and possibly code to Obscure its self. :shock:

Though Easy to pick up if your like myself and use not to popular straight dissasemblers to take a first peak at a target for any Anti-tool tricks. But it may serve as something that would add a few hours to an new Reversers session with his tools :P


Anyhoo yet another rant ops:


Good Health,
+Malik

[Crudd]

Well, i had a crash and lost everything i had done on the project, so i gotta start over. Hopefully ill have a new pre-rel within the month. Keep those ideas and thoughts coming guys
Crudd

[Ben]

Anti-Olly Trick: SMC

Ollydbg litterally Dies when it meets SMC,
it will totally be fucked up, and i mean really fucked up
if u click a line, it won't be focused, clicking other line will select 2 lines..etc hehe very funny

[sna]

one thing you might want to try is to record a trace history. to do so, select debug->open or clear run trace. now the next time you find yourself in the middle of a block of self modifying code, bring up the trace history to get a better overview (view->run trace). another thing that might help is the command line's AT command; use it to disassemble code starting at an arbitrary address.

i don't see SMC as a very big threat to ollydbg since they're able to coexist quite nicely. the idea described by Malik is far more dangerous if implemented properly.

cheers, sna

[kratorius]

You can defeat olly also using calls without ret. Olly gives an error message that can confuse the cracker the first time if he steps the call over (pressing F8 ).
If you step the call with F7 you won't get any problem.
Really easy to defeat, as trick, but useful if you want to make the things a bit more difficult to understand.

[andyistic]

I'll just mention this briefly since everyone already covered this.

I use a program which I wrote to launch the target app.
When I do this, the program gives me various information about the app,
including the PID (Process ID) and Window Callback address.
I can also select which API breakpoints I want to set.
After launching the app, I attach to the app with Turbo Debugger (Win32).
The first thing I do with the debugger is to clear the IsDebuggerPresent flag.
After I tell them debugger to resume execution, I can break the app using the previously set breakpoints, as well as force a break with my launcher program.
Other than checking the timing involved in executing blocks of code,
there's no way the app can tell if it's being debugged.

The challenge of course, is to locate the serial/Cd-Key check code and keygen that part.

[Darawk]

Another interesting trick, that i'm sure many of you have seen, is to call a few instructions into an API function.

You could do this for example:

push ebp
mov esp,ebp
call IsDebuggerPresent+3

When you set a breakpoint on an API function, the debugger sets a breakpoint on the first byte of a function, so doing this, will cause any normal API breakpoints not to get executed.