2

I'm using WinDbg to debug a program under WOW64 (OS is x64, app is 32-bit).

I came across some indirect call inside the process module (module created by the app and not Windows), and started following it.

Stepping into this call gets me to an (*) address which doesn't match any loaded module: Tried to search manually with lm, didn't see a match. Used !address command with that address, and it says the page is committed but the protection is PAGE_NOACCESS. Also the stack trace gives me a warning "frame ip not in any known module".

Stepping one more, I get again an indirect call to fs[0c0h] which is a stub for WOW32Reserved (after some more single stepping I get into ntdll.dll. So it's obviously some WOW64 code).

The question is, where did the code in (*) came from? Who's responsible for it? Why isn't it mapped to any module?

1

This sounds like the process has allocated a page for itself, in which it has placed code to run. It might be a form of obfuscation, or if the file was packed, then the unpacker code might be in that page. If you're able to step into the code, then it can't be PAGE_NOACCESS, so perhaps the debugger is confused. The call through fs[0c0h] is the interface for 32-bit code to call kernel code in a 64-bit environment. Depending on the version of Windows, there is either a far jump at that location (pre-Win10), or some stack manipulation followed by a retf (Win10).

  • Well.. I hardly believe the debugger is confused, since it's WinDbg. – user5188701 Jan 31 '16 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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