Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
I analyze a piece of malware and I am faced with the following problem: The main thread of the malware spawns some threads. After the first thread is generated, the main thread jumps to a non-existent memory space to cause an exception. The debugger ( i use ollydbg v1.10) crashes.
So, I do not know how to execute the first thread before the main thread causes the crash. Is there an elegant way to bypass that anti-debug trick ? Can somebody help me?
best regards,
The question is missing some background information about the debugging process and the instructions you've seen. I'll try offering a few leads and am waiting for an edit with more info before i proceed and elaborate on any of these.
Obscured exit upon debugger detection
Since OP asked about exceptions i'm going to assume he's facing exception-based anti-debugging techniques, but it's worth noting this could also be an issue of any other type of anti-debugging, and the exception is only the manifestation of malware's debug-detection handling.
For example, you might be facing an anti-debugging trick as simple as calling IsDebuggerPresent and jumping to some fixed invalid address. Or a more complicated address calculation that includes debug-related flags to hide it's anti-debugging nature. In that case, you should back-trace the cause of that misbehaving jump (was there a conditional jump? is the address calculated based on dynamic values?).
Exceptions as anti-debugging techniques
Many malware samples and packers use exceptions as part of their anti-debugging tricks in order to thwart analysis. You may be facing a similar issue.
The basic idea behind exception anti-debugging techniques is to use side effects of a debugging tool (or of decisions made by the person using the tool) to alter the execution flow. There are several ways to do that, the classic being setting an exception handler (either for the local thread or at the process level) and implementing important parts of the logic in the exception handler before returning execution to the original EIP or changing it completely.
To check if you're facing an anti-debugging exception tricks it's usually good to configure Olly to automatically pass all exceptions you encounter to the debugged program. Using ollydbg2, you do that by opening the Options dialog (Alt+O), navigating to the Debugging/Exceptions tab ticking the "Ignore also the following custom exceptions or ranges" and hitting the "Add current". Specifically for memory exceptions you can simply tick the "Memory access violations" under the "Ignore (pass to debugged program) following excpetions"
Please make sure you're facing an exception based anti-debugging using the adove tips, and update you question to include more details and i'll update my answer with ways to overcome the specifics of the issue you're dealing with.
Breaking concurrency assumptions
Although this technique is not too common by debugging the process you break concurrency assumptions, which is something malware can use as a way to detect debugging. For example by issuing the create threat syscall you also give the OS scheduler a chance to switch contexts, and the newly created thread might be required to change something in the process's context (a global value is the simplest) before the main thread resumes execution. I'm not sure this is 100% generated to work, and might require other setup by the malware (Sleep(0) is a common practice).
