Skip navigation.

hllywood's blog

Why anti mal* is doing it wrong

I had a presentation the other day at UNM on some of the work that I had done two years ago. It's fascinating that there is such a renewed interest.

A. Kozakiewicz, A. Felkner, P. Kijewski, and T. Kruk published a paper (4/2007) after my DefCon presentation entitled "Application of bioinformatics methods to recognitio of network threats." The conclusion of this paper was that these the bioinformatics techniques seem to have less resistance to polymorphism, however I maintain that was because of the simplicity of the scoring function they considered.

One of the starting papers in the field of using nature as a way to figure out how to do things correctly was a 1994 paper "Principles of a Computer Immune System" by A. Somayaji, S. Hofmeyr, and S. Forrest. This spends a lot of time considering the acquired immune system.

So, how does nature do things differently than anti mal*? There's a lot out there on this topic. I'd like to advance two points I've not seen elsewhere:

  • Natural systems don't "root" the individual hosts, but the hosts provide enough information (via MHC II molecules) to an immutable status of what each host is doing. Anti-mal* is the opposite, wanting hooks into everything and itself being readily disabled.
  • There is no hesitation to kill hosts that are suspected infected. Among many destruct mechanism is the FAS ligand activation pathway. Think of this as a lever on the outside that automatically shreds the cell and makes it easy for the acquired immune system to improve future defense. Note again that the cell is shredded; there is no "root" required for post mortem forensics.

These are just some ideas. I hope to be getting them together in a formal paper sometime soon. I look forward to comments.

binBLAST release

This is something that I've ignored for entirely too long, so I finally just did it instead of trying to pretty up the release.

binBLAST is now available via google code (not SourceForge):
binBLAST source code

This is everything that was presented at DefCon.

BinBLAST Pre-Alpha Release


BinBLAST is an extension of Karlin and Altschul's Basic Local Alignment and Search Tool (BLAST) to work with binaries. This technique has proved invaluable in aiding reverse engineering of genomes and its variants have become mainstays of modern bioinformatics. The analog developed for security analysis of binary executables, binBLAST, demonstrates sensitivity to code versions, compiler variations, and can be used to generate antivirus signatures.

Attached to this post is the code as of the DefCon presentation, provided without much documentation. If you have the DefCon CD, there is an outline in the slides of the programs and how they fit together. This includes the proof-of-concept code necessary to produce signatures of uniqueness.

Automatic Signature Generation

Unfortunately, the utility of the UI was perhaps not worth the development effort. Fortunately, the trainings I've attended at Blackhat have given me a good idea of how to use other UI's and get access to a `better' disassembler than objdump in IDA Pro.

Instead of the UI, I've shifted development focus to the automatic signature generation, an attempt to use the binBLAST technique to identify unique code sequences compared to some universal set of code. Initial development of this is showing great promise but is far from submission quality. I'm making changes to my DefCon talk to reflect this new progress/development.

UI Development

As Chamuco has indicated, I'm working on getting my prototype code into a usable form. For those of you who did not get the chance to see my office, I had about 8 pages filled front-and-back with file offset calculations and other side-effects of a highly disjoint process.

Right now I've moved the code from a series of standalone projects into a suite unified by a CGI/python interface. This is moving toward integration with OC's systems to provide automatic coverage of malware submissions.

The major problem with the BLAST-type approach, as with the original BLAST algorithm, is in filtering the output to get the usable kernels.

Posting to Sourceforge in Process

The tool mentioned in previous post will be presented at DefCon and released via sourceforge. The intent is to make the suite usable for larger analysis vs. the prototype analysis present in my thesis topic. As soon as I have the registration for the sourceforge project completed, I will post the project link here.

Special thanks to Valsmith and Chamuco for providing the source malware for my thesis as well as some reverse engineering pointers.

binBLAST presentation at DefCon

For consideration

I suppose this is a question to everyone reading this blog. If you were to have a tool that could locate similar instruction sequences in some large database, say all of the binaries on an installation, what would you like to see it do?

Based on the work/analysis of valsmith and others, I'm going to start by seeing if Win32.Klez has anything in common with Ubuntu, SuSE, and Mandrake.*

As I don't expect that to return any results, does anyone have any good Linux malware w/ analysis?

* Yes, I do realize that I'm doing a cross-platform analysis. Unfortunately, the people funding my research will not let me assume the risk for analysis of Windows.

New Security Analysis Tool

As I don't know exactly where to begin, I will begin in medias res. I've been spending some time now on a number of techniques to automate portions of reverse engineering for security analysis most of which have been inspired by bioinformatics-type approaches. I don't have any succinct documentation to this point in time, but that will change in the next two-to-three weeks.

Syndicate content