[PT] Module ... loaded in the address range that module ... previously occupied.

[expend20]

Hi,

Just curious why there is such a constraint?

It's not uncommon to hit this behavior

[-] PROGRAM ABORT : Module RICHED20.DLL loaded in the address range that module ResourcePolicyClient.dll previously occupied. This is currently unsupported.
         Location : add_module_to_section_cache(), c:\work\winafl\source\winaflpt.c:726

Assuming I'm not interested in collecting coverage from such modules, is it safe to just skip them?

[ifratric]

Intel PT decoder requires knowledge of executable code within the process, so it saves executable code from modules when they are being loaded. Custom Intel PT decoder in WinAFL heavily relies on caching in order to achieve acceptable performance, however across process restarts (and across module loads/unloads within the same process) the cache would only be valid if all modules are loaded with the same start address. Fortunately, this is usually the case for Windows as ASLR only kicks in once per-boot. However there are sometimes (usually third-party) modules that misbehave.

To answer your question "is it safe to just skip them", that depends. If such a module is called anywhere within the target function, then skipping it would cause the PT decoder to break as soon as the IP starts pointing into the skipped module. On the other hand, if this module is not called as a part of the target function, skipping it won't hurt.

If the problem only occurs when the process restarts (i.e. the module isn't loaded/unloaded for every iteration), then an alternate solution would be to increase the iteration count and flush the cache for each process restart.

Another solution could be to patch the misbehaving modules and set a fixed base address for them using e.g. https://docs.microsoft.com/en-us/cpp/build/reference/editbin-options?view=vs-2017

[expend20]

Ok, thanks a lot!

Fixing image bases of dlls might be a temporarily solution.

Feel free to close the issue ;)