Greets,

I'm working on a proggie (written in BCB, packed with ASPack, I have manually unpacked it) and have been stuck on a problem for days, when I run the proggie standalone, it pops up a message box first, then goes on, but when I load the proggie into Olly, the message no longer pops up. Obviously it detected the debugger (or loader), I also tried to locate the normal anti-debug things like MeltICE, IsDebugPresent, etc but no luck. Can anyone point me a way to solve this problem? This popup is important, cuz the IDA shows the procedues after this popup are critical to proggie running.

Thanks in advance.

there are several things ollydebug cant deal with
two examples

1. fs related things
fs has to do with thread information block / thread environment block / process environment block
fs:[00] holds for instance the error handler

2. the program may load kernel32.dll and jumping to the (undocumented) routines directly
if you choose trace into ollydebug may hold on in the dll code
if you choose trace over, the program could make a "pop" and so never return

a solution could be to place a "jmp toitself" what means "EB FE" in the file, execute the file, attach ollydebug to it and replace the EB FE with the former values
so you can trace the way of the code the program follows

CU Snej

Hi Snej,

First thanks for yr reply. I think yr first guess is most likely the cause of the problems, cuz I've found tons of fs:[0] codes in the program. I have to say that Im not familiar with SEH things (Im learning it though), after some tests, Iv found that BCB generates such codes to handle exceptions, and one thing confused me is: if I keep hitting F8, the program can pass thru the codes (which contain the "mov fs:[0], something" withouth problem, however, if I set a breakpoint after the same code and press F9, Olly stops with an exception, is this normal ? Is there any general rules on dealing with programs that have such fs:[0] things?

Thank you.

Hi crknoob

this with fs:[0] behavior of ollydebug I described in the bug section over a week ago - but there is no answer yet
I hope this will be fixed in 1.10 or later

in my post in the bug section there is also a link about exception handling which may be useful to you

Iīm not into these things so I canīt tell you more

CU Snej

I also noticed the program uses Process32First and Process32Next to check something, I heard this is a way to detect if the process is loaded by loader or running standalone, but I don't know how this is implemented, can anyone describe this in a bit? A link will also be very helpful.

Thank you.

I have the tuts in my ftp of acprotect 1.09 and 1.10 this packer use this detection and is explained but is in spanish.

If you need fool this detection is easy, make a infinite loop in the entry point of the packer bytes EB FE, and save the changes.

RUN the program out of ollydbg, and will be looping in the EP , now attach with ollydbg, change manually EB FE for original bytes
and RUN, and voila, the detection is fooled.
Only ollydbg is detected if you run the program in the debugger with open-run, not if you atach the program.
If you have detailed information how work this apis read the tutes mi ftp
ricnar456.no-ip.org
user:curso
pass:curso

NUEVA TEORIAS

Ricardo

Well, one question, the detection is not in the packer (cuz iv removed the packer) but coded into the program itself, does this method (dead loop & attach) still work ?

Thank you.

PS. Too bad I can't read Spanish

well is in the functionality of the apis, try this method and rename the exe of the olly to other name for better protection, put two exes in the ollys folder OLLYDBG.exe and a renamed.exe and use renamed.exe for debugging and use the method of atach too for two protections.

The other possible detection is for the name of the window OLLYDBG, this can be fooled using WINDOWSHACKER.

Ricardo

yeah thanks for all yr helps, after i attached to the running (in a dead loop at EOP) process, i could trace as needed.