Hey there guys,
Like the topic is stated I am wondering on how to protect an exe file being debugged and protect my exe file against setting breakpoints etc..
Can you guys help me further on. I have no idea where to start. I just want to protect it against all debuggers out there especially SoftICE and Ollydbg.
Like the topic is stated I am wondering on how to protect an exe file being debugged and protect my exe file against setting breakpoints etc..
Can you guys help me further on. I have no idea where to start. I just want to protect it against all debuggers out there especially SoftICE and Ollydbg.
i suggest you to start by learning PE structure. for example write app to display PE headers.
after that write program that just adds section to PE
after that write program that just adds section to PE
Any recommandations about books etc.. on that?
*edit*
I just found out Iczelion did a few PE tutorials. Will those cover enough or do you recommend reading other books also?
*edit*
I just found out Iczelion did a few PE tutorials. Will those cover enough or do you recommend reading other books also?
hmm, IczLion's is far from complete... but can explain many things for you for beginning.
i would suggest also some reference, and downloading anything you can find on subject.
http://en.wikibooks.org/wiki/Reverse_Engineering/PE
http://board.flatassembler.net/topic.php?t=5616
i would suggest also some reference, and downloading anything you can find on subject.
http://en.wikibooks.org/wiki/Reverse_Engineering/PE
http://board.flatassembler.net/topic.php?t=5616
Veggy
If you don't embed symbols in your executable, ie. if you don't create a "debug" version of your exe, then although it can still be disassembled in a debugger, the disassembly will be difficult to follow. Frankly, if anyone tried to follow and use such a disassembly that would be more time consuming than writing the source from scratch in the first place.
Do you want to protect against such disassembly to protect your source or is there some other concern that you have?
If you don't embed symbols in your executable, ie. if you don't create a "debug" version of your exe, then although it can still be disassembled in a debugger, the disassembly will be difficult to follow. Frankly, if anyone tried to follow and use such a disassembly that would be more time consuming than writing the source from scratch in the first place.
Do you want to protect against such disassembly to protect your source or is there some other concern that you have?
Hello Veggy,
Write a good solid protection scheme that is difficult to cr*ck. Don't even dream of impossible.
You got to be kiddin jorgon! There's a million programs out there with cr*cks and keygens. They weren't all shipped with debug symbols. That would be like leaving the bank door open. However locking the door won't stop robbers ;)
best regards,
czDrillard
Write a good solid protection scheme that is difficult to cr*ck. Don't even dream of impossible.
Frankly, if anyone tried to follow and use such a disassembly that would be more time consuming than writing the source from scratch in the first place.
You got to be kiddin jorgon! There's a million programs out there with cr*cks and keygens. They weren't all shipped with debug symbols. That would be like leaving the bank door open. However locking the door won't stop robbers ;)
best regards,
czDrillard
Veggy
If you don't embed symbols in your executable, ie. if you don't create a "debug" version of your exe, then although it can still be disassembled in a debugger, the disassembly will be difficult to follow. Frankly, if anyone tried to follow and use such a disassembly that would be more time consuming than writing the source from scratch in the first place.
Do you want to protect against such disassembly to protect your source or is there some other concern that you have?
Hey there guys,
Well the thing is I want to protect my exe file against the possibility to set a breakpoint on the writeprocessmemory api.
No protection scheme will hold up for long however there are a few tricks that will hold off the lesser attacks. Obfuscating your code is always a good idea, write as much spaghetti code as you can and embed data in the code section. Multiple threads using synchronisation objects can make it difficult to trace code. There are plenty of white papers on detecting debuggers/disassemblers such as SoftIce that can let you shut down when it is present in memory, google around a bit and you'll find a few. Try running an exception handler within your application, you can have your app hang on INT3 fairly easily. Change the AEDebug key for the run of your app, that will redirect the final handler to another application of your choosing, just be sure to change it back.
The best you can ever hope for is to buy a bit of time, all protection schemes fail eventually since the tools to reverse engineer applications are incredibly powerful and becoming more so everyday.
The best you can ever hope for is to buy a bit of time, all protection schemes fail eventually since the tools to reverse engineer applications are incredibly powerful and becoming more so everyday.
There's a plethora of antidebug tricks being employed in the wild.
Check out http://www.woodmann.com/forum/index.php for more information, this is not the right forum for such discussions.
Note that I've written a userland debugger which is immune to almost all of the known antidebug methods (it uses lookahead analysis).
Check out http://www.woodmann.com/forum/index.php for more information, this is not the right forum for such discussions.
Note that I've written a userland debugger which is immune to almost all of the known antidebug methods (it uses lookahead analysis).
Okay guys thanks for all the help and tips, I will start reading on all of them.
Change the AEDebug key for the run of your app, that will redirect the final handler to another application of your choosing, just be sure to change it back.
It's not a good idea to play with that kind of registry values. And do consider what happens *if* your program crashes or exits unexpectedly without restoring the key... it's not like it's going to buy you a lot anyway.
Code obfuscation is one of the few things that does work pretty well, but you should use automated tools to do it and keep your source code clean - for your own sake.
Softice detection is fairly useless - anybody that's able to use that debugger will hide it (there's several public tools out there to do that, and then there's some private and very powerful tools). Softice detection will mainly piss off programmers that can't run your grame/program/whatever just because they have softice installed, not even running, on their machine.
Multiple threads, synchronization and use of SEH is a good step, it makes it annoying to trace your code. Do yourself a favor and have a RELEASE/DEBUG build set up, so you can actually debug your own code when built in debug mode :)