I'm reverse engineering a malware that at some point tries to connect to http://api.ipify.org in order to get the IP address of the infected PC.

I was able to replicate this behaviour with a small Python script, but for some reason, I can't get the same result when debugging the malware (in my dynamic-analysis VM using x32dbg), due to the fact that execution hangs indefinitely inside HttpSendRequestA.

I tried to trace the execution flow inside that API, and the reason of the hang is a call to WaitForSingleObjectEx in wininet.dll (so, nothing to do with the malware itself).

If I try to patch the dwMilliseconds param of WaitForSingleObjectEx (causing a timeout) I can get further to the execution, but eventually I get stuck another time when the malware tries to perform another http request.

I tried to run this sample on another dynamic-analysis VM with Fakenet-ng installed and I can't even see the attempt to perform the http requests from the log.

In both VMs the network is online.

Am I missing something obvious here?


I tried to run the malware outside the debugger (still in a VM with fakenet) and I see the http requests from the log! So the issue described here only happens when running INSIDE the debugger. Still, I don't think that this is an anti-debugging trick: I have reverse-engineered and documented EVERY function of this malware and I haven't found any anti-debugging stuff.


It seems that this user had the same issue (usign a different debugger):

OllyDbg "runs away" when stepping over wininet.HttpSendRequestW


Found a workaround (described in the answer bellow)

  • 2
    I assume you've tried setting a breakpoint after the function call, and rather than stepping to and over the call, just launch the process and wait for it to hit the breakpoint. What flags are sent to InternetOpen()? Is it setting the async flag? After clearing the dns cache, do you see it doing name lookup before the hang?
    – Tobias
    Apr 26, 2023 at 0:53
  • Hello Tobias. Yes, I tried to set a bp just after the function call, but it still get stuck before reaching it. There isn't any flag pushed to InternetOpenA (it pushes 0 as dwFlags param). I don't see any name loopups either. I'm thinking about coding a little prog that simulate this behaviour using same APIs/params and see what happens while debugging it. Apr 26, 2023 at 22:23

2 Answers 2


Ok after hours of struggle, I found a solution (sort of).

First of all, I still don't know what causes the deadlock, but I found that this happend only when debugging the malware as a dll.

How I came to this conclusion? Because I've written a little app (exe, NOT dll) to simulate exacly what the malware is doing, using the same windows apis and in this case I got no deadlock. So I started to suspect that the issue was indeed the fact that I was debugging a dll.

So this is what I did:

  1. Using dll_to_exe I've convert the malware from dll to exe (thanks @hasherezade for this great tool) [https://github.com/hasherezade/dll_to_exe]
  2. Since the malware uses a custom entry point, I loaded the new executable in x32dbg, reached the real entry point, then fired up Scylla and produced a new dump with the EP set to the real entry point (I know that this can be done without Scylla at all by simply using a PE editor, but I was lacking any PE editor in that VM and the network was intercepted by Fakenet-NG).
  3. Loaded this new executable (with the correct EP) in the debugger and executed it. It reached HttpSendRequestA call and I was able to step over it without any deadlock.

Still, if you know why the deadlock happens in the dll version please tell me. I also tried to use OllyDBG just to make sure that this wasn't a bug of x32dbg, but I was able to repliace the same issue there too.


I don't know if it's still a problem for you, but it might be related to this:


and more particularly this sentence:

"Improper synchronization within DllMain can cause an application to deadlock or access data or code in an uninitialized DLL. Calling certain functions from within DllMain causes such problems."

So my guess is that the malware you're debugging is trying to call HttpSendRequestA before it exits DllMain ?

  • Thank you for this piece of info. This is interesting, considering that this malware doesn't use the regular DllMain, but instead use another entry point. Jun 3, 2023 at 11:14

Your Answer

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

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