How RestoreCode works

[pambol]

How RestoreCode works?
I ask it because if somebody hook GetProcAddress or LoadLibrary who are used like RestoreCode(GetProcAddress(LoadLibrary(PChar('ntdll.dll')), PChar('RtlExitUserProcess'))); will RestoreCode works?

if not how prevent it?

[madshi]

RestoreCode() wants an address, not a dll name, so LoadLibrary/GetProcAddress are not used. So if GetProcAddress or LoadLibrary are hooked, that doesn't bother RestoreCode(). Of course if *YOU* call GetProcAddress or LoadLibrary to find the address which you then pass to RestoreCode(), then of course it could matter if GetProcAddress or LoadLibrary are hooked. But that's really outside of my control.

Generally, madCodeHook wasn't written to fight against other hooking libraries. So if someone else blocks some key APIs, madCodeHook might stop working. If I tried to make madCodeHook bullet proof against such problems, it would be a contant fight.

[pambol]

I understand, so it's better hook these apis and just call a RestoreCode(@TrampolineHookedFunction) right?

another question, how about manual map injection on MCH? it on user mode.

[madshi]

I'm not sure about your RestoreCode() suggestion. You could of course map the DLL file into RAM from harddisk and manually parse the PE file header to find the address.

Manual map injection? I'm not 100% sure what you mean with that, but whatever it is, I'm pretty sure it's currently not supported by madCodeHook.

[iconic]

Pambol asked a very similar question already, here:

viewtopic.php?f=7&t=28575#p52102

Manual mapping is exactly as it sounds, *you* are essentially functioning solely as the PE loader and you map the image from disk into memory, write said memory to the target process(es), perform relocations, import fixups etc. then lastly call the main module entry point without any real Windows loader assistance or intervention. The primary reason some mimic the PE loader (mostly malware authors and/or game cheat authors) is due to the fact that the image can't be detected that easily (no PEB entry for the loaded module, no section backed memory traces to disk (i.e> GetMappedFileName) etc. It's a stealthier way to inject a module with no ties to the Windows loader so people wanting to circumvent mitigation policies such as enforced signature restrictions find the concept even more appealing.

--Iconic

[madshi]

Yes, that exactly what I thought he was asking, just wasn't sure.

Generally, I'm trying to avoid techniques which might be useful to malware developers. That said, there's not always a clear line. So at this point I haven't ruled out ever adding support for "manual mapping". It's not currently supported, though, and I don't have immediate plans to add it.

[iconic]

Hey Madshi

I prefer the official Win32 way but I do maintain a separate module for manual mapping mainly for testing purposes and research. It will never be as smart as the Windows loader, though. Do you think you'll ever support packed images with RestoreCode()? Probably it's not a big deal because likely 0% of Windows system DLLs would ever be packed. When I was actively developing anti-rootkits (many years ago) I of course had to add it, otherwise I had no way of unhooking/restoring the original code bytes, and that required unpacking in memory first before relocation fixups could ever even begin.

--Iconic

[madshi]

Isn't unpacking specific to the packer? I don't think I want to add support for that, to be honest...

[iconic]

Isn't unpacking specific to the packer

Yes.

The trick is letting the unpacker do its job and catching execution at the original entrypoint, which isn't specific to any one particular packer/compressor. AV (from what I know anyhow) implement some form of "generic unpacking" at run-time in order to effectively scan packed images. I think in the future we will see more of this done in hypervisor/virtual environments especially now since Microsoft has official hypervisor APIs (https://docs.microsoft.com/en-us/virtua ... r-platform).

--Iconic

[madshi]

Ah ok, makes sense!