Stuxnet is now on GitHub

[rst]

Decompiler output; product of the HBGary/Anonymous dump. The most interesting thing here is probably the emails from HBGary folks about StuxNet in the accompanying blog post[1]. (For public purposes, the CEO wants everyone to know, they know nothing about it, but Aaron Barr was talking about it with various people anyway.)

Unfortunately, the decompiler output doesn't convey much as it stands, unless you like sorting through pages and pages of

    local199 = local191;
    local203 = local191 + 0x6f02418d;
    local3 = proc2(0x10021238, param1, param2, param9, param5); /* Warning: also results in local190 */
    local208 = local3;
    local209 = local190;
    local211 = local203;

That being one of the more interesting sections; there are stretches with dozens of lines in a row of the form "localfoo = localbar".

It does seem to suggest, at least, that this dump didn't have the actual source.

[1] http://crowdleaks.org/hbgary-wanted-to-suppress-stuxnet-rese...

[viraptor]

A silly decompiler that doesn't even recognise for loop with a break (https://github.com/Laurelai/decompile-dump/blob/master/outpu...)

That said... I wonder how useful would github be as a collaborative decompilation space - grab a file, annotate / simplify as much as possible, send pull request, repeat...

[kens]

Is this decompiler output accurate? I'm suspicious because proc12 [¹] looks like memcpy, except it's advancing a byte at a time and copying an int at a time:

  *(int*)local6 = *(int*)local5;
  local5++;
  local6++;

Either the memcpy code is strangely broken, or the decompiler is putting int * where it means char *.

[¹] See full code at https://github.com/Laurelai/decompile-dump/blob/master/outpu... and same for proc20: https://github.com/Laurelai/decompile-dump/blob/master/outpu...

[yuhong]

"(For public purposes, the CEO wants everyone to know, they know nothing about it, but Aaron Barr was talking about it with various people anyway.)" Which is of course not a good idea in the PR 2.0 age. Anyone found emails explaining why they did this?

[jeffreyg]

"Throughout the following emails it is revealed that HBGary Federal may have been planning to use Stuxnet for their own purposes"

what does that even mean? nonsensical.

[kissickas]

Many of the emails in that article are ordered newest to oldest... not a great link.

[levigross]

this is just in time for the RSA show that is starting on Monday.

[leon_]

it's just building the stack frames in C. at the end this is just assembly with C syntax - and the reason why I rather like disassemblies than decompilates.

[dmix]

For those curious, a Microsoft employee broke down each of the exploits that Stuxnet used at a conference recently: http://www.youtube.com/watch?v=rOwMW6agpTI

[SoftwarePatent]

For anyone watching this video, zoom to 6:55 to skip a long, dull discussion about filling empty seats in the audience.

[levigross]

that's a great talk. I like how most of the bugs within the OS logic as opposed to overflow bugs. It does lend itself to the stability of the exploits

[hdx]

Thx for this link, very kewl talk.

[forgotusername]

Title insults the intelligence of HN readers, that's obviously nothing more than minimally annotated Hex Rays decompiler output.

There is nothing new to see here. A quick Google search for "stuxnet.zip" reveals other samples, undamaged by some PR whoring idiot running it through IDA.

[lukeschlather]

>There is nothing new to see here.

Has anyone suggested using Github as a social space to work on decompiling malware before? Github has some potential to be a unique space to work on this sort of problem in a collaborative setting. The story is that someone thought of that.

As for the title, I'll forgive it just as I'd forgive any other nascent Github project stating its goal rather than its present state in the link. The point is to get interested people working on it together.

[NateLawson]

This is not Hex-rays output. It is much better than this. This is boomerang, which is a free decompiler that hasn't been maintained much lately. You'll note that not much has been updated on their page since 2006.

http://boomerang.sourceforge.net/

This github project is pretty much useless for those who want to learn about Stuxnet. Better to load the binary into IDA Freeware instead.

Stuxnet does appear to be an unusually large project (base classes, ungainly modular structure) for malware. This reinforces what I said earlier about its lack of stealth for the payload.

http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not...

It does not appear to be sophisticated in any way except for its payload, which some evidence seems to claim was carefully constructed (e.g., with a PLC testbed). The "embarrassing" fact I was referring to in the above post is that its lack of stealth revealed its payload to the world, and no competent intelligence agency has that goal if the purpose of the worm itself is to do some damage.

Perhaps the worm is a way to draw the heat off the real deployment method. Or it is industrial sabotage gone awry. There is still not enough evidence to come to any conclusions on it, except this is not what an eleet cyberweapon would look like if you were to find one.

[updog]

I don't know how any reasonably intelligent person could continue to stubbornly insist that stuxnet was too lame to be done by a government agency. This isn't even a question, of course it was. It isn't even speculation anymore. The only question is which one(s).

[Tenchi]

I like the fuss this "recent discovery" makes all around the web when this article here: http://ma2moun.com/blog/2010/09/stuxnet-source-code-samples/ is FOUR MONTHS OLD, and contains the exact same code output than the github "source code" (The second screenshot has the exact same content as 016169EBEBF1CEC2AAD6C7F0D0EE9026.c)

[levigross]

I wonder if anyone is going to send a DMCA takedown to github.....

[wslh]

What's the license? :-)

[scotth]

Man oh man. That would take a long time to figure out. Is this really the best a C decompiler can do?

[DCoder]

This looks like the output of HexRays [1], which is the best C decompiler I've seen. Defining some structures and typing the variables would make it a lot more readable in some cases. I've used HexRays to make sense of C++ games several times, after investing enough time to define and use data types, the result looks [2] much better, but then again, that's unobfuscated and not optimized C++, not old-school "I know what I'm doing and I don't need the compiler second-guessing me" C.

Unfortunately there's still a lot decompilers can't do, mostly compiler tricks (e.g. storing a pointer to the middle of a structure instead of its beginning, and using negative offsets to access other struct members [3] - this is usually obvious when looking at it, but HexRays can't make sense of it so it falls back to raw pointer math).

[1] http://www.hex-rays.com/ [2] http://img824.imageshack.us/img824/1188/hexrayscpp.png [3] https://github.com/Laurelai/decompile-dump/blob/master/outpu...

[viraptor]

Depends how much you want to spend on it. Hex-Rays for example is pretty decent and not even comparable to the mess on github.

[yuvadam]

This decompiled output shows a very nice example where C can really be no more than "glorified assembly". (Anyone help me with proper attribution for the quote?)

[udp]

That's a bit inaccurate: http://james-iry.blogspot.com/2010/09/moron-why-c-is-not-ass...

[tedunangst]

What do you suppose a decompiled chunk of optimized Haskell would look like?

[btrask]

On the contrary, I think the decompiled output highlights the difference between C and assembly, because it looks nothing like typical C code.

[dustinchilson]

So I see GoTos in that code. I hope that was the decompiler not the author because thats just sacrilege.

[apl]

Ah, that's a classic approach: no clue, but strong opinions. "goto" hardly qualifies as a sign of bad code; otherwise the Linux kernel would be in a terrible position. If used well, it's a valid solution to many flow-problems.