Hi, I'm debugging an application that contains this obfuscated procedure (see image) and the first instruction is already causing a Memory Access violation

This app is packed with UPX and I'm running it on OllyDbg on it's packed format.

My questions are:

1-Is a Memory Access Violation a normal sympton of a obfuscated code during debugging?
2-How can it be able to run without problems out of a debugger?

well theres a few possibilities

1. its unpacked badly somehow, perhaps using a tls trick
2. its designed to crash (and be caught by an seh)
3. both of the above

or maybe

u have missed a antidebug check and were thrown to this location for halting the program. Some of exe's now use this kind of techniques rather than ExitProcess for graceful exit Which makes RE more difficult

That's definitely not UPX's unpacking stub

As for the crash there, one of two things probably happened:
1. The program set up an SEH handler or VEH handler, purposely threw the exception above, and now will use the handler to handle the exception. You can get around this by configuring OllyDbg to ignore all exceptions.
2. There was code earlier in the program that detected your debugger and then redirected you to the code above, in which case you'd have to circumvent that check/redirection.

The code shown above is not part of UPX body, but part of the application itself. I'm running the exe using the packed format (I made an OllyScript that unpacks it and breaks on OEP correctly). There is no problem on unpacking it.
That procedure receives 2 arguments and of them being the number I'm passing myself 0XDDCCBBAA (look at the stack).
When I configure Ollydbg to ignore all exceptions and execute the first instruction (aka: SAR instruction) the code below is executed and the only thing it does is to close the thread I'm working in, by calling ExitThread.


I'm pretty sure that procedure is a keygen routine because after it is executed it passes the returned value to the function that shows the finnal generated key. I never dealt with obfuscated code before, so I'm not sure about if this sympton is normal in some codes like this. For example, isn't possible that the number which represents the memory location [C547A19E] is part of the keygen calculation routine?

That smells of invalid code. Are you sure C547A19E is even a valid address? ALT+M to find out, but it appears Ollydbg has already decided on the answer with the "???" response. The other addresses look suspect too. Are you sure it unpacked ok?

I'm sure this number (C547A19E) is an invalid address (I never said it was valid!) and, yes, UPX is unpacked ok. The function I'm showing in the image is the only obfuscated function I met when debugging this application since its OEP. This function must be protected with something else because it's the crucial part of this application. The question is, why I can not run it inside the debugger?

The obvious next question for me is: "Does this unpacked version run fine OUTSIDE the debugger?" If yes, then I'd bet it's screwing with you. It detected the debugger, and threw you into some shit trying to see if you realize it.

Ohh.. Another thought. Clear your breakpoints, and run it inside the debugger. If it runs OK there it's probably NOT a debugger check. If it crashes, well, there's your answer.

I'm assuming that debugging in IDA is out of the question? If not, try that.

As above. Everything that was said above, plus, I don't think it's 'obfuscated' code per se, in that instructions resolve to valid code as they are executed - even though they don't look valid statically, but rather a code routine that is still encrypted.

As mentioned you probably got tripped up by an SEH or other debugger/tracing detection and, if the case holds, the routine never got decrypted, and woe to you if it crashes bad cracker.

You might check around that GetTickCount call sitting on the stack as a start