Results 1 to 6 of 6

Thread: Resource Editors and Hex Editors

  1. #1

    Resource Editors and Hex Editors

    Hello everyone!

    Im typing this myselft, but in name of someone else (a friend that at the moment doesnt have net).

    Here goes:

    - He is coding an app, and he has alot of questions that he whants to know, about how to secure his app.

    1- How to prevent (secure) the app, to show details with the use of a resource editor?

    2- And Hex editor?

    3 - How can he make his app more secure, not reveling any details about the code, resource, or information on Hex Editors etc?

    He means, an strong encryptation. (i think its that what he means).

    All that is applied to the .exe

    The following txt is his own:

    "i whant to make my app secure, so no one using a resource editor, hex editor etc can modify it, or see the content of the .exe file or .dll, not show the dialogs, bitmaps, accelerators etc..is that possible? is there a way? help please"

    Thats it

    Thanx

  2. #2
    AO Senior Cow-beller
    Moderator
    zencoder's Avatar
    Join Date
    Dec 2004
    Location
    Mountain standard tribe.
    Posts
    1,177
    I am not a code-guru (zencoder doesn't mean what most people think it means at first glance), but with my understand of the principles of computing and security, I really don't think this is possible. One can make it difficult for a layperson to use these tools, but at some point in the execution process the computer system has to break down that code to bits it can understand (literally, bits...8 of them make a byte...on or off...binary...machine code, maybe). At this level, that data is not protected by your common encryption or obfuscation methods, and the skillful hacker should be able to access that information, if they have control of the machine executing the code.

    Sorry. But as has been said here many a time before...

    Security is a state of mind, the name of our common journey, not an actual destination you can reach; it is an acceptance of the risks and a pursuit of handling and minimizing them, not the complete eradication of risk.
    -- zencoder


    </goofy-monk-diatribe-mode>
    "Data is not necessarily information. Information does not necessarily lead to knowledge. And knowledge is not always sufficient to discover truth and breed wisdom." --Spaf
    Anyone who is capable of getting themselves made president should on no account be allowed to do the job. --Douglas Adams (1952-2001)
    "...people find it far easier to forgive others for being wrong than being right." - Albus Percival Wulfric Brian Dumbledore

  3. #3
    well, it is not as easy as it sounds, otherwise other big companies would already have done that with their programs. (and there would be no cracks at the net anymore)..

    simply put, every program can be cracked / reversed but it depends upon the value of your program, the fame that your program has and the perseverance of the attacker .

    first factor:
    most reversers crack programs for the challenge, so the first factor is of no interest of them.

    second factor:
    if no-one knows your program excists, then no-one will try cracking it... so if you are planning on making the program widely known, then this factor won't help you either.

    third factor:
    well, here comes the tricky part, like i said before, if someone really wants it, your program WILL be cracked.

    but, you can make it as hard as possible for them:

    first of all make a strong protection in your program if you are using some kind of serial check or something like that.
    the program can be fully secured, but if the serial can be guessed easily then that won't help a bit.

    second, disable debug options in your compiler, this way it will be a little harder to follow your program.

    third, learn about safe coding,
    check every userinput,
    clear the buffers as soon as you don't need them anymore,
    check for debuggers in your program and respond to it when found,
    make the serial check as hard and complicated as you can. this will be the most precious thing for an attacker, so secure it well.
    also remember, that when a good serial is entered, you still need to make some bogus checks or something to divert the attacker from the goodguy message:

    Code:
    push offset userinput
    push offset validserial
    call lstrcmp
    cmp eax,0
    je GoodGuyMessage
    BadGuyMessage
    "incorrect serial"
    
    GoodGuyMessage:
    "well done!"
    i put this code in asm since this is about the same as you see when you run a program through a debugger...

    as you can see there is a string compare. if the stringcompare returns 0 (if equal), then go to the goodguymessage.

    all i need to do is change the
    Code:
    je GoodGuyMessage
    to
    Code:
    jmp GoodGuyMessage
    now every serial that is entered will be correct (according to the program).

    as you can see this is very important to be careful about this.
    also hardcoding the serial in your program is NOT the way, since an attacker can read the serial with any hex-editor.


    now when you have made sure your program is coded as safe as possible, you still need to protect the executable.

    there are several packers out there which can be used to protect your program from being debugged.

    these packers work by a simple routine (simply put), they add an encryption routine to your executable, change / encrypt your code and safe the program.

    then next time the program is executed the encryption routine is run first and that will decrypt your code, this has to be done, otherwise your program won't run since the operating system won't recognize the commands if encrypted.

    an attacker now has several options of cracking your program.

    he tries to find out which packer you have used and run an unpacker against it which will retrieve the original (decrypted) executable.

    if that doesn't work he can use a program that retrieves your program from memory and makes a new executable from it.
    this can only work if it is clear where the encryption routine is finished and where your code starts.
    also your program has to be decrypted in the beginning completely to make this work.

    there are some packers which decrypt your program one part at the time and run it immediately after it, then it decrypts another piece and so on...

    so be careful with your choice of packer.

    the best way would be to write your own packer, since this way you are sure no unpacker will be able to unpack your program since they don't know your unpacking routine.
    so the attacker would have to unpack your program manually, this can be a hard and time expensive job where most of them will give up.

    then we have the danger of patching in memory, this is:
    a program (loader) runs your program and then "pause" it after several miliseconds. when your program is fully loaded the attacker is able to walk through your code and patch the program where necessary to crack the program. if this works the atacker would probabely write a patch / loader which will load your program and patch it automatically, this way your program is cracked.

    as you can see by what i have told here, there are a ways to protect a program, and also a lot of ways to attack it.
    i'm sure i haven't completely told you everything, but this is just an example.

    for more info i suggest your friend gets a copy of this book:

    Hacker disassembling uncovered by Kris Kaspersky.

    it will show you ( your friend) how an attack works and how to prevent it.

    here are some tools (packers / unpackers) which can be used by an attacker.

    ollydbg a free debugger / disassembler which you can use to see how your program looks like when compiled.

    crackits use these programs to learn how easily a password can be retrieved...

    if anyone has something to add / point me to a mistake, then please do, i'm not alknowing

  4. #4
    Socialist Utopia Donkey Punch's Avatar
    Join Date
    Sep 2004
    Location
    In the basement
    Posts
    319
    1- How to prevent (secure) the app, to show details with the use of a resource editor?
    Some executables/dll's/whatever can use compression algorithms to at east slow down some resource hackers/editors/exractors/etc. If you were to open DAMN's NFO viewer (which is written in MFC), it cannot just be opened with a resource editor to be played with.

    Another way to prevent hex editing is to use something like: http://www.cyotec.com/resources/cyoprotect/ but as the page suggests, it is not 100% because as you know, even the most secure of applications are cracked (3DSMax, Windows, Dreamweaver, etc...)

    That has been a problem for developers for years, and piracy has always been a game of cat and mouse:

    1. Develop the program and add features to prevent cracking

    2. Cracker finds a crack or makes a keygen in a matter of days or even hours

    3. Developer makes a patch or uses another method

    4. Cracker cracks it again and posts the update on astalavista

    if you find a solution to this problem, you will be a billionaire.
    In loving memory of my step daughter 1987-2006

    Liberty In North Korea

  5. #5
    Thanx alot for all this info, i will print this (i dont know alot about the subject, just a bit here and there..not enough to call myself a even wanna´be a programmer dude lol)

  6. #6
    Socialist Utopia Donkey Punch's Avatar
    Join Date
    Sep 2004
    Location
    In the basement
    Posts
    319
    everybody starts somewhere. Also, you said your friend does the programming, why not get some info from him, or look into it yourself? There are a lot of languages to learn from.
    In loving memory of my step daughter 1987-2006

    Liberty In North Korea

Posting Permissions

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