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
The job of a linux distributor (such as Red Hat, Debian, Gentoo, Ubuntu etc) is primarily that of assembling a large quantity of free and open source software into an easy to use and pre-configured package. While they may write and contribute some of their own software to the mix, and do some customisation and bug fixes of their own, 95%+ of the software you see in a linux distro will be common to other distrabutions.
I don't use Red Hat or Fedora myself, so could be wrong about the below, but... Fedora is developed by the community (Red Hat also helps to develop it) and is kept fairly up-to date with new software releases. Red Hat Enterprise Linux uses snapshot of Fedora as a core, keeps it stable (ie doesn't update it that often, just bug fixes) and adds a few bits of proprietary software and adds in the support contract (most people buy Red Hat for the support). If you want Red Hat without the support, and the RH branding, then maybe CentOS is what you are looking for.
I would personally suggest Ubuntu Linux, which is Debian based, its fairly well polished and most things will work straight out of the box, so you shouldn't need too much in the way of support to get it setup (Though I have had some difficulties with the 64 bit version). Even things like Java, ATI/nVidia drivers and multimedia codexs can be gotten via apt-get (you may need the extras repository for some of these). If you need paid support, Canonical will support Ubuntu for $100 USD per computer per year (I haven't used them myself, so can't say how good they are).
If you want free support, then goggle is your friend, as is reading the documentation, searching goggle groups, asking on mailing lists and visiting IRC channels. The only cost is the time and effort to find the answers for yourself (which doubles as a good education in Linux). You are not guaranteed an answer, but will usually find one, nor a time limit on how long it will take to find or receive an answer. This is the method that most individuals actually use, though it does require that you are willing to learn. In a business where time is money, it is possible that paid support may work out cheaper than your own time in searching google (it depends on how much your time is worth compared to the time saved via a support contract), but in comparison, I will ask you when was the last time you phoned up Microsoft and had them tell you how to fix your problem.
As for the Mozilla Corporation, they are very new and haven't done anything that I could comment on, but I see it as very, very unlikely that its formation will have a detrimental effect to the development of free and open source Firefox. We already have Netscape as a commercial company that takes Firefox, gives a customised setup, adds alot of their own branding to the package and throws in a few proprietary components and calls it Netscape 8. Firefox is not the poor "free starter edition" cousin to Netscape 8. As long as people are intrested in Firefox, then it will continue to be developed and it will always remain free.
For businesses specialising in free and open source software, the "switchero" is fairly uncommon. FLOSS licences actually prevent people from doing a "switchero" on existing software, if its been releases as FLOSS then that version will be free forever. With non copyleft (ie GPL) licences (or when exceptions are made in the licence), then someone can make a proprietary fork of the project and future versions of that fork may not be free, though others are still free to continue to work on the FLOSS version. This can also happen with copyleft or GPL software when only one person, or one group, owns ALL the copyright to the software and can thus change the licence for future versions (such as PHPedit). In many cases, where the software has been developed by the community, there are too many copyright holders for this