Linked by Thom Holwerda on Mon 12th Mar 2012 19:00 UTC, submitted by yoni
Privacy, Security, Encryption "And just when you thought the whole Stuxnet/Duqu trojan saga couldn't get any crazier, a security firm who has been analyzing Duqu writes that it employs a programming language that they've never seen before." Pretty crazy, especially when you consider what some think the mystery language looks like "The unknown c++ looks like the older IBM compilers found in OS400 SYS38 and the oldest sys36.The C++ code was used to write the tcp/ip stack for the operating system and all of the communications."
Thread beginning with comment 510384
To read all comments associated with this story, please click here.
Not that I've ever tried it...
by daedalus on Tue 13th Mar 2012 10:46 UTC
Member since:

But surely if you write code in C for example, and just use a compiler you modified yourself along with some custom header files, the resulting binary wouldn't look like anything from any other known compiler, and hence wouldn't be relatable to a known language? It'll be roughly procedure and event-driven, and any language and compiler can do that. Write the code in a text editor instead of getting an IDE to generate it, use your custom compiler and include some reworked open source TCP/IP code that's modified sufficiently to not look like any other code, and that should do the job.

I'm no expert on these things, but am I missing something here?

Reply Score: 1

sithlord2 Member since:

Most of the time, it's relatively easy to see which programming language was used, by taking a look at the calling conventions: are parameters passed using the stack, or by using registers... If the stack is used, are they pushed from left to right, or right or left... etc...

Sure you can modify your compiler to change your calling conventions, but it would make it impossible to call external libraries + there is no real benefit (= it doesn't result in better code). Also, since C compilers compile to native code, it's still possible for a reverse-engineer what the code is doing, despite the modified calling convention.

I doubt those guys wrote their own compiler. They probably used some more obscure programming language for that piece of code, whatever the reason might be...

Edited 2012-03-13 15:49 UTC

Reply Parent Score: 2

Alfman Member since:


"Sure you can modify your compiler to change your calling conventions, but it would make it impossible to call external libraries + there is no real benefit (= it doesn't result in better code)."

It's usually not worth the immense development/maintenance burden, but I found that breaking with strict calling conventions can boost performance since you're not shifting registers around anywhere near as much to fit within a standard calling convention. If you look at ASM dumps frequently, you see a lot of functions have boilerplate MOVs just to get things in and out of place. This is often trivial to eliminate when your working in assembly without restraints.

Some day I envision optimizing compilers which can do inter-procedural optimizations without any calling convention at all to get rid of all that "useless" cruft. After all, the only time a calling convention truly matters is when calling a function of an external component/library.

C++ style exceptions might still might require a consistent stack frame, but a static calling convention like CDECL is not necessary.

Reply Parent Score: 2

Soulbender Member since:

there is no real benefit

Except if what you're trying to do is make it look like you created a new language.

I doubt those guys wrote their own compiler

Probably not but how much headlines is that going to create for your security company?

Reply Parent Score: 2