Live data from Hacker News

Kaspersky: Duqu Trojan uses 'unknown programming language'

zdnet.com

91–100 of 122 posts

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#91
post #18

Writing an unpolished programming language isn't that much work in comparison to writing a complex virus. Especially low level languages where instructions map pretty closely to the CPU instructions are easy to create. I think it makes a lot of sense to write a custom programming language/compiler because virus scanners tend to use fingerprints to recognize dangerous pieces of code. So you want a compiler that delibe…

It's particularly hard to obfuscate when anything produced by your compiler gets marked as a virus: http://community.norton.com/t5/Norton-Internet-Security-Nort...

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#93
post #50

I will be repeating a notion I read on YCombinator elsewhere - but I, too, find it incredibly cool that we live in a time when wars are fought online like that. We have online revolutionaries anarchists and REAL nation-wide revolutions, started on online networks (talking about Arabic Spring here); we got FBI agents, looking through IP addresses on IRC networks to catch a small group of bragging attackers; we got inv…

It's very cool from a geek / technological point of view but I can't help but think that non-lifesaving technology ultimately brings us little good, if you look at the big picture.

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#94

I've seen the theory that Stuxnet/Duqu was developed by a state thrown around a lot, but what's the actual evidence? It's not particularly hard to write a simple programming language. Worms are very specialized pieces of code. It doesn't seem that crazy that someone would create a language tailored for worm development.

Considering the facts that are known (e.g.: http://www.digitalbond.com/2012/01/31/langners-stuxnet-deep-...) it is nigh impossible for Stuxnet to be commissioned by a nongovernmental entity.

The sheer complexity is off the charts. Stuxnet's sophistication and complexity is an cybernetic equivalent of Manhattan project. E.g.: As a domain expert on industrial automation of this kind Langners states that whoever created Stuxnet _had to have a testing facility_. How many hackers do you know who build uranium enrichment centrifuges to test their cyber attack tools?

Yeah thought so.

Edit: TL;DR: There are two pieces of evidence. No.1: Motive, No.2: Sophistication and complexity.

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#95
post #50

I will be repeating a notion I read on YCombinator elsewhere - but I, too, find it incredibly cool that we live in a time when wars are fought online like that. We have online revolutionaries anarchists and REAL nation-wide revolutions, started on online networks (talking about Arabic Spring here); we got FBI agents, looking through IP addresses on IRC networks to catch a small group of bragging attackers; we got inv…

Yes, we live in the cyberpunk future.

"High tech meets low life".

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#96
post #48

Earlier quoted context omitted.

The inconsistent placement of the "this" argument in function calls seems to support this being C. The vtable moving around would indicate that each class layout is hand-written, though.

Yeah, the author made a point of noting "this" could be in a register or the stack, but that to me just says "C". The functions moving around wouldn't necessarily mean it is written by hand, though. There just needs to be some rules governing the system and we don't know what those rules are (yet). I would just be very surprised if this is anything other than some convention developed on top of C.

Differing calling conventions can point to combination of hand crafted object system in C with some custom code generator with some high level input that produces machine code directly without C in between. When you generate machine code that does not directly interface with system libraries it is often useful to ignore platform ABI calling conventions and make up your own.

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#97

is it dumb to suggest that someone who understands c++ (or other compiled oo language) would/could write assembler in this way? just from reading the description (things like variable locations of method tables, various registers for "this", and lack of memory management) it sounds like it could be handwritten, but structured in a similar way to c++.

The disassembly snippet looks like typical C/assembly handcrafted object system without real classes, but responses by Kaspersky guys in blog comments seem to imply that it uses these objects even in places where it is highly impractical when writing code manually. So it's possibly C/assembly written by typical hardcore Java programmer, but I find that highly unlikely.

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#98
post #48

Earlier quoted context omitted.

The inconsistent placement of the "this" argument in function calls seems to support this being C. The vtable moving around would indicate that each class layout is hand-written, though.

Yeah, the author made a point of noting "this" could be in a register or the stack, but that to me just says "C". The functions moving around wouldn't necessarily mean it is written by hand, though. There just needs to be some rules governing the system and we don't know what those rules are (yet). I would just be very surprised if this is anything other than some convention developed on top of C.

I don't immediately see why it would be putting arbitrary data in front of the vtable unless it's done by a person. Do you have any ideas?

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#99
post #96

Earlier quoted context omitted.

Yeah, the author made a point of noting "this" could be in a register or the stack, but that to me just says "C". The functions moving around wouldn't necessarily mean it is written by hand, though. There just needs to be some rules governing the system and we don't know what those rules are (yet). I would just be very surprised if this is anything other than some convention developed on top of C.

Differing calling conventions can point to combination of hand crafted object system in C with some custom code generator with some high level input that produces machine code directly without C in between. When you generate machine code that does not directly interface with system libraries it is often useful to ignore platform ABI calling conventions and make up your own.

Perhaps they use some kind of right-to-left fastcall convention. Or maybe they are just unconventional, putting "this" at the end of the parameter list, hence ending up in different registers or the stack depending on the number of arguments?

Re: Kaspersky: Duqu Trojan uses 'unknown programming language'

#100
post #8

This is one of the most interesting netsec (if not THE most) questions of our time. We have what is effectively an alien virus, given how advanced it was, its construction and spawing of duqu and being written in an unknown language. This is serious awesome cyberpunk stuff - but scary as hell at the same time. With the revelation of Stuxnet and Duqu, NOBODY should think anything they do/say online is safe.

Read some hacker/cracker zines from the late 80's/early 90's (Phrack, 2600, etc being the well known ones) and you'll quickly gain a deep perspective on the pace of computing/IT security advancement over the decades. Stuxnet and Duqu will suddenly appear to be a minor revisions of 20 year old technology/techniques. You'll see code for polymorphic engines written in TurboPascal suddenly break out into obscured x86 assembler interrupt handlers. Detailed analysis of reverse engineering efforts against "packed" code on foreign and obscure architectures. And the word "cyber" used in all seriousness.

It is quite amusing to see how many old ideas from the dawn of computing have been reinvented multiple times over the years.

Post reply on HN