Code/program protection

Thought of a new idea for program detection.

I have to dig up the code, but there is a way to get a specific ID for the computer being used. I could code in a check to ID the computer and store it along with a count of how many times the ID changes. If it changes more than 2 or three times, I could probably figure the program had gone beyond it's allowed borders and maybe do one of the following:

1. Do a slow file corruption
2. Erase itself completely after overwriting it
3. Change some code to run differently but still work

Question:

Could a program be coded so that if a block of code didn't run in a specified amount of time, something else could be branched to.

Like if it was being traced.



Comments

  • [b][red]This message was edited by descenterace at 2004-3-7 11:59:57[/red][/b][hr]
    : Thought of a new idea for program detection.
    :
    : I have to dig up the code, but there is a way to get a specific ID for the computer being used. I could code in a check to ID the computer and store it along with a count of how many times the ID changes. If it changes more than 2 or three times, I could probably figure the program had gone beyond it's allowed borders and maybe do one of the following:
    :
    : 1. Do a slow file corruption
    : 2. Erase itself completely after overwriting it
    : 3. Change some code to run differently but still work
    :
    : Question:
    :
    : Could a program be coded so that if a block of code didn't run in a specified amount of time, something else could be branched to.
    :
    : Like if it was being traced.
    :
    :
    :
    :
    That's easy enough, but the person tracing your code would see the conditional jump and they could override it.

    Also bear in mind that slower computers will take longer to execute the piece of code, so that'll mess up the program on 386s. [edit: OK, so if it's a small piece of code you could set the threshold at 1 second and even a 8086 wouldn't fail the test.]

    If you want to obfuscate code, use the FORTRAN hacker's technique of arithmetic jumps. Use math operations to calculate the jump distance, save it to AX, then do JMP AX.


  • : Also bear in mind that slower computers will take longer to execute the piece of code, so that'll mess up the program on 386s. [edit: OK, so if it's a small piece of code you could set the threshold at 1 second and even a 8086 wouldn't fail the test.]

    I was keeping that in mind, my code wouldn't work in anything pre-486 anyway.

    : If you want to obfuscate code, use the FORTRAN hacker's technique of arithmetic jumps. Use math operations to calculate the jump distance, save it to AX, then do JMP AX.

    Could you give an example of that.


  • : : If you want to obfuscate code, use the FORTRAN hacker's technique of arithmetic jumps. Use math operations to calculate the jump distance, save it to AX, then do JMP AX.
    :
    : Could you give an example of that.
    :

    You can implement it in C with pointers to functions. Let us assume you do something like this branching subroutine:

    [code]
    /* Branch to f() if 'j' is zero, else branch to g(). */

    void branch(void (*f)(void), void (*g)(void), int j)
    {
    if (!j) f();
    else g();
    }
    [/code]

    What's funny about this routine is that you can call it from many places in your code, so if the average cracker changes the assembler 'jz' for 'jnz', the program will malfunction in all the places where 'branch' is called.

    Of course, there are ways of cracking this scheme (changing the order of the pointers in the stack before "branch" is called), but it may confuse some unexperienced crackers.

    You can use arithmetics with pointers to functions (or even use arrays
    of pointers to functions) to achieve more obfuscation.

  • The really important thing is not to piss off your honest customer, and from a few years of supporting a shareware program I can testify that the frequency of hard disk replacements or reformats going on "out there" in publicland is about fifty times higher than I would have guessed. If you somehow keyed the program to the HDD, you'd be taking a lot of service calls. I wouldn't do it that way. You could key it to the network controller, which has a a "probably unique" number - most recent MBs have one on board.

    As for defeating the debugger, there are some well-known ways. Try running games with SoftICE installed, for example. An awful lot of them detect it and just refuse to start. A web search for SoftICE will turn up some references to concealing it, that will show you how to detect it.

    I found an anti-debugger article in an old issue of 40HEX. Written for the benefit of stealth virus writers, I think, but it sure had some good advice. For example, encrypt a small part of your program, then decrypt it at run time with the decryptor code copied down at 0000:0000, [italic]right on the interrupt vectors[/italic]. Debuggers use Int-1, Int-3, maybe Int-11, not a big area to cover. Even if someone somehow manages to put a trap in your code, what's it going to do if the vector isn't there?

    I wrote a key system based on that principle and I never heard that it had been cracked. The decryption key was the CRC of the decryptor code, calculated at run time, so if anyone altered that to insert a trap, it wouldn't work anyway. It decrypted a short section of code that verified a key file, patched some selected routines, then erased itself so that it couldn't be examined once the vectors were back.


  • : The really important thing is not to piss off your honest customer, and from a few years of supporting a shareware program I can testify that the frequency of hard disk replacements or reformats going on "out there" in publicland is about fifty times higher than I would have guessed.

    I would never do something that would cause that.
    I would make it more difficult to change things in my program.

    If you somehow keyed the program to the HDD, you'd be taking a lot of service calls. I wouldn't do it that way. You could key it to the network controller, which has a a "probably unique" number - most recent MBs have one on board.

    I wouldn't key to the HDD either, what I would be asking for my program
    would be minimal.

    : As for defeating the debugger, there are some well-known ways. Try running games with SoftICE installed, for example. An awful lot of them detect it and just refuse to start. A web search for SoftICE will turn up some references to concealing it, that will show you how to detect it.

    : I found an anti-debugger article in an old issue of 40HEX. Written for the benefit of stealth virus writers, I think, but it sure had some good advice. For example, encrypt a small part of your program, then decrypt it at run time with the decryptor code copied down at 0000:0000, [italic]right on the interrupt vectors[/italic]. Debuggers use Int-1, Int-3, maybe Int-11, not a big area to cover. Even if someone somehow manages to put a trap in your code, what's it going to do if the vector isn't there?

    : I wrote a key system based on that principle and I never heard that it had been cracked. The decryption key was the CRC of the decryptor code, calculated at run time, so if anyone altered that to insert a trap, it wouldn't work anyway. It decrypted a short section of code that verified a key file, patched some selected routines, then erased itself so that it couldn't be examined once the vectors were back.

    I have code for a .com CRC but haven't been able to get much help in converting it to an .exe and some other things.

    Lot of folks think DOS programs are dead. Based on posts on newsgroups and many sites that is simply not true.

    Programs I have written work fine on Win XP.

    Thanks for your feedback.










  • [italic]Lot of folks think DOS programs are dead. Based on posts on newsgroups and many sites that is simply not true.[/italic]

    [blue]DOS is good for learning to program... I never seen any serious DOS application written in the last few years - 95% is for Windows. That's because DOS is gone as operating system of choice - it is all Windows now... sad, but true. And people asking on forums just to learn to program - there are no serious developers there...

    I am currently making an IDE for Assembly programming - the target platform - Win32 only - no DOS. But if you add into your project some DOS code and set up a tool to compile it properly - (for DOS) - maybe that will work...[/blue]
  • : [italic]Lot of folks think DOS programs are dead. Based on posts on newsgroups and many sites that is simply not true.[/italic]
    :
    : [blue]DOS is good for learning to program... I never seen any serious DOS application written in the last few years - 95% is for Windows. That's because DOS is gone as operating system of choice - it is all Windows now... sad, but true. And people asking on forums just to learn to program - there are no serious developers there...

    [black]
    I use DOS every single day, but I'm also in an environment (hardware development) where an operating system gets in the way of the stuff we're interested in checking. Here, DOS is king. It's stable, small, robust and easy to develop for, and lets us have access to all the hardware without pleading for ring 0 access.

    I don't think DOS will ever quite disappear; it'll continue to be niched into different areas where it suits the users. I wish microsoft wasn't so hasty to get rid of it; it really is a useful little O/S.

    -jeff!
  • : : [italic]Lot of folks think DOS programs are dead. Based on posts on newsgroups and many sites that is simply not true.[/italic]
    : :
    : : [blue]DOS is good for learning to program... I never seen any serious DOS application written in the last few years - 95% is for Windows. That's because DOS is gone as operating system of choice - it is all Windows now... sad, but true. And people asking on forums just to learn to program - there are no serious developers there...
    :
    : [black]
    : I use DOS every single day, but I'm also in an environment (hardware development) where an operating system gets in the way of the stuff we're interested in checking. Here, DOS is king. It's stable, small, robust and easy to develop for, and lets us have access to all the hardware without pleading for ring 0 access.
    :
    : I don't think DOS will ever quite disappear; it'll continue to be niched into different areas where it suits the users. I wish microsoft wasn't so hasty to get rid of it; it really is a useful little O/S.
    :
    : -jeff!
    :
    I know I was fairly annoyed when the WinXP 'emergency boot disk' turned out to have WinME DOS on it. 'And the computer shall boot... nevermore!'

    WinME DOS appears to have... issues... with some older computers, which happen to be the ones I'm using this boot disk on. Bring back Win98SE's DOS 7.0.
  • : : [italic]Lot of folks think DOS programs are dead. Based on posts on newsgroups and many sites that is simply not true.[/italic]
    : :
    : : [blue]DOS is good for learning to program... I never seen any serious DOS application written in the last few years - 95% is for Windows. That's because DOS is gone as operating system of choice - it is all Windows now... sad, but true. And people asking on forums just to learn to program - there are no serious developers there...
    :
    : [black]
    : I use DOS every single day, but I'm also in an environment (hardware development) where an operating system gets in the way of the stuff we're interested in checking. Here, DOS is king. It's stable, small, robust and easy to develop for, and lets us have access to all the hardware without pleading for ring 0 access.
    :
    : I don't think DOS will ever quite disappear; it'll continue to be niched into different areas where it suits the users. I wish microsoft wasn't so hasty to get rid of it; it really is a useful little O/S.
    :
    : -jeff!
    :

    [blue]I kind of argee with that: I myself used only DOS when writing small business applications and the production line code, but these are very small on the market, maybe 0.1%... That was my point, basically. But, of course, every OS has its own niche - UNIX is OK for servers, DOS is OK for small applications, but if you want something big - the Windows is a choice of a lot of business people...[/blue]
  • Writing an .asm 32 for Win in the handy Win98SE straight DOS environment works fine.
    Then test it on your Win machine after DOS assembly.......

    I coppied all the DOS files out of C:WIN98COMMAND & EBD
    and made C:DOSWIN
    altered my MSDOS.SYS AUTOEXEC.BAT CONFIG.SYS
    and made a straight DOS version I boot to.
    It handles any hard drive size, plug 'n play, etc (DOS 7.x works great)

    http://bitdog.home.att.net/files/nasmenv.zip
    http://bitdog.home.att.net/files/fasmenv.zip
    has a batch file for swapping OS files easily, then reboot to DOS or Win.


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories