Structure of an executable

[JohnOne]

Is it possible to scan or hash an exe file to determine if the resources in it have been changed/removed/replaced.

Following on from my goal was to update the resources in one executable from another, I would like to check the integrity of the target executable, to confirm that changes have been made to resources, and no changes to the original binary.

So in short, I want to confirm the code has not been changed, and the resources have.

is there a name or phrase for the kind of operation I am trying to describe?

[Mat]

Yes. Not really any simple way to do it off the top of my head.

Are we talking about AutoIt code here?

Read up on the portable executable format. It is made of sections, and it should be possible to do a comparison of .text section. If it's autoit code then I've got no idea how you'd do it.

[JohnOne]

Compiled c++ code is my target, I'm not concerned really whether a solution is in AutoIt or C win32 API, as one can usually be changed to the other.

I suppose I could just fileread specific locations in exe, update and check again for change, but that's just scruffy and nasty.

I'd sooner be able to determine which parts of the file are what.

Resource hacker does a similar operation I suppose, if it knows the locations of the resources within it.

I'll look into portable executable  format, cheers mat.

Meanwhile...

If anyone knows location to a decent PE explanation (preferably visual - for a dummy) I'd appreciate it if you'd link a boso up.

Edited May 13, 2013 by JohnOne

[Richard Robertson]

The PE header should contain either an index of sections or an indicator of where the first section starts. Then the first section would say how long it is, which indicates where the next section starts. If it's not one of those two, then I have no idea how it could work as a container.

[Mat]

I don't think there is any "PE For Dummies", as dummies generally don't need to even know what it is. This is the msdn guide, which is not only readable (surprise!) but also has demo code for a PE reader written in C.

Using this on C++ code makes your life easier, you just need to compare the binary data of the .text sections. 

[monoceres]

Go to town: 

[JohnOne]

Thank you kindly Gentlebodes, well enough for me to be getting on with there.

I did find some sort of reading but it seemed rather convoluted.

[JohnOne]

Reading about the PE, I don't think it's what I'm after. It seems to describe an executable in memory, where as I'm after it's structure on disk.

And how to determine, or interpret if you will, which part of that is resource data.

[trancexx]

It doesn't make much difference. When reading PE that way you are after PointerToRawData, SizeOfRawData, etc... You get the raw picture, right?

edit:

The only difference between PE file that's not loaded and PE file that's loaded (in/to memory) are addresses of the data. You see, loader reads raw data and places it on different places inside virtual memory. These addresses are written inside PE file as relative values. Relative means that the only important value is the distance between two data. Once loaded you work with VirtualSize, VirtualAddress and other virtual things.

Edited May 13, 2013 by trancexx

[annaharris]

Generally it doesn't happen, the resources for the exe never changes or removed from the application file.

[JohnOne]

You're wrong about that annaharris, resources can be removed, added or replaced.

[Richard Robertson]

The resources typically only change at the development end. There's no reason for a binary's resources to change later.

[JohnOne]

Typically, perhaps, but I can think of many reasons to change or add resources to a binary. For example, there would be no point in building a new file if all I want is a new icon or display a different image.

[monoceres]

Except that building a new file takes approx. 10 seconds.

[Xenobiologist]

To check whether your process did a change to the file, wouldn't it not be enough to save the hash of the entire file before and after your program and then compare that?

You won't get an answer whether your exchange was ok and did not corrupt the new file, but you will be able to see whether something has changed.

[JohnOne]

That would be enough to test that the file was altered of course, but not enough to test that the file is the same, or the original.

What I need, is to test the integrity of only that portion which is executable.

Just be a computer for a moment, you are instructed to allow a file to run, then that files resources are updated.

You test the hash of that file and as far as you are concerned it is not the file you are allowed to run, the executable code is the same, but you disallow it, and wait for user input to tell you how to treat it.

If however you hash only the executable code to begin with, and again after a resource update, you know it is the same file you ran earlier, and can allow it without user input.

[JohnOne]

Except that building a new file takes approx. 10 seconds.

In reality, you cannot possibly know that, even approximately.

Unless of course there is a universal compiler with strict time constants which I'm unaware of.

[Xenobiologist]

Can you provide two example files? and the resources you changed.

Maybe reading the file --> binary shows, that the resource(s) always start at byte number xxxxx and the executable part is between byte y and byte z.

[Richard Robertson]

In reality, you cannot possibly know that, even approximately.

Unless of course there is a universal compiler with strict time constants which I'm unaware of.

He didn't mean literally ten seconds, only that compilers are very fast. And why would you change an icon without changing the software?

[JohnOne]

Can you provide two example files? and the resources you changed.

Maybe reading the file --> binary shows, that the resource(s) always start at byte number xxxxx and the executable part is between byte y and byte z.

 

Not really, the file could have any number of resources, so byte x to byte y would need to be calculated on the fly.

I've been looking at some code I found here but have not yet got my head around exactly what information it gleans and if it is relevant to my needs.

He didn't mean literally ten seconds, only that compilers are very fast. And why would you change an icon without changing the software?

I might have a project that takes 10 minutes to compile, and how fast compilers are is not really relevant any way, nor is why I's want to change an icon, which I only mentioned as an example.

Thanks for your interest nontheless.