
Stuxnet is now on GitHub - steipete
https://github.com/Laurelai/decompile-dump
======
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...](http://crowdleaks.org/hbgary-wanted-to-suppress-stuxnet-research/)

~~~
viraptor
A silly decompiler that doesn't even recognise for loop with a break
([https://github.com/Laurelai/decompile-
dump/blob/master/outpu...](https://github.com/Laurelai/decompile-
dump/blob/master/output/30DF51C9F0D9B010350DC09ABE1E4E97/30DF51C9F0D9B010350DC09ABE1E4E97.c))

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

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

~~~
viraptor
I really don't think so. The decompilation result is genuinely silly. For
example look at:

    
    
        if (*(int*)(local2 + global0) == 0x4550) {
            local5 = *(unsigned short*)(local2 + global0 + 20);
    

Either local2 or global0 are pointers to a structure. Neither is detected.
Most sensible decompilers would change the names and just make it `local5 =
global0[local2].blah` instead. Advanced decompilers also can avoid gotos in
almost any case. It also uses function calls without parameters or output,
assuming some stack layout probably.

It's a really really bad output, not a result of obscured compilation.

~~~
updog
This came from one of the better known commercial decompilers. Which ones do
you consider 'advanced'?

~~~
viraptor
Pointed out before: <http://news.ycombinator.com/item?id=2214052> \- this is
from boomerang - not a known commercial decompiler really.

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

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

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

------
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...](http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not-amazing/)

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

~~~
leon_
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)

~~~
updog
Yeah, good point - I would lump that in as being the same thing. They usually
get companies like General Dynamics to do this type of thing. Point is, it
wasn't amateurs or "basement patriots," and it cost a lot.

------
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...](https://github.com/Laurelai/decompile-
dump/blob/master/output/1E17D81979271CFA44D471430FE123A5/1E17D81979271CFA44D471430FE123A5.c#L496)

~~~
viraptor
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)

~~~
DCoder
Thanks for the link! You were correct, the quality is noticeably better:
[https://github.com/Laurelai/decompile-
dump/blob/master/outpu...](https://github.com/Laurelai/decompile-
dump/blob/master/output/016169EBEBF1CEC2AAD6C7F0D0EE9026/016169EBEBF1CEC2AAD6C7F0D0EE9026.c)
vs <http://img715.imageshack.us/img715/1051/hexraysstx.png>

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

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

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

~~~
gloob
I admit to basing this on nothing more than a gut feeling, but a "sufficiently
smart decompiler" seems even less plausible than a "sufficiently smart
compiler".

~~~
eru
My first version was just `ugly'. But I guarded it.

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

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

~~~
xilun0
> I have never needed to use a goto

That's because you have not yet programmed enough / read enough programs.

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

Goto from one function to another? Not possible in standard C. If this was
written in C it is most probable that compiler optimisation caused the direct
jump. Even if you were not indeed talking of something like that you missed
the obvious that compilation optimisation and imperfection of the decompilator
are the far more probable cause of presence of curious goto.

You could also have noticed the far more interesting use of cast of char* to
function pointer which are then called. Did the original programmer wrote this
mess? Hint: probably not too...

As for the quality of the source code of the Linux kernel, well, apart from if
you work on safety critical software (in which case it's like comparing apples
to carrots anyway, because they are far more important differences to general
purpose software than the mere presence or absence of gotos) I doubt you've
seen a lot of far better code.

Indeed I even doubt you could advance reasonable reason for why goto should be
100% banished in all situation, especially when doing dynamic allocation or
resources. Maybe you don't even have ever read the original Dijsktra's paper
or the Knuth's paper
[http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pd...](http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf)
(curiously (or not) it's the case for many cargo cult goto haters even for
just the orinal Dijkstra's paper)

