Slashdot Mirror

← Back to Stories (view on slashdot.org)

Russian Denies Writing SoBig Worm

Posted by timothy on from the nyet-nyet-nyet dept.

IphtashuPhitz writes "The Russian spamware programmer anonymously accused eariler this week of writing the Sobig worm has responded to the accusations. Ruslan Ibragimov of Send-Safe doesn't deny that his program uses proxies to hide spammer's identities. But he totally refutes the report's technical analysis in an online interview over at OReilly Network."

2 of 67 comments (clear)

  1. For sure he denies. by a_hofmann · · Score: 4, Informative

    If you read the original report you can see hard facts against Ruslan Ibragimov.

    The binary comparison in the report shows evidence for a correlation between Send-Safe and Sobig-F which could be proved if Ibragimov would be forced to open the Send-Safe source.

  2. Re:I don't buy it by Anonymous Coward · · Score: 2, Informative

    There are legitimate ways to compare executables (as opposed to the method used by the authors of "Who Wrote SoBig?").

    0) All of these ideas involve disassembly. http://www.datarescue.com/idabaseIDA Pro is the best dsassembler on the market; all ideas below are implemented as extensions to it. Nothing even comes close to its sheer strength, except perhaps the underdeveloped, alpha knockoff http://lida.sourceforge.net/Lida.

    1) http://www.datarescue.com/idabase/flirt.htmFLIRT signatures work surprisingly well for the detection of statically-linked libraries (assuming the library itself hasn't been recompiled). It is basically binary-based but there are important measures for dealing with code that can/will change between different binaries.

    A plugin called http://www.sport-und-event.de/backtrace.de/plugins /idb_2_pat.zipIDB2PAT for IDA can take an executable and produce FLIRT signatures for all functions in it, which can be applied against any other executable for comparison. I find this very handy for malware versioning analysis.

    2) http://www.razorteam.com/publish/papers/comparing- binaries.htmlInstruction Semantic-Based Binary Comparison The paper calls itself "Comparing binaries with graph isomorphisms" but this is a misnomer because there is nothing graph-based about the comparison; only the visualization has any bearing on graph theory. This technique attempts to match the assembly instructions almost exactly (not necessarily a byte-for-byte direct comparison). No public implementation is available for this method.

    The problem with the two methods above and the reason that byte-for-byte comparison won't work in general is that compilers regularly re-arrange code or change register allocation, especially in the case an optimization is applied differently between builds. Two successive builds might look completely different on the binary level. Microsoft's internal compilers are especially notorious for this.

    Enter 3) http://www.sabre-security.com/products/bindiff.htm lBinDiff by Halvar Flake. BinDiff is the most promising idea of the three (though designed for a different purpose than 1)). By using structural and graph-theoretic properties of executables (e.g. the call-tree) and the functions within them, BinDiff is able to compare executables without looking at the instructions themselves (except for properties that can be deduced in a CPU-independent fashion by IDA). That means that BinDiff can potentially diff binaries for different platforms, meaning the binaries could be using a different executable file format and a different assembly language. Obviously, the two binaries described would be remarkably different.

    2) & 3) conception was motivated by the idea of diffing security patches (which they do with various degrees of effeciency). 1) is arguably at the core of IDA's power.

    P.S. the "Who Wrote SoBig?" authors are completely full of shit. From the paper:

    "AMS [a *completely unrelated* email client] and Sobig contain common high-level functionality, as both programs generate and send email. Although there are many ways to create this functionality in source code, it is extremely unlikely that two people working independently would generate similar opcode sequences for this type of functionality. From the results of our comparisons, the first 1K of memory indicated that they are very similar types of executables."

    No shit, that's because the first 1k of the executable is usually the PE header. "Very similar types of executables"? What does that mean, anyway? The whole report is anonymous, unfounded slander.