If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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?

Don\'t SYN us.... We\'ll SYN you..... \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

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

IT Blog: .:Computer Defense:.PnCHd (Pronounced Pinched): Acronym - Point 'n Click Hacked. As in: "That website was pinched" or "The skiddie pinched my computer because I forgot to patch".

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.

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.

Oliver's Law:
Experience is something you don't get until just after you need it.

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

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

Oliver's Law:
Experience is something you don't get until just after you need it.