Slashdot Mirror
Code Auditing the Defcon Way
An anonymous reader writes "Last weekend at Defcon, the best and brightest hackers got together to play Capture the Flag, a weekend long hacking event that is the premier event of its kind. According to the results, Shellphish won (UC Santa Barbara students led by professor Giovanni Vigna). An article at SecurityFocus states that the competition was far more technical than in previous years, focusing on reverse engineering skills and code auditing." From the article: "The game required skills that are also required by both security researchers and hackers, such as ability to analyze attack vectors, understanding and automating attacks, finding new, unpredictable ways to exploit things...It's about analyzing the security posture of a system that is given to you and about which you initially know nothing."
http://protools.reverse-engineering.net/unpackers. htm
.exe filesize into the application @ it's initialization (either form/screen creation or show methods), & test it on disk.
.exe afaik, so this DOES function as a rudimentary form of virus protection & stops your apps from spreading infectors like those, potentially @ least, because they let you know something IS wrong!
:)
.exe decompressors &/or stand-alone "debuggers" (hacker/cracker tools mostly imo), because they're like swords & double-edged, & often used to bypass password protected installers for the illegal filesharing circuits out there where you can get commercially produced software for ZERO cost...
Sorry to tell you this, because just like Shrinker, some bunch of dorks has also broken AsPack (as far as Win32 Portable Executeable format packers/compressors)...
I use (or have used) both in the past not only to gain the faster loadtime off disk (or, even over LANS, because the decompression process only happens AFTER the read up off of the diskdrive into memory, & thus, runtime & today's modern VERY fast nearly 4ghz CPU's more than makeup for the decompress process 'slowdown' in memory as well as how fast memory is nowadays) but also to 'confuse' debuggers (disassembly tools imo more than anything) via 'obfuscation' of their code, which makes it harder on them.
You can do what I do though, which makes it HARDER STILL on them (and, as a bonus effect, builds in "native antivirus protection" into the app), which is, believe-it-or-not, hardcoding the application's compressed
If the Win32 PE file changes its size even 1 byte (less or more) from its on-disk compressed size? DO as you like!
After all, this IS what std. type "Virus" do, add size & code to the end of the
This is what/how I do it in my code @ least. SO, what can you do IF the filesize changes? Well, limits of your imagination, or 'cruelty' I suppose...
E.G.-> Reboot their machines, shutdown the program being 'hacked' or potentially virus infected since it changed its size (what I do), or if you are crueler than myself, anything you like (i.e./e.g.-> Blow their bootsector, lol).
There is MORE you can do to protect against various "debuggers" like SoftIce &/or WinDbg for example RIGHT in your code though, even if they uncompress to attempt disassembly.
API calls like IsDebuggerPresent, or the presence of SoftIce via routines present all over the internet for it (there are many of these).
*
APK
P.S.=> It almost amazes me that folks build in
How's that done?
Tools like SoftIce or Frog's Ice, WinDbg, & others like them OR techniques like DLL Injection as well! It's unfortunate, but, thievery abounds in this field...
There is nothing you can really do, but make it TOUGH on those that practice it, via ideas like I use above as an example... & I am sure someone could figure out a way around that too, if not eventually!
They do it by mis-using 'debuggers' like the ones I mention. I have NO respect for those that do that, by the by/personally... apk