hash changing

I was recently at a hands-on security lab presented by microsoft. The labs focused mainly on Server 2003 and it's security features.
The course was a bit over my head in many areas, but I was able to follow along and learn some from the experience.
One of the labs we did was "Implementing Security by Using Software Restrictions" exercise 1 in the lab involved setting a rule in Software Restriction Policies that Disallowed the hash of %windir%\System32\calc.exe. The next exercise showed how you would change the hash of calc.exe by replacing all the * with a space....worked great on their demo version, but I'm left with a couple of questions in the real world.

1) how much change must be made to change a hash, is it simply one character or space?

2)-how would you go about changing the hash of a program like telnet or cmd? typing notepad c:program/address/tochange.exe opens the program on notepad....but If I try doing so much as adding an extra blank line somewhere the result is a program that won't run at all.

thanks for helping me to clear these questions up.

Faqt;

Are you talking about an MD5 hash? If you are it's like a fingerprint.... You can't change anything about the file, (without significant computing power and even them it might not be possible), without changing the MD5 hash..... It's different to a checksum that can result in an altered file while the checksum remains the same because the concept is different.

I'm not sure what you mean by adding a blank line in your second question. Do you mean adding a blank line to the executable itself? Which executable? Notepad or tochange?

Hey Hey,

I'm not sure what you're changing, but once you answer TS (this time I mean Tiger Shark ;) )I'll have a better idea. Anyways, to make a change to a binary file you should use a hex-editor.

As for your second question, that's an easy one, well kinda. Remember a few years back when the big thing on IRC was to hex edit your version response, so that people couldn't find out you were using mIRC? Well all you had to do was open mIRC.exe in your favourite hex editor and search for version then replace the version string "mIRC 4.11 blah blah blah" with blanks. As long as you kept the string the same size, you were fine, but if you made it bigger (increasing the size of the program) it would crash out. I'm not entirely sure why this happens, but I believe the file knows it's size, or byte locations or something (or at least that's what I tell myself).. Certain hex editors, i.Hex for one, are looking at implementing the ability to add/delete bytes from a file however I'm not sure if anyone has succeeded yet.

Peace,
HT

Quote:

---

I'm not entirely sure why this happens, but I believe the file knows it's size, or byte locations or something (or at least that's what I tell myself)

---

It's because you are overwriting the rest of the origonal code.

So instead of:

"Mirc version 6"
goto 12
blah blah
12: more code here


You have

"Mirc version 6 OMFG"
-error-12
blahblah
12: more code here that is never reached

Quote:

---

Originally posted here by pooh sun tzu
It's because you are overwriting the rest of the origonal code.

So instead of:

"Mirc version 6"
goto 12
blah blah
12: more code here


You have

"Mirc version 6 OMFG"
-error-12
blahblah
12: more code here that is never reached

---

Hey Hey,

That's true if you are overwriting the code, however even if you insert additonal bytes on some binaries (mIRC being one of them).. you will end up with an error..

So you'd start with:

"Mirc version 6"
goto 12
blah blah
12: more code here

Size = 45 bytes (who cares what the numbe ris

and you'd end up with

"Mirc version 6 OMFG"
goto 12
blah blah
12: more code here

Size = 50 bytes

That's the part I don't get, I understand overwriting code, but what about inserting and still getting errors?

Peace,
HT

if i understand you correctly you could use morphine.exe or even upx

Because it doesn't look at it in terms of lines, but in terms of binary.

Let's take for example, even assembly. The assembly runs checks on certain bites within the program, and if those bytes have moved then the code can't process itself.

Similar to making street signs on a road that point to other streets, but then moving all of the streets down one from each other. No one would get there they need to be and thus they would in a sense "Crash". The same happens for the data being read and written. Since assembly and binary work on calling bytes (not lines) the program looks for the data in itself, and that is (usually) something decided and finalized upon program compilation.

Of course, we can't compare it to C, because C calls lines and functions, but assembly and binary call bytes and bits :) Once those move.. the assembly has no idea what to do.


edit:
Now, the way to get around this, or "injection" is to have decompiled the code or used a memory mapper to see what is being called and where. At this point in time, you could then modify the hex further (to a degree) to change the assembly/binary calls to point to the new locations. Of course, this is not just a point and click process, but a trial and error process, mathamatical process, and then inserting the modified hex to resend the assembly checks elsewhere.

Quote:

---

Originally posted here by Faqt
1) how much change must be made to change a hash, is it simply one character or space?

---

If the hashing algorithm is any good, changing just 1 bit should result in a totally different hash (with no relation to the original hash).

http://www.networksorcery.com/enp/data/hashing.htm

Edit: rereading your post I think I know what happened. You added hashes to a list of programs that are not allowed to run. This would mean I can change just 1 bit of that program and it's allowed again.

A better way to secure the system would be to store a list of hashes of programs that are allowed to run. If anything changes in these files or if it encounters an unknown file (virus/crackers/malware) the OS will prevent you to run it.

Quote:

---

Originally posted here by HTRegz
So you'd start with:

"Mirc version 6"
goto 12
blah blah
12: more code here

Size = 45 bytes (who cares what the numbe ris

and you'd end up with

"Mirc version 6 OMFG"
goto 12
blah blah
12: more code here

Size = 50 bytes

---

This would mean you've changed the source of mIRC and recompiled. If you used a hex editor you will be overwriting other (maybe important) parts of the binary. Even if you just inserted the bytes some of the (relative) jumps or lookups inside the code will all get screwed up (jump half way inside the wrong subroutine, lookup the wrong value i.e.).

A bit of pseudocode:

Code:

---

.data
text1 db "This is a text\n"
value1 db 12

.code

 load Reg1 value1
 print text1
 end

---

If you inserted text inside text1 the address of value1 should also change. If you did this to a binary Reg1 wouldn't contain 12 anymore (but part of text1) because the address of value1 is calculated at compile-time not at run-time. That would explain the crashes.

Hope that explains it a bit ;)