Results 1 to 9 of 9

Thread: hash changing

  1. #1
    Senior Member
    Join Date
    Mar 2002
    Location
    Snohomish WA
    Posts
    315

    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


    If you want to make God laugh....make plans.

  2. #2
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    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?
    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

  3. #3
    Senior Member
    Join Date
    Jan 2003
    Posts
    3,915
    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

  4. #4
    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

  5. #5
    Senior Member
    Join Date
    Jan 2003
    Posts
    3,915
    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

  6. #6
    Senior Member
    Join Date
    Nov 2001
    Posts
    4,785
    if i understand you correctly you could use morphine.exe or even upx
    Bukhari:V3B48N826 “The Prophet said, ‘Isn’t the witness of a woman equal to half of that of a man?’ The women said, ‘Yes.’ He said, ‘This is because of the deficiency of a woman’s mind.’”

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

  8. #8
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401

    Re: hash changing

    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.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  9. #9
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    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
    Oliver's Law:
    Experience is something you don't get until just after you need it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •