Archive for the 'Reverse Engineering' Category

Fall Penetration Testing and Exploit-Dev course

This year’s Penetration Testing and Exploit Development course (Fall 2008) will contain completely rewritten course material, guest lectures from leading security professionals, and free access to commercial tools provided by Fortify Software and Matta (thank you!). Additionally, the class will be held on-campus rather than online as it has been.

The instructor for the course is Nasir Memon with TA’s Dan Guido (me) and Vikram Padman. The syllabus has been finalized and the guest professors as well as their respective topics are as follows:

  • December 4th — FINAL PROJECTS
  • December 11th — hack the planet/show off projects

Students will have to complete one homework assignment every two weeks, a take-home midterm, and do a final project of their choosing. Each two week session will contain one full session of Q&A to review the homework associated with it. Extra credit will be given for participating in CSAW and UCSB iCTF.

Any questions about the course can be e-mailed to me at dguido@gmail.com.

EDIT: The course will be held in room RH227

F-Secure Khallenge Level 1

Thanks to Aleksey and Phn1x for dealing with my constant stream of questions while reversing this. You’d think it was the first time I opened a debugger!

The level 1 challenge was a binary that asked for input and, if your input was correct, printed out an e-mail address you could use to get the level 2 binary. The Khallenge is a contest of speed, so the first person to get to and beat level 3 wins. Unfortunately, I solved level 1 after the contest ended and the level 2 and 3 binaries aren’t online yet, so no prizes and no info on those.

Continue reading ‘F-Secure Khallenge Level 1′

Reverse Engineering a PHP “Virus”

In a recent incident a school server (not an ISIS server) was compromised. PHP code was injected that listened to and executed commands passed through a POST request with ‘www’ user privileges. Some of the commands that were run include id, pwd as well as directory searches and wgets of various files. The compromised machine also served as a hop in a pharmacy ad delivery scheme. It redirected HTTP requests for medications to a possible ‘mothership’ server. There is evidence that links to our server were posted as ads on websites like MySpace.

sample_ads

Continue reading ‘Reverse Engineering a PHP “Virus”’

Chinese CNO anyone?

While I’ve been sitting at home, sick for the last few days, I’ve been trying to keep my mind at least somewhat sharp by watching some light videos here and there. The usual stuff, some TED, some 30 Rock, and I came across this gem I thought many people on this list might be interested in:

Crouching Powerpoint, Hidden Trojan: An analysis of targeted attacks from 2005 to 2007
Presented by Maarten Van Horenbeeck of the SANS ISC at the 24th Chaos Communication Congress
http://events.ccc.de/congress/2007/Fahrplan/events/2189.en.html

See the links at the bottom for presentation materials including a PDF, video, and analysis of actual targeted exploits. I highly recommend the video, the torrent was extremely fast.

Enjoy :-)

Reverse engineering mailing list

A mailing list for our re group was created. If you are truly serious about joining, please write to me (yan@isis.poly.edu) and I will add you. The list is meant to exchange ideas, topics, materials, and post challenges for other subscribers (along with tips).

The list is going to be informal and of average volume.

Prodding programs

I will try to keep this to the point. Auto-completion on the terminal is something we all love and it makes using a UNIX system and running commands far more pleasant. Most shells can auto-complete path names, binary names, and built in commands. Bash goes further and supports auto-completing user names, hosts and a few other trivial things. No shell that I know of has ever attempted to auto-complete the arguments that the binaries take. Leaving out support for this makes sense, as there is no common way for a binary to store the arguments it can take inside the program binary, and it is bound to be a porting nightmare.

Keeping this in mind, I realized that almost every single UNIX binary gets its arguments from the shell in a standard, POSIX-compliant way. The getopt libc function call parses the input from the shell in to usable internal flags. If one were to peek inside what each binary gives to getopt(), one would find out all arguments it is expecting to take and provide more insight about the executable! This is what I have done and what the remainder of the post is about.

This is what my previous post related to. Now I realize this is a slightly silly goal. My primary reason for doing this is to learn the techniques I’ve used to get there, which I simply could not learn without experimentation and a concrete goal in mind. The way this problem was attacked as follows:

Continue reading ‘Prodding programs’

Tools for implicit code understanding

In the last few weeks, I have been needing to understand a lot of existing source code. People, including myself, often try to reverse-engineer binaries and not pay much attention to reverse-engineering available code, if that’s the proper way to call it. While not reverse-engineering in its core, analyzing source code tends to tickle similar parts of the brain as when reverse-engineering binaries. This post is a short description of the tools and techniques I’ve been using and hope to receive suggestions to techniques I have been missing.

The tool in question is ltrace, which I believe is a doing of mostly the Debian project (I can be wrong), with a port to FreeBSD which is what I have been using. I have spent enough hours trying to just read source code, using grep to look for where to look for my next step.

Read on for descriptions!

Continue reading ‘Tools for implicit code understanding’