3

How is it possible to reverse engineer dynamic malware imports using a debugger like x32dbg or Ollydbg?

I want to dump process injection malware using a debugger trick using a breakpoint on write process memory. But I can't find any injection-related function like WriteProcessMemory at all. I suspect the reason is the malware is dynamically importing.

How can I solve these issues?

Improve this question
1
  • Hi and welcome to RE.SE. Quite frankly I fail to see the connection between the screenshot and the question (also, text is usually better than screenshots for the kind of info you posted). Are you insinuating the values we see are hashes by which the malware resolves imports? You don't even mention the platform, but going by the tools, I'll assume Windows. Shellcode or malware can always use the loader info linked from the PEB to find already loaded DLLs and traverse their exports to resolve them. However, there are NT native APIs instead of WriteProcessMemory, too.
    – 0xC0000022L ♦
    Jan 5 at 11:02

1 Answer 1

Reset to default
-2

Using a debugger like x32dbg or Ollydbg, you can set a breakpoint on the LoadLibrary or LoadLibraryA functions, which are typically used by malware to dynamically import libraries. When the breakpoint is hit, the debugger will stop the execution of the program and you can see the library that is being imported.

Using the same method, you can also set a breakpoint on the GetProcAddress function, which is used to dynamically resolve the addresses of imported functions. This can help you to identify which specific functions are being called by the malware.

Hope this helps.

Improve this answer
3
  • 2
    This method doesn't work when the software use peb to load library or import function because it doesn't need to execut LoadLibrary or GetProcAddress. Check out this github for POC: github.com/vxunderground/VX-API/blob/main/VX-API/…
    – haxerl
    Jan 19 at 10:56
  • 1
    Hi and welcome to RE.SE. This looks and sounds very much like an AI-generated answer (flagging as such). As the previous commenter pointed out, this barely scratches the surface. Even hooking those relevant functions inside ntdll.dll would provide better visibility of what the software does, but even that misses plenty. As a side note, it depends a lot on the injection method, too, what you need to do in order to figure out what the malware attempts to import/call.
    – 0xC0000022L ♦
    Jan 19 at 14:20
  • 1
    Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – sudhackar
    Jan 22 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.