12

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 ?

10

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.

| improve this answer | |
  • I wonder though, could some kind of load-time unpacking/decryption work here? Resource editors presumably work with the data on disk, not in memory. – Brendan Dolan-Gavitt Mar 30 '13 at 16:52
  • you're right, I edited my answer. – Ange Mar 30 '13 at 17:48
15

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).

| improve this answer | |
11

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

| improve this answer | |
  • Clever! Question though: some of ur suggestions seem to go out of spec for reiurce definitions. This may cause the loader to fail or cause resource functions (eg loadstring) to fail in present or future windows versions? – Remko Apr 3 '13 at 17:08
  • 2
    It is unlikely that Microsoft would change the fundamental behavior of its PE loading and traversal code. I've never seen them do this. The only variation in behaviors was back when the win9x kernel was in use, and it varied from the NT kernel. Microsoft is well aware that linkers of all types generate such differing interpretations of the PE file format, that I'm sure they know not to touch anything. In fact, the PE file format is so surprisingly varied, the only constant is compatibility with Window's code. Of course, test well after making mods like these. – dyasta Apr 4 '13 at 21:47
  • The link to antiResHacker.exe is dead – Fred Concklin Feb 17 '15 at 13:57

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.