First I'd like to say that OllyDbg is really an awesome tool... Very powerful.

I used OllyDbg to unpack a program that was packed with an unknown packer. Different file identifiers said it was packed with different packers... some said yoda's cryptor and some said ASPack. Either way, it won't unpack with those unpack tools, so I used OllyDbg to trace through the code until it unpacked itself, and used OllyDump to dump the code to a file. OllyDump also has the functionality to rebuild the import table, but I still had to modify it a bit by hand to get the program to run correctly.

Now the program runs perfectly, however for unknown reasons, when I run the unpacked executable in OllyDbg, no breakpoint actually breaks. The program just runs from start to finish. If I pause the program in Olly, I'm able to see the current memory, stack, registers, etc. It all looks good, but Olly just won't break on any breakpoints. Any ideas why?

are you using w9x then it may probably be because it plays with sidt hooks int3 and moves an iretd at the start of int3 handler
see daemons site for all kinds of tricks like this but all of them mostly work on 9x only

apart from this if you are setting bpts at what olly says as data section they probably wont be preserved every time you restart them you have to set them anew

i dunno if any of these or the cause may be you could explain it a little more

I'm running on XP Pro. I did check the flags on the .text section after I unpacked the executable, and it is set to be executable.

Hmm... explain it more... what do you want me to explain?

What I'm doing is just opening Olly with the program that is unpacked on disk. As soon as the program is loaded, it executes straight through even though I have Olly set up to break at the entry point of the main module. This is the only program that does this. Is it possible for there to be a problem in the PE header that would prevent Olly from breaking but the executable still run perfectly?

If there's anything specific you want to know about it, just ask.

I found out that the Resume Flag is set when the program loads up.
If the Resume Flag is set as the program loads, then it would prevent the debugger from breaking, correct?

Is there something in the exe's header that could set this flag?

Hi,

could you please explain what "Resume Flag" means in the context of ollydbg?
If the debugger loads a target it has full control over the debuggee because all of its threads are initially suspended.
There is no automagic flag in PE that tells the debugger to "start over".
You might check ollydbg "events" and "SFX" debugging options to make sure it isnt trying to trace some entry at startup.

Regards,

A. Focht

Oops, I meant to say Restart Flag. It's bit 16 in the flags register.

I'm not sure this is the problem, but it seems to always be set. When I read about the restart flag, it said that debuggers(in general) use it to determine when they have already executed an instruction due to a break so that they don't execute the same instruction twice.

I'm able to pause execution in the process in question, but the problem is that if I try to single-step in code or set breakpoints or anything, it just executes straight through and never stops. When I did pause execution, the flags register was set to 00010202. I tried this multiple times all with the same result, and as soon as I step another instruction, the entire executable runs till finish without stopping. The one time that it did not do this is when I changed the flags register from 00010202 to 00000202 and then stepped.

I have Olly set up to break on entrypoint of the main module. It should break as soon as the executable loads, but it doesn't. This is what makes me think that the restart flag is being set as the main module is loaded. Is the flags register set to a value stored within the executable upon load?

Greets,

are you sure it breaks at earliest possible point (without executing any bits of debuggee code)?
The EFLAGS value has no correlation with PE header.
It can be modified by debugger and - of course - by debuggee itself. But it has to execute code to do this.

The comment of 'oh me anon' is seams very reasonable: "and moves an iretd at the start of int3 handler"

IRETD is the way to change the RF flag.
If the return stack is adjusted with EIP, CS, and EFLAGS (with RF set in the EFLAGS image) then executing an IRET causes popping the RF flag into EFLAGS.

Break directly at the PE header entry (OS loader system breakpoint), dont let ollydbg execute "startup" code to get to the main entry

Regards,

A. Focht

hehe if it sets an iretd and hooks int3 it wont brerak anywhere at all coz ntdll.dll debug break itself will be hooked and then it will prevent from stopping at entry point
only way is dissemble and deadlist but he didnt seem to like my explicit implication that you dont make any sense comment
so i stopped posting

btw if it is nt one cant grab the sidt the proggy will crash it only works on 9x and also only after executing some of the debuggy code and it will do break for the first time when the iretd isnt installed but wont break any other subsequent times till you reboot

using extend code to include extarctor ,trace realentry blockwise
etc may work
or the best way is to examine pe header and find entry point use ctrl+g -->ep and use new origin here or hard code a cc there and force it to break for the firsttime after reboot and trace from there