How to prevent use of Resource editors

Question

There are variety of tools that allow editing the resources of Windows executables. These tools allow a very easy interface for changing the programs look and feel. Replacing icons, text, menus can be easily done without any knowledge in reversing.

My question is, what option I have to prevent the resources being so easily edited ?

Answer 1

Resources are just a standard structure with defined constants, but in the end, it's just a recursive structure to a buffer, no matter what it contains (here is the standard layout).

It can theoretically contain anything - any depth, loops, invalid types, etc... but then standard APIs will not work with them.

So, you need to make sure that, if you encrypt or compress resources, they need to be restored (both the resource directory structure, and their content) before any of these APIs is used, which might not be obvious.

In particular, some resources will be used by the OS even before the file is executed, such as first icons, manifest and version information - so you probably want to keep these intact.

A simple way to prevent trivial resource editing would be to run a stream cipher on selected resources, on the final binary (after the linker put them in place and generated the resource entry in the DataDirectory), and to restore these resources on demand or on program initialization.

If you're looking for a ready-made solution, many good packers such as PECompact support resource compression, thus preventing external resource editing.

Answer 2

An elegant and simple solution would be to sign your executable and verify the signature on startup (any change will invalidate the signature). Even if someone patches your signature check, the signature will still be invalid which makes clear that the exe is not the same one you delivered.

My other thoughts would be to use an exe packer or to take a checksum on the resources (both were already suggested in @angealbertine answer).

Answer 3

Also, we can exploit bugs in the editors themselves to prevent tampering with our resources. The interesting part here is that most Resource Editors have no idea how to parse non-typical (not very non-typical) PE files. For example, Some editors assume the resource section name must always be .rsrc. Examples:

1. Resource Hacker

   • Inserting a special resource to cause Resource Hacker to go into an infinite loop. Demo here : http://code.google.com/p/ollytlscatch/downloads/detail?name=antiResHacker.exe

   • Inserting a special RT_STRING resource to cause Resource Hacker to crash.

   • It assumes the size of the IMAGE_OPTIONAL_HEADER structure is assumed to be sizeof(IMAGE_OPTIONAL_HEADER), currently 0xE0 in hex, while it can even be greater. Having the size to be of a greater value causes Resource Hacker to discard the whole PE file.

2. Restorator

   • Same as 1c.
   • Uses the NumberOfRvaAndSizes field, which can easily be forged to be 0xFFFFFFFF. This causes Restorator to discard the whole PE file.
   • Assumes the resource section name must be .rsrc. Change it anything else. This causes Restorator to discard the whole PE.
   • Any resource Section with the Characteristics field set to IMAGE_SCN_CNT_UNINITIALIZED_DATA among other characteristics will be discarded by Restorator.

   Demos here : http://pastebin.com/ezsDCaud