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?
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.
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.
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.
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.
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.
Yes.Isn't unpacking specific to the packer
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).