Stuxnet is now on GitHub

https://github.com/Laurelai/decompile-dump

by steipete • 15 years ago

248 66 15 years ago

rst2• 15 years ago

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...

viraptor6• 15 years ago

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...

soulclap• 15 years ago

'collaborative decompilation space' (github-based or not) sounds like a sick idea, actually.

rst2• 15 years ago

Although in this case, the object code may have been deliberately obscured. On reflection, I can't help wondering how much of the seemingly pointless diddling of local variables is the result of turning a naive decompiler on a bytestream where the actual instructions are somehow encrypted or masked.

levigross3• 15 years ago

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

yuhong• 15 years ago

"(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?

kissickas• 15 years ago

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

jeffreyg2• 15 years ago

"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.

nailer• 15 years ago

Parses fine here.

"Here are some emails that show this company was planning to use Stuxnet"

Stuxnet is a distributed bot. It can be commanded. The post is saying this company planned to do that.

I don't know whether that's true or not but it seems easy to understand.

kens• 15 years ago

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...

leon_2• 15 years ago

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.

yuvadam• 15 years ago

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• 15 years ago

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

tedunangst• 15 years ago

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

eru3• 15 years ago

Without a very clever decompiler, I'd say `ugly'.

jerf2• 15 years ago

Heck, you don't even need that. Put this in a file named "Hello.hs":

    module Hello where

    main = print "Hello world!"

and run "ghc -fvia-C -keep-hc-files Hello.hs". Compilation may fail with linker errors, but today we don't care about that. We just want to look at the resulting Hello.hc file, which is the C representation of the Haskell, and generally looks like:

    II_(rhG_closure);
    II_(si4_closure);
    FN_(Hello_main_entry) {
    FB_
    if ((W_)(((W_)Sp - 0x10UL) < (W_)SpLim)) goto _cip;
    Hp=Hp+2;
    if ((W_)((W_)Hp > (W_)HpLim)) goto _cip;
    Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info;
    ;EF_(newCAF);
    {void (*ghcFunPtr)(void *);

and so on for quite a while longer. Passing this through a compile and decompile step might actually clean it up a bit....

btrask• 15 years ago

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

scotth• 15 years ago

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

viraptor6• 15 years ago

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.

updog5• 15 years ago

Actually, the mess on github is hex-rays.

DCoder3• 15 years ago

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...

viraptor6• 15 years ago

If you have it installed at the moment (I don't unfortunately), you can always give it a go for comparison... The binary is apparently available from http://tuts4you.com/request.php?3011 (pass tuts4you)

forgotusername2• 15 years ago

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• 15 years ago

>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.

forgotusername2• 15 years ago

Given Stuxnet's purported sophistication, I'd be shocked if it didn't employ obfuscations that rendered decompilation ineffective, at least prior to annotation within IDA first, which doesn't appear to have been done here.

Decompiler output is nice to glance at quickly, but as demonstrated elsewhere in the thread, it is only of superficial benefit when faced with even remotely complex code. For example, it cannot discover a struct's fields - they must be manually inferred and input into IDA before decompilation. A mess will result on trying to merge the output from a run with this information with a run that did not have it.

There are tools already in use for collaborative disassembly over the Internet, but a Github repo containing auto-generated source is not one of them. For all intents and purposes, it looks like someone's made minimal use of the IDA GUI without much clue for what they're doing. That's why I called it a PR stunt.

dmix• 15 years ago

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

levigross3• 15 years ago

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

SoftwarePatent• 15 years ago

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

hdx• 15 years ago

Thx for this link, very kewl talk.

dustinchilson2• 15 years ago

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

apl• 15 years ago

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.

derwiki• 15 years ago

You just need to make sure you're using it well if you use it :)

borism2• 15 years ago

since when is linux kernel a reference on good code?

dustinchilson2• 15 years ago

I know goto is not necessarily a sign of bad code and there are situations where they are needed. That being said even though I am not the most experienced, I have never needed to use a goto (except QuickBasic maybe).

The linux kernel works very well but does "just working" necessarily mean that that is the only way have it function. "It works" doesn't mean its good code.

I did not look at the code very closely but one goto I saw seemed to point from the main loop into a function. Which to me seems like an odd use, a use that can easily be avoided.

eru3• 15 years ago

Unless you have proper support for functions. Optimized tail calls are as cheap as goto, but cleaner in the code.

wslh• 15 years ago

What's the license? :-)

levigross3• 15 years ago

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

NateLawson5• 15 years ago

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.

updog5• 15 years ago

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).

leon_2• 15 years ago

to me it looks like it was done by an external contractor _for_ a government agency.

cyber-warfare is the shit now - and everyone wants a piece of that cake. (even if it means mixing 0days with ex-javacoders)

Tenchi• 15 years ago

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)

Stuxnet is now on GitHub

Related Stories