Slashdot Mirror
A New Challenge from Honeynet
cjpez writes: "The people at the Honeynet have issued another challenge on the Bugtraq mailing list. Instead of hacking into a box, though, this time your goal is to submit the best analysis of a binary file they'll post on Monday, May 6th. Think you're good at reverse engineering? Then try it out! They're even offering actual prizes, so you can get something besides the feeling of personal fulfillment for your trouble. The post hasn't quite made it to SecurityFocus' Bugtraq Archive yet, but I did find it at another Bugtraq archive in Germany (slashdottings abound!). The URL included in the email, http://project.honeynet.org/reverse/, doesn't seem to be active yet, so presumably we can assume it'll go up on Monday. The post fails to address other concerns, though: will the winner be in violation of the DMCA? :P The challenge was also issued, obviously enough, on SecurityFocus' Honeypot mailing list."" In a later note, he points out that the announcement has finally made it to the Bugtraq archive page." (And that URL is active now.)
Last year the Honeynet Project sponsored the Forensic Challenge,
a competition amongst the security community to study, analyze,
and report on a computer hacked in the wild. The result was a
complete forensic analysis of the hacked system. Both the analysis
from different individuals and the the images of the hacked
computer are shared and used to this day.
This year we are continuing that tradition and are announcing the
Reverse Challenge. The goal of this challenge is to develop reverse
engineering skills amongst the security community. Your mission, if
you should choose to accept, is to analyze and report on a binary
captured in the wild. Your analysis will then be judged by a panel
of experts, rated, and shared with the security community.
This year we actually have prizes. Top prizes include licensed
copies of IDA Pro, $200 Amazon gift certificate from DataRescue, and
free pass to the Black Hat Briefings. As if that was not enough, the
top 20 entries get a signed copy of the Honeynet book, Know Your Enemy
(you know, the book the guy down the hall is using as a door stopper
Judges include:
- David Dittrich
- K2
- Halvar
- Job de Haas
- Niels Provos
- Gera
The challenge officially begins Monday, 06 May when we release the
binary. You have between now and the 6th to get your tools ready,
form teams if you wish, and stock up on the caffeinated beverage of
choice. You will then have four weeks to complete your analysis and
submit your report no later the 24:00 GMT, Friday, 31 May. Submissions
will be judged and then released 01 July. You can learn more about the
challenge now, and download the binary on 06 May, at
http://project.honeynet.org/reverse/
All question, concerns, and submissions should be sent to
We hope that the community has fun with this, with the ultimate goal
of learning and sharing. Let the games begin!
--- The Honeynet Project
PS, the person who hacked our Honeynet is not eligible to submit an entry,
you know who you are. The question is, do we?
Pedro Côrte-Real.
they are going to release a binary found in the wild
in other words, a trojan, altered system binary from a rootkit, or the like
we are supposed to determine what it is, what it does, what it doesn't do, that sort of thing. then write up our findings in a nice professional package for fun, fame and prizes
Will work for paycheck.
Not everybody serves their dot-org like slashdot. Here's the real link : WWW.honeynet.org.
:)
Or maybe they were just trying to keep it from being slashdotted!
---- Just another spud server.
I know you're just clowning, but the binary is a tool uploaded to a honeynet server right after it was compromised and then executed on that machine.
The goal of this contest is for the security community to examine tools that are "in the wild" and forensically analyse them to determine origin, function, skill of the creator, etc. and present the forensic methods used. The community can benefit from this open sharing of methodology so we can all be aware of our opponents in the ring.
---- Just another spud server.
- Don't run it on a work machine! Should be obvious.
- If it's not your personal machine and you intend to run it, make sure that the owner is aware of possible consequences and has given full permission.
- Don't run it on a critical machine. If it's a rootkit of some sort, or something more insidious, you don't want it destroying data. Preferably, you'd like the option to wipe the partition(s) and reinstall if it's nasty.
I don't think the honeypot project would release a very dangerous file without some kind of warning. Still, a little precaution wouldn't hurt.Car analogies work about as well as a Ford Pinto with a keg of beer in the passenger seat.
This looks to be an interesting challenge; I believe the entire idea is analyizing the binary (which is a program) without actually running the thing; then, designing methods to check for network activity and such that this particular binary would generate. In addition, you get bonus points for correctly quantifying the skill level of the coder who produced said binary.
It's much the same way as anaylizing a captured worm/virii; you need to figure out what it does, how to detect it, how to block/eradicate it, and also try and establish a profile of the originator of the worm/virii.
--
I Hit the Karma Cap, and All I Got Was This Lousy
Here's an interesting link. Not necessarily a guide though.
Fravia's Pages of Reverse Engineering aren't too shabby an introduction. However, their focus is on DOS-based systems, not UNIX.
Schwab
Editor, A1-AAA AmeriCaptions
Perhaps you take a look at their site and some of their previous work before you assume an ulterior motive. The Honeypot project provides some really interesting looks into the minds of the Blackhat community.
You can't get a blue screen on a black and white monitor.
> I just mv it to dev/null.
/dev/null, and you won't have a /dev/null special file anymore, which can break a LOT of stuff. (mmap(/dev/null, bunch_o_bytes) is a common way to allocate memory, for example). If you DO blow away your /dev/null, you need to know the maj/min numbers for that device and recreated it with mknod.
The file will still be there, only it will be called
Do daemons dream of electric sleep()?