Hey, I'm on the other side of things... I'm wondering how to calculate a CRC of my own code during execution in order to thwart hackers.. (Yes I know it won't really, but indulge me if you will)

Anybody have any tips? Any docs I should look at?

Thanks.

Platform win32 (windows2000)

p.s. I have discovered the windows API to ReadProcessMemory and WriteProcessMemory, but it is not obvious to me how to find how large the process is- which parts are executable and which parts are memory- at what address they actually reside (if I don't trust they are at 0x400....0).. etc.

---Also---

Does anyone know if the win32 api IsDebuggerPresent actually detects SoftIce?

lowrunner

Several points really.

1. You can calulate a CRC on the file. This will tell you if the file has been modified. I assume you have a CRC routine already. It will not however tell you that the contents of memory have been modified (by patches, breakpoints etc.)

2. Calculating the CRC of memory is more involved. You cannot calulate the CRC of the data section (for obvious reasons) and must content yourself in calculating the CRC of read only sections.

3. Even read only code can be different to that on disc. Look at relocation items for instance. Most (all) of the time an exe file will not be relocated but a DLL may be. Safest approach is to only CRC between relocation items.

4. Don't, don't, don't check the CRC by comparing it with the 'correct' value and then jump to good-boy, bad-boy code. This is easily patched by a cracker. Instead use the CRC value, for example as the decryption key for some later calculation. If the cracker patches the code, the CRC value is altered, the decryption key is corrupted and the program fails later!

5. You may ask how do you know what the correct CRC should be when you are writing your code? You don't. You will need a post compile process which takes your exe file and works out the CRC of the sections you are interested in. It can then 'inject' the value into the appropriate parts of the program where it is used. Similarly if you encrypt your program you will need a post compile process.

This is only a brief note on these points, we could get into more detail but in the same way as crackers do not put all of their detail on message boards so as not to give the game away to protectors, it also works the other way around too

p.s.
When you get a handle for a process, as in LoadLibrary, you will see that the handle is simply the address of the start of memory for that process. The memory also holds the files PE header so as long as you know the PE format (essential for what you are doing) then you have everything you need including the size of the memory section. I can't remember off hand how to get the address of your own process but I am sure I can look it up for you.

It is hardly worth while trying to detect SoftIce, there are many-many ways of doing so and an (almost) equal number of ways to hide SoftIce from such checks.

Thanks.. i will especially take the SoftIce comment to heart.

I only need to calculate the crc the program as it runs, not check for its correctness.

So, I have downloaded the PE format specification from MS. What a monster it is. Do you know of simple demonstrations of interpretting PEs that *aren't* in assembly?

(I admit it, I'm spoiled)

-- Also --

Most of the hacks I have been reading about involve modifying a few parts of the exe so that a check is not made.. Or waiting until after unpacking, and then dumping the program to disk...

Would there be any significant increase in difficulty if the hacker were forced to insert entirely new sets of code (rather than modify or nullify existing)?

---

Thanks again.

There is one from a guy called Luevelsmeyer. I am not sure where to obtain this but it contains some examples in C and ofcourse some in assembly aswell. I don't think you will get rid of the assembly part fully since PE is really lowlevel stuff and some parts is not really possible to do/show in a highlevel language.
One thing is theory though and another practice. If you understand the theory there's alot stuff you can do with you favorate language.



Tell me what you mean about new set of codes and I'll tell you about difficulty. If you have a license check which you can isolate from the rest of the program and it won't depend on your code and your code won't depend on the check in a significant way, then it will be possible to remove entirely or nullify as you call it. Imagine the following two cases:

You do a simple license check during compare:
The value 12345678 comes from a license file of any kind.

Compare(hardcoded value, 12345678)
if equal proceed else show error

You do a calculation using the value from the license:

... <your super duper secret algorithm> ...
add(constant, 12345678)
... <continue calculations>...

Hopefully you see the difference here and can understand the change in dificulty. First one you can isolate and force it to become correct every time. Even if you don't know the original value (in this case 12345678) because your code doesn't rely on the checking after it's completed.

In the 2nd case you need to find out whats the real value. Mainly because if you don't do that then your super algorithm will give bad results and your code could crash if it's not behaving correctly.

When you write a new set of codes I think of emulation similar to dongles. Imagine a dongle which supports saving maybe 64 values like the one above. Either of them can be used like above. Additionally it contains some secret hashing/encryption algorithm so a input I will give a output O. If used correctly you can make your program depend on the dongle and you need to write a emulation for it to make the program think there is a dongle connected. If used wrongly you don't need a emulation because the method of checking could be like the first example which is defeated easily for anyone who knows just a bit of cracking.

As for your checksum idea I say it's good if used wisely. Again you could use it in the above two ways (use or misuse) but it's a good thing to include.

Ok thats it for now

// CyberHeg

Here you go:

http://personal5.iddeo.es/ret007ow/PE.TXT

Thanks again

I'll post again with more specifics in the future.

Hi lowrunner,

There's a few good places you can check for information. One very handy reference when you finally get down to coding something to parse the PE header is an article in the ID_RIP archive available on this site, "Exe file format with offsets rather than explanations" exe_hdr.html by FatboyJoe. Looking at the PE header as a structure you can recognize in a hex editor rather than trying to piece it together from descriptions in a multipage document may make it easier to interpret. The file can be upped here if you can't find it.

A utility such as PEBrowsePro will help immensely as well if you run it on a few PE files and view the output. As for examples of some code which will "walk" the PE header so you can find the section addresses and sizes or however you want to use it in a protection, there are likely some examples in C/C++ out there, but you may have to interpret an ASM source example such as PELabs by Latigo or some other "PE" utility with source that has been offered up. Check out the Protools site at the bottom of the page, or Iczelion's ASM site for examples.

You're probably already familiar with general protection resources, but also check out Fravia's "How to Protect Better" labs on his searchlores site. I think DelphiBox has some good information for programmers as well. Good Luck.

Kayaker

After reading the last post I did a quick google search for "Exe file format with offsets rather than explanations" (just out of curiousity) and ran into this article: (strange isn't it, from MS)

You probably have already seen it. But if you haven't, it contains compilable C code that will traverse a PE.

h t t p : //www.anticracking.sk/EliCZ/import/msdn_pefile.htm

....

Thanks again everybody. I'm sure I'll post another question soon enough. I have plenty of docs to read through now!