Tajemství Duqu rámce vyřešen

Pátrání po identifikaci

V mé předchozí blogpost o rámcové Duqu, jsem popsal jednu z největších zbývajících záhad asi Duqu - zvláštností C & C komunikačního modulu, který se zdá být napsána v jiném jazyce než zbytek kódu Duqu.Pokud jde o technické odborníky, jsme našli na tuto otázku velmi zajímavý a záhadný a my jsme chtěli sdílet s komunitou.

Zpětnou vazbu jsme dostali předčil naše nejdivočejší očekávání. Máme více než 200 připomínek a 60 a více e-mailové zprávy s návrhy o možných jazycích a rámců, které by byly použity pro generování rámcového Duqu kód. Rádi bychom říci velký "Děkujeme!" všem, kteří se podíleli na této cestě, aby nám pomohli identifikovat záhadný kód.

Podívejme nejoblíbenější návrhy jsme dostali od Vás:

• Varianty LISPu
• Dále
• Erlang
• Google Go
• Delphi
• OO C
• Staré kompilátory pro C + + a dalších jazycích

Díky některé velmi užitečné a znalý připomínky, můžeme nyní říci, s vysokým stupněm jistoty, že jsme našli správnou odpověď. Chtěl bych citovat nejdůležitější připomínky, které nám pomohlo vyřešit hádanku:

igorsk Simple Object Orientace (pro C)

Zdá se, že někdo po dobu reddit odst. http://www.reddit.com/r/ReverseEngineering/ ) jackpot: kód úryvky vypadají _very_ podobného, ​​co by to přinést: http:// daifukkat.su / wiki / index.php / SOO
Existuje několik dalších OO rámce pro C, ale oni neodpovídají také: http://ooc-coding.sourceforge.net/ http://sooc.sourceforge. net /

Jonwil Re: Ostatní C / C + +?

Viděl jsem, jak GCC pracuje interně a jeho ABI (pro množství různých verzí), a mohu potvrdit, že kód Duqu rozhodně není generován GCC. Nevím, jak ostatní C + + kompilátory práce, ale věci, které vidím v ASM (např. kde se odkazy na funkce odejít, jak "to" ukazatel je předán atd.) nevyplývá, že C + + se mi, ale něco úplně jiného. (Jako výše uvedené "objektově orientované" rámců pro C, které existují)

igorsk Re: Ostatní C / C + +?

jsem 99% jistý, strojový kód byl vytvořen MSVC. Je to něco, co budete mít pocit, který má zkušenosti, ale mohu poukázat na dvě věci, které jsou zcela charakteristické pro MSVC: 1), které používá ESI jako první kandidát na dočasné uskladnění, 2) "pop ecx" místo "add esp, 4" .

Také jsme obdrželi dvě velmi zajímavé e-mailové zprávy. Pascal Bertrand aka bps a další autor, který se raději zůstat v anonymitě navrhl, že kód byl generován z vlastní objektově orientované C dialekt, obecně zvané "OO C".

Připomínky byly velmi důležité, protože nám umožnila sledovat přesnou kompilátor používaný v projektu: Microsoft Visual Studio kompilátoru. Jsem strávil více času experimentovat s různými verzemi překladačů MSVC a různých zdrojových kódů a kompilace možností se snaží reprodukovat binární kód konstruktoru funkce uvedené v předchozí blogpost a nakonec podařilo.

Demontáž původního kódu Duqu: konstrukce spojené seznam třídy

Ručně rozložit C kód, který má stejný kód

Výše C kód, když sestaven s MSVC 2008 a možnosti / O1 (minimalizovat velikost) / OB1 (pouze rozšířit __ inline) vyrábí operační kódy shodné s těmi v binární Duqu. Změna pořadí operací a if / else bloky mění výsledný kód, MSVC 2005 kompilátor produkuje trochu jiný kód, taky. Takže lze říci, s vysokým stupněm jistoty, že výsledný binární byla sestavena s MSVC 2008 a možnosti / O1 / OB1 a vstupní zdrojový kód byl čistý C.

Takže, co to znamená? Stručně řečeno, existují dva velmi pravděpodobné odpovědi na naši úvodní otázku:

1. Kód byl psán používat vlastní OO C rámec založený na makra preprocesoru nebo vlastních směrnic.To bylo navrhl vaše komentáře, protože to je nejčastější způsob, jak zkombinovat objektově orientované programování s C.
2. Všechny kód byl napsán v C OO ručně, bez rozšíření do jazyka. Nemůžeme popřít, tuto možnost úplně, protože technicky je téměř nemožné rozlišit kód psaný s makro směrnic z ručně kopírování vložený kód.

Soudě podle množství podobně vypadající kódu v každém konstruktoru funkce a funkce členů, lze předpokládat, že zdrojový kód byl použit předzpracování a varianta 1 je blíže k pravdě.

Nyní existuje několik open-source "OO C" rámce k dispozici, a některé z nich vyrábějí kódu staveb, které jsou velmi podobné těm, které v kódu Duqu. Nejlepší zápas jsme našli, je SOO (Simple Object Orientace pro C), ale to nemohlo být použity v Duqu, protože to bylo jen zveřejněn při Trojan už ve volné přírodě.

Bez ohledu na to, která z těchto dvou variant je pravda, že důsledky jsou působivé. Užitečná knihovna obsahuje 95 kB na řízené událostmi kód napsaný s OO jazyka C, který nemá automatickou správu pamětí nebo bezpečné uvedeme. Tento druh programování je více obyčejně nachází v komplexu občanských států softwarových projektů, spíše než současný malware. Dále musí být celá akce řízené architektury byly vyvinuty jako součást kódu Duqu nebo jeho rozšíření OOC.

Neexistuje žádná jednoduchá vysvětlení, proč byl OO C namísto C + +, ale jsme viděli podobné případy v minulosti. S mluvil s některými lidmi, kteří dávají přednost takové techniky, dali dva hlavní důvody:

1. Oni nevěří C + + kompilátory, což jsou většinou lidé, kteří začali programovat v dávných dobách, kdy byl assembler nejlepší volba. C byla přímá evoluční krok po assembleru a rychle se stal standardem. Když C + + byla publikována, mnoho starých školních programátorů raději vyhýbat, protože nedůvěra v přidělování paměti a dalších temných jazykových prvků, které způsobují nepřímé provádění kódu (například konstruktéři).
2. Extrémní přenositelnost. Ještě jednou, za starých časů (10-12 let) C + + není zcela standardizována a to bylo možné, aby C + + kód, který by se kompilovat MSVC ale nekompiluje se s (řekněme) Watcom C + +. Pokud byste chtěli jít na extrémní přenositelnost a zaměřit všechny stávající platformu venku, měli byste jít s C.

Oba důvody se objeví uveďte kód byl napsán týmem zkušených, "staré školy" vývojářů.

Závěry

• Rámcová Duqu se skládá z "C" kód kompilován s MSVC 2008 pomocí speciální volby "/ O1" a "/" OB1
• Kód byl pravděpodobně napsán s vlastní rozšíření C, obecně nazýván "OO C"
• Event-driven architektury byl vyvinut jako součást rámce Duqu nebo jeho rozšíření OO C
• C & C kód mohl být znovu z již existujícího softwarového projektu a je začleněn do trojan Duqu

Všechny výše uvedené závěry ukazují spíše profesionální tým vývojářů, které se zdají být opětovné použití staršího kódu napsaný top "old school" vývojářů. Tyto techniky jsou běžně vidět v profesionální software a téměř nikdy v dnešní malware. Opět se jedná naznačují, že Duqu, stejně jako Stuxnet, je "jediná svého druhu" kus malware, který vyniká jako klenot z velkého množství "němý" škodlivého programu jsme normálně vidět.