'Duqu-trojan deels geschreven in onbekende programmeertaal'
Kaspersky Lab heeft na een analyse van de Duqu-trojan een onderdeel gevonden dat in een tot nu toe onbekende programmeertaal zou zijn geschreven. De Russische beveiligingsfirma vraagt daarom programmeurs om hulp.
De Duqu-trojan, dat is gespecialiseerd in het aanbrengen van een achterdeurtje op besmette systemen, is grotendeels identiek aan de code van Stuxnet, de malware die poogde scada-systemen van het Iraanse kernprogramma te saboteren. Na een grondige analyse van de code concludeert Kaspersky Lab dat een onderdeel dat contact maakt met een command and control-server, oftewel de payload-dll, in een onbekende programmeertaal is geschreven, terwijl de overige onderdelen bestaan uit C++-code en er gebruik is gemaakt van de Microsoft Visual C++ 2008-compiler. Kasperky sluit uit dat het 'mysterieuze' Duqu-onderdeel is geschreven in Python, Java, Objective C, Ada of Lua.
Volgens de Russische malware-onderzoekers is het mogelijk dat de Duqu-programmeurs een eigen framework hebben gebouwd om zelfgeschreven C-code met een eigen compiler te compileren of dat er een tot nu toe onbekende taal is ontwikkeld. Het 'Duqu-framework' blijkt bovendien zeer veelzijdig in zijn mogelijkheden. Zo kan de betreffende module op diverse manieren contact maken met de c&c-servers, onder andere via http, proxy servers en netwerk-sockets. Ook kan de module http-requests van de server afhandelen en is het in staat om buitgemaakte informatie door te sturen of nieuwe malware-code te injecteren op andere met Duqu besmette systemen binnen een netwerk.
Met de aanwijzingen dat de bouwers van de Duqu-malware een eigen programmeertaal hebben ontwikkeld, lijkt het niet ondenkbaar dat de betreffende programmeurs niet alleen zeer vakkundig waren, maar vermoedelijk ook over ruime financiële middelen beschikten. Verder sluit Kaspersky niet uit dat de c&c-module door een ander team is geschreven en pas later aan de overige Duqu-onderdelen is toegevoegd. Om het 'mysterie' rondom de c&c-module op te lossen, vraagt Kaspersky Lab om hulp van de ontwikkelgemeenschap.
Reacties (118)
Wie weet. Het komt nog wel een keer zover.
Mijn programmeerkennis stamt nog uit de Commodore Amiga tijd - ietsje verouderd dus,
Wat ik mij afvraag: hoe kan je aan een binary zien in welke programmeertaal die geschreven is?
(er van uitgaande dat 'ie gestript is van onnodige debug-info natuurlijk)
Wat ik mij afvraag: hoe kan je aan een binary zien in welke programmeertaal die geschreven is?
(er van uitgaande dat 'ie gestript is van onnodige debug-info natuurlijk)
Omdat een compiler bepaalde code op een bepaalde manier omzet. Een soort vingerafdruk van de compiler zeg maar. Als je weet welke compiler weet je natuurlijk ook welke taal. Daarom vind ik het ook sterk dat men het over een 'onbekende programmeertaal' heeft en de conclusie dat het directe assembler is blijkbaar al heeft uitgesloten? Die is ook niet zo te identificeren. Misschien heeft men wel de compiler alles om laten zetten naar assembler en gepoogd direct in assembler sporen te wissen in het C&C deel ofzo.
@elmuerte: dan herkent men dus ook niet nee, want daar kennen ze geen vingerafdruk van, maar dat kost erg veel tijd en is onwaarschijnlijk. Ongeveer zoiets (maar dan in afgeslankte vorm) bedoelt men met 'eigen framework'.
@elmuerte: dan herkent men dus ook niet nee, want daar kennen ze geen vingerafdruk van, maar dat kost erg veel tijd en is onwaarschijnlijk. Ongeveer zoiets (maar dan in afgeslankte vorm) bedoelt men met 'eigen framework'.
[Reactie gewijzigd door ktf op 8 maart 2012 19:35]
En wat nou als ze hun eigen C compiler gemaakt hebben, bekende programmeertaal, maar onbekende compiler.
wat als men direct in assembly gewerkt heeft?
of kan dat niet in dit geval, hoedanook wel erg apart en toch interessant,
dit is dus echt geen standaard huis tuin en keuken virus, men wist dat het speciaal was maar zo geraffineerd had niemand verwacht denk ik.
of kan dat niet in dit geval, hoedanook wel erg apart en toch interessant,
dit is dus echt geen standaard huis tuin en keuken virus, men wist dat het speciaal was maar zo geraffineerd had niemand verwacht denk ik.
Dat lijkt me onwaarschijnlijk. Het artikel claimt dat er sprake is van een event-driven en object oriented gedrag. Typisch kenmerken van hogere talen, hoger dan C zelfs.
Volgens mij wordt gebruik van Objective C (van Apple) niet uitgesloten. Er worden echter geen verwijzingen naar de standaard bibliotheek gemaakt en de compiler komt ook niet bekend voor. Dat maakt het onwaarschijnlijk of hoogst opmerkelijk.
Een van de suggesties is dat er een taal of framework is gebruikt dat zo is geimplementeerd dat deze naar C compileert. Dat is overigens niet ongebruikelijk: de meest gebruikte Python implementatie werkt ook zo. (onzin)
@onder: ik zit ernaast: CPython compileert naar Bytecode, niet naar C.
Wat ik zelf bijzonder vindt is dat er voor object-orientatie is gekozen. Dat was in jaren 90 het toverwoord, maar de ontwikkelaars van nieuwe talen lijken zich nu massaal of functionele en/of concurrent talen te werpen.
Tot slot wordt nergens de vraag gesteld WAAROM de schrijvers voor deze aanpak hadden gekozen. Verbetert dit de kans dat het virus onopgemerkt blijft? Is deze sowieso moeilijke te bestrijden omdat decompileren niet mogelijk is? Was het gewoon een hobby-ding van de virus-schrijvers? Ik ben benieuwd om iemand hierop durft te speculeren.
Volgens mij wordt gebruik van Objective C (van Apple) niet uitgesloten. Er worden echter geen verwijzingen naar de standaard bibliotheek gemaakt en de compiler komt ook niet bekend voor. Dat maakt het onwaarschijnlijk of hoogst opmerkelijk.
Een van de suggesties is dat er een taal of framework is gebruikt dat zo is geimplementeerd dat deze naar C compileert. Dat is overigens niet ongebruikelijk: de meest gebruikte Python implementatie werkt ook zo. (onzin)
@onder: ik zit ernaast: CPython compileert naar Bytecode, niet naar C.
Wat ik zelf bijzonder vindt is dat er voor object-orientatie is gekozen. Dat was in jaren 90 het toverwoord, maar de ontwikkelaars van nieuwe talen lijken zich nu massaal of functionele en/of concurrent talen te werpen.
Tot slot wordt nergens de vraag gesteld WAAROM de schrijvers voor deze aanpak hadden gekozen. Verbetert dit de kans dat het virus onopgemerkt blijft? Is deze sowieso moeilijke te bestrijden omdat decompileren niet mogelijk is? Was het gewoon een hobby-ding van de virus-schrijvers? Ik ben benieuwd om iemand hierop durft te speculeren.
[Reactie gewijzigd door snirpsnirp op 8 maart 2012 23:15]
Een van de suggesties is dat er een taal of framework is gebruikt dat zo is geimplementeerd dat deze naar C compileert. Dat is overigens niet ongebruikelijk: de meest gebruikte Python implementatie werkt ook zo.
ctypes?
Tot slot wordt nergens de vraag gesteld WAAROM de schrijvers voor deze aanpak hadden gekozen. Verbetert dit de kans dat het virus onopgemerkt blijft? Is deze sowieso moeilijke te bestrijden omdat decompileren niet mogelijk is?
Om de c&c servers zoveel mogelijk buiten schot te houden?
ctypes?
Tot slot wordt nergens de vraag gesteld WAAROM de schrijvers voor deze aanpak hadden gekozen. Verbetert dit de kans dat het virus onopgemerkt blijft? Is deze sowieso moeilijke te bestrijden omdat decompileren niet mogelijk is?
Om de c&c servers zoveel mogelijk buiten schot te houden?
OOP is de standaard van tegenwoordig, helemaal niet raar dus. Veelgebruikte/bekende talen van tegenwoordig: C#, Java, VB.NET, C++, Python, PHP en Javascript hebben allemaal volledige ondersteuning voor OOP en in de eerste twee kun je zelfs nauwelijks anders.Wat ik zelf bijzonder vindt is dat er voor object-orientatie is gekozen. Dat was in jaren 90 het toverwoord, maar de ontwikkelaars van nieuwe talen lijken zich nu massaal of functionele en/of concurrent talen te werpen.
Nu OOP volwassen is en er weinig ontwikkeling meer op is kijkt men natuurlijk verder voor nieuwe mogelijkheden, maar voor algemene programmeertaken is OOP op dit moment juist keuze bij uitstek
Het verbaast me ook niet zozeer dat software geschreven is een object-georienteerde taal. Het verbaast me een beetje dat daarvoor gekozen is bij een schijnbaar nieuwe taal. Daar lijkt het hier namelijk om te gaan.
Niet alleen heeft een compiler een vingerafdruk, maar ook een programmeertaal. Voor diverse programmeertalen zijn er afspraken hoe er met de stack omgegaan wordt, e.d. Dit om linken van object bestanden mogelijk te maken tussen programmeertalen. Zie: http://en.wikipedia.org/wiki/Calling_convention En zo zijn er meer voorbeelden. Bijvoorbeeld voor Perl zou men de Perl compiler/interpreter moeten bijsluiten in C code (kan), en zou men of Perl source terug moeten vinden, of zal men C code vinden die duidelijk diverse Perl afspraken volgt.
Verder is een eigen programmeertaal maken niet zo heel ingewikkeld, zeker niet als die specifiek voor een bepaald domein is (bijvoorbeeld alleen integer bewerkingen, eenvoudige datastructuren, enz.). De gereedschappen om dat soort dingen te doen zijn gratis en volop aanwezig.
Wellicht geen "direct assembly" omdat a) dat nogal wat veel werk is en b) ik aanneem dat de onderzoekers slim genoeg zijn om dat op het lijstje te plaatsen als dat een optie was. M.b.t. dat laatste: ik gok dat men een duidelijke calling convention gevonden heeft, maar dat deze afwijkt van de opgesomde talen.
Verder is een eigen programmeertaal maken niet zo heel ingewikkeld, zeker niet als die specifiek voor een bepaald domein is (bijvoorbeeld alleen integer bewerkingen, eenvoudige datastructuren, enz.). De gereedschappen om dat soort dingen te doen zijn gratis en volop aanwezig.
Wellicht geen "direct assembly" omdat a) dat nogal wat veel werk is en b) ik aanneem dat de onderzoekers slim genoeg zijn om dat op het lijstje te plaatsen als dat een optie was. M.b.t. dat laatste: ik gok dat men een duidelijke calling convention gevonden heeft, maar dat deze afwijkt van de opgesomde talen.
[Reactie gewijzigd door J.J.J. Bokma op 8 maart 2012 19:54]
Het is relatief. Ik denk dat er daarom ook "other language / c framework" staat. Als je een constuctie maakt in c met pointers en directe hardwaretoegang, eventueel met blokken assembly erbij en vervolgens alle handelingen opdeelt in functies die met een zelfbedachte syntaxis worden aangeroepen heb je iets wat op een programmeertaal lijkt.
Daarna kan je die function-calls weer samenvatten dmv een andere zelfbedachte syntaxis en je hebt een programmeertaal die een level hoger is.
Daarna kan je die function-calls weer samenvatten dmv een andere zelfbedachte syntaxis en je hebt een programmeertaal die een level hoger is.
C heeft pointers, en directe hardware toegang. En er zijn C compilers die inline assembly toestaan (zie bv. http://ibiblio.org/gferg/...ne-Assembly-HOWTO.html#s4 ).
Maar het maken van een domeinspecifieke taal is echt niet zo moeilijk. Het is een mooie opdracht voor een compiler vak aan een HTS/universiteit.
Maar het maken van een domeinspecifieke taal is echt niet zo moeilijk. Het is een mooie opdracht voor een compiler vak aan een HTS/universiteit.
Ik zat ook te denken dat het direct in assembly is geschreven, dus was zeer benieuwd waarom ze dit hebben uitgesloten, dit zijn hun conclusies:
Conclusions
- The Duqu Framework appears to have been written in an unknown programming language.
- Unlike the rest of the Duqu body, it's not C++ and it's not compiled with Microsoft's Visual C++ 2008.
- The highly event driven architecture points to code which was designed to be used in pretty much any kind of conditions, including asynchronous commutations.
- Given the size of the Duqu project, it is possible that another team was responsible for the framework than the team which created the drivers and wrote the system infection and exploits.
- The mysterious programming language is definitively NOT C++, Objective C, Java, Python, Ada, Lua and many other languages we have checked.
- Compared to Stuxnet (entirely written in MSVC++), this is one of the defining particularities of the Duqu framework.
Ze hebben over 'highly event driven architecture' en 'asynchronous communications'. Dat krijg je in pure assembly simpelweg niet voor elkaar.
Uiteindelijk gaat een programmeertaal door een assembler en wordt het assembly, dus aan assembly ligt het niet. Wat jij bedoelt is dat het niet te doen is voor een programmeur, ik zou willen zeggen dat het niet te doen is voor de meeste programmeurs. De hoeveelheid programmeurs die een moderne assembler kunnen bouwen is ook niet al te groot...
Klassieke talen zoals Cobol, Fortran, Haskell of Pascal zijn ook nog mogelijk. Vooral voor industriele frames wordt dit nog steeds toegepast. Zeker gezien de oorsprong van het virus lijkt me dat geen vreemd uitgangspunt.
(overigens wordt niet uitgesloten dat het wél in C geschreven is, maar dan zonder een bekend framework)
(overigens wordt niet uitgesloten dat het wél in C geschreven is, maar dan zonder een bekend framework)
[Reactie gewijzigd door -RetroX- op 8 maart 2012 21:11]
"Haskell .... nog steeds" Sinds wanneer is Haskell antiek ? ;-). Verder, voor Haskell zal er de nodige code meegelinkt moeten worden, die duidelijk herkenbaar is.
[Reactie gewijzigd door J.J.J. Bokma op 8 maart 2012 20:41]
antiek? Dat maak jij ervan. Ik zeg klassiek: zoals een taal die al een tijdje mee gaat. Deze talen worden zeer zeker nog gebruikt.
Ik heb de code zelf niet gezien dus geen idee wat het precies is maar juist vanwege het doelsysteem lijken mij deze 4 het handigste. Maar in hoeverre ze te herkennen zijn zou ik niet weten, het is zeker 15 jaar terug sinds ik iets gedaan heb met cobol en pascal.
Ik heb de code zelf niet gezien dus geen idee wat het precies is maar juist vanwege het doelsysteem lijken mij deze 4 het handigste. Maar in hoeverre ze te herkennen zijn zou ik niet weten, het is zeker 15 jaar terug sinds ik iets gedaan heb met cobol en pascal.
[Reactie gewijzigd door -RetroX- op 8 maart 2012 21:16]
Je hebt gelijk, ik las "antiek", maar het is klassiek. Maar goed, waarom is Haskell klassiek? Lijkt mij een beetje onzin om een taal die net iets meer dan 20 jaar oud is "klassiek" te noemen, zeker als een enorm groot deel van de programmeurs er nog nooit in geprogrammeerd heeft [1]. Zijn Perl en Python ook klassiek?
Qua zeer zeker gebruikt, ik denk dat je kan zeggen dat Haskell pas recent (de laatste 5 jaar of zo) aan een langzame opmars bezig is. Kortom, het lijkt mij extreem onwaarschijnlijk dat Haskell gebruikt is, ook omdat de runtime duidelijk herkenbaar zou moeten zijn (RTS). Dit sluit ook eigenlijk talen als Perl, Python, etc. uit. Elk heeft een redelijk grote runtime nodig (garbage collection, ondersteuning voor dynamische datastructuren, etc.).
[1] Ik toevallig wel, Miranda/Gofer, begin jaren 90. Ben ik nu een klassieke programmeur?
Qua zeer zeker gebruikt, ik denk dat je kan zeggen dat Haskell pas recent (de laatste 5 jaar of zo) aan een langzame opmars bezig is. Kortom, het lijkt mij extreem onwaarschijnlijk dat Haskell gebruikt is, ook omdat de runtime duidelijk herkenbaar zou moeten zijn (RTS). Dit sluit ook eigenlijk talen als Perl, Python, etc. uit. Elk heeft een redelijk grote runtime nodig (garbage collection, ondersteuning voor dynamische datastructuren, etc.).
[1] Ik toevallig wel, Miranda/Gofer, begin jaren 90. Ben ik nu een klassieke programmeur?
@ j.J.J. Bokma:
Ik denk niet dat Retrox 'klassiek' bedoelt met 'oud', maar meer in de trant van gevestigd/basis, zoals het adagium "Ken uw klassieken".
Uiteindelijk heeft het dus weinig met leeftijd te maken. Iets relatief nieuws kan al snel een klassieker worden, zeker in de IT wereld.
Ik denk niet dat Retrox 'klassiek' bedoelt met 'oud', maar meer in de trant van gevestigd/basis, zoals het adagium "Ken uw klassieken".
Uiteindelijk heeft het dus weinig met leeftijd te maken. Iets relatief nieuws kan al snel een klassieker worden, zeker in de IT wereld.
[Reactie gewijzigd door Fireshade op 8 maart 2012 22:58]
Maar dan is het nog vreemder om met Haskell aan te komen zetten, ik denk niet dat je Haskell gevestigd noch basis kan noemen ;-).
Haskell, de taal waar 100x meer OVER dan IN geschreven is...
Onzin, de compiler zet high-level code in low-level assembly om. Alles wat jij in een hogere taal in elkaar knutselt kan een assembly guru in de helff van de ruimte en 2x zo snel qua runtime maken (afhankelijk van de kwaliteit van de compiler, maar MSVCC is nou niet direkt top-of-the-line qua compiler). Dat het ongebruikelijk is klopt wel, de meeste mensen zouden niet weten waar te beginnen als ze teruggeworpen worden qua platform en alles zelf moeten doen, neemt niet weg dat er genoeg hele slimme mensen rondlopen die dit nog leuk vinden ook (ik niet meer zo, heeft toch een hoog gehalte werkverschaffing).
En dat laatste maakt een domein-specifieke taal waarschijnlijker ;-). Er zijn niet veel mensen die handmatig betere code op kunnen leveren dan een goede compiler en het vreet tijd.
hele goede vraag, hier wil ik het antwoord ook wel op weten... <nieuwsgierige 2dejaars TI student> 
Ik ben zelf geen 'oude rot' met assembler/machine code, maar volgens mij kan je een binary die machine code of bytecode bevat 'decompilen', dus omzetten naar een hogere taal. Stel dat je gewoon een bende CPU instructies hebt, die in een bepaalde volgorde staan, dan zou je kunnen kijken naar de manier waarop ze geordend en gebruikt worden kunnen kijken welke compiler dat op die manier zou kunnen doen. Stel dat je bijv. C en C++ hebt, dan zou het kunnen dat een bepaalde volgorde of combinatie alleen in C++ voor kan komen, en dan weet je dus dat het C++ is. Nu is het natuurlijk niet zo simpel, maar daar komt het in de eerste instantie wel op neer.
Bij decompilen moet je al weten welke taal het is lijkt me, je moet een compiler van die taal hebben die 'andersom' werkt.
Dan heb je nog beschrijvingen en magic numbers, soms staat in een bestand gewoon beschreven wat/hoe/waarom het is. Je hebt in de meeste Win32 applicaties bijv. een 'This program cannot be run in DOS mode' lijn zitten, dat zit vaak in de kop van het bestand in een uiterst compacte stub die door DOS uitgevoerd kan worden en niks anders doet dan die regel uitprinten naar het scherm en afsluiten. Een magic number is dan weer een aantal bytes, dat een bepaald bestand zou kunnen identificeren. Stel dat je een JPEG bestand hebt (bevat uit een aantal onderdelen - hoewel het gewoon een bende binaire data is), dan begint dat bestand altijd met een bepaalde reeks bytes. Dat is met ingepakte binaries die uitgevoerd kunnen worden ook zo. Daar zit dan wat minder variatie in, maar je kan bijv met het unix/linux hulpprogramma 'file' meestal door die magic numbers te gebruiken wel weten wat het bestand is. Ook als er geen bestandsextensie is.
Nu zal het bij de DLL die hier gepresenteerd is een specifiek verhaal zijn, want een DLL is een binair bestand dat specifiek voor een bepaald doel gecompileerd is. Een bibliotheek bestand, voor de win32 omgeving. Dat is bijv. al informatie. Dan kan je verder kijken naar aanwijzingen wat er in het DLL bestand gebeurd, bijv. met een debugger, en hexeditor. En zo kan je dan door gaan, tot je iets tegen komt dat niet door een bekende decompiler of interceptor begrepen kan worden, en dan heb je dus een stuk code wat je niet kan 'lezen'. Dan kan je stellen dat je dan 'gewoon lekker machinecode gaat lezen', maar daar zal je je vies op verkijken
Want in 1 KB zitten zo veel machine code instructies, daar ben je wel een dag zoet mee.
Bij decompilen moet je al weten welke taal het is lijkt me, je moet een compiler van die taal hebben die 'andersom' werkt.
Dan heb je nog beschrijvingen en magic numbers, soms staat in een bestand gewoon beschreven wat/hoe/waarom het is. Je hebt in de meeste Win32 applicaties bijv. een 'This program cannot be run in DOS mode' lijn zitten, dat zit vaak in de kop van het bestand in een uiterst compacte stub die door DOS uitgevoerd kan worden en niks anders doet dan die regel uitprinten naar het scherm en afsluiten. Een magic number is dan weer een aantal bytes, dat een bepaald bestand zou kunnen identificeren. Stel dat je een JPEG bestand hebt (bevat uit een aantal onderdelen - hoewel het gewoon een bende binaire data is), dan begint dat bestand altijd met een bepaalde reeks bytes. Dat is met ingepakte binaries die uitgevoerd kunnen worden ook zo. Daar zit dan wat minder variatie in, maar je kan bijv met het unix/linux hulpprogramma 'file' meestal door die magic numbers te gebruiken wel weten wat het bestand is. Ook als er geen bestandsextensie is.
Nu zal het bij de DLL die hier gepresenteerd is een specifiek verhaal zijn, want een DLL is een binair bestand dat specifiek voor een bepaald doel gecompileerd is. Een bibliotheek bestand, voor de win32 omgeving. Dat is bijv. al informatie. Dan kan je verder kijken naar aanwijzingen wat er in het DLL bestand gebeurd, bijv. met een debugger, en hexeditor. En zo kan je dan door gaan, tot je iets tegen komt dat niet door een bekende decompiler of interceptor begrepen kan worden, en dan heb je dus een stuk code wat je niet kan 'lezen'. Dan kan je stellen dat je dan 'gewoon lekker machinecode gaat lezen', maar daar zal je je vies op verkijken
Want in 1 KB zitten zo veel machine code instructies, daar ben je wel een dag zoet mee.
IDA Pro is een bekende professionele disassembler op
http://www.hex-rays.com/p...t/download_freeware.shtml
kun je een oudere versie downloaden is niet commercieel gebruik !! maar wel nuttig
http://www.hex-rays.com/p...t/download_freeware.shtml
kun je een oudere versie downloaden is niet commercieel gebruik !! maar wel nuttig
Ik heb ooit eens in basic een macro-assembler geschreven voor een atari 800xl. Echt simpel met een eigen bibliotheek van functies. Die 1k proggies werkte als een trein, supersnel maar als je dan de machinecode bekeek en met name naar patronen dan viel het me op dat de standaard assembler andere patronen opleverde dan die van mij. Het is maar net hoe een programmeur bepaalde problemen zoals b.v. memory en code management oplost. Elke compiler of assembler geeft daardoor een eigen fingerprint af en kennelijk heeft er eentje 6 maanden op een zolder achter een scherm gezeten en een eigen vertaalmachientje bedacht. Vind die assembler of compiler en je hebt een spoor...
"Die 1k proggies" - klinkt een beetje als 'page 6' :-)
Wanneer ze kleiner moesten zijn dan 256 bytes, yup, dan was het page 6 (een geheugen segmentje op de Atari 600 xl en 800 xl dat niet werd gebruikt door het systeem). Dat hield je tenminste scherp op een 8 bitter!
ftp://ftp.cs.wisc.edu/paradyn/papers/Rosenblum10prov.pdf
Hier wordt uitgelegd hoe je de code die een compiler produceert kunt herkennen
Verder meen ik me te herinneren dat pascal en C++ de parameters in een andere volgorde naar de stack pushen
Hier wordt uitgelegd hoe je de code die een compiler produceert kunt herkennen
Verder meen ik me te herinneren dat pascal en C++ de parameters in een andere volgorde naar de stack pushen
[Reactie gewijzigd door (id)init op 8 maart 2012 19:57]
Correctos, Nuttig document.
Ik geloof dat er nog c++ compilers zijn gemaakt (wel lang geleden) die de parameters ook omgekeerd de stack opzetten in een (naïeve) poging buffer overflows tegen te gaan.
Ik heb zelf in het DOS tijdperk ooit eens een macro library gemaakt voor assemblers. Daarmee kon ik routines met macro's voorzien van correcte C of pascal call interfaces zonder zelf de details iedere keer opnieuw uit te hoeven werken. Van conventie veranderen was niets anders dan een taal definitie in de top van je source omzetten.
Zelfs voor de High en Low words/bytes waren door het genereren van nieuwe labels meteen benaderbaar op de stack. Verder heb ik destijds nog een eigen in theorie snellere conventie bedacht, maar zonder support daarvoor vanuit een hogere taal was dat niet zo bruikbaar.
Het moet dus niet al te lastig zijn om iets unieks te maken dat daardoor niet makkelijk herkend wordt.
Ik heb een heel oude routine die er gebruik van maakt gevonden, dat verduidelijkt het een en ander. Sommige delen worden helaas met emoticons vervangen, maar het idee is duidelijk.
Code vervangen door een download: http://members.chello.nl/p.heer3/asm.zip
common.mac
f_crect.asm
De eerste is de macro library, de 2e een VGA copieer routine.
Een nieuwere (1993) versie van de library: http://members.chello.nl/p.heer3/asm2.zip
Zelfs voor de High en Low words/bytes waren door het genereren van nieuwe labels meteen benaderbaar op de stack. Verder heb ik destijds nog een eigen in theorie snellere conventie bedacht, maar zonder support daarvoor vanuit een hogere taal was dat niet zo bruikbaar.
Het moet dus niet al te lastig zijn om iets unieks te maken dat daardoor niet makkelijk herkend wordt.
Ik heb een heel oude routine die er gebruik van maakt gevonden, dat verduidelijkt het een en ander. Sommige delen worden helaas met emoticons vervangen, maar het idee is duidelijk.
Code vervangen door een download: http://members.chello.nl/p.heer3/asm.zip
common.mac
f_crect.asm
De eerste is de macro library, de 2e een VGA copieer routine.
Een nieuwere (1993) versie van de library: http://members.chello.nl/p.heer3/asm2.zip
[Reactie gewijzigd door TheCodeForce op 8 maart 2012 21:24]
Lachen, uit het doom tijdperk.
Heb niet zo heel veel later nog een printerdriver met dithering moeten bouwen in C, echt pixeln**ken dus
Memories.....
Heb niet zo heel veel later nog een printerdriver met dithering moeten bouwen in C, echt pixeln**ken dus
Memories.....
Verschillende programmeertalen (compilers) varieren bijvoorbeeld in de afhandeling van lokale variabelen op de stack. De aanroeper kan verplicht zijn om zijn interne variabelen op de stack zetten voor de call naar de aangeroepen functie, omdat de registers door de aangeroepen functie overschreven kunnen worden. In het andere geval is de aangeroepen functie verplicht om de registers die intern nodig zijn bij terugkeer de oude waarde tegeven.
Ook de volgorde van de waarden op de stack kunnen varieren, bijvoorbeeld de positie van parameters ten opzichte van het returnadres.
Ik weet dat je in C een Pascal-style aanroep kon doen, die de bovenstaande regeltjes aanpaste. Maar wie nou welke toepaste....
Ook de volgorde van de waarden op de stack kunnen varieren, bijvoorbeeld de positie van parameters ten opzichte van het returnadres.
Ik weet dat je in C een Pascal-style aanroep kon doen, die de bovenstaande regeltjes aanpaste. Maar wie nou welke toepaste....
Volgens mij moet dat wel een kostbare investering zijn, die niet zomaar 1,2,3 door 'hackers' groep opgezet kan worden. Denk, gezien het Stuxnet verhaal, dat er Israëlische dan wel Amerikaanse gelden ingezet zijn om zoiets te ontwikkelen.
Benieuwd of er meer onthuld gaat worden op korte termijn.
Benieuwd of er meer onthuld gaat worden op korte termijn.
Werp eens een blik op diverse open source projecten. Het is verbazingwekkend wat een groep mensen in korte tijd en in hun vrije tijd voor elkaar kunnen krijgen.
Inderdaad, deze taal is vrij wel zeker ontwikkeld door hackers. Het is niet moeilijk een virus te schrijven dat niet te detecteren is, zelfs in een bekende taal gaat dat.(als je kan programmeren)
Waarom zou hier veel geld in zitten? Als je niet wilt dat de rest van de wereld er niet van op de hoogte wordt gebracht ga je niet experts inhuren, de kans is veel te groot dat iets lekt. Je gaat aan de slag met een kleine groep die je vertrouwd. En aangezien dit wordt gebruikt voor illegale praktijken, lijkt het me ook niet vergezocht dat het gefinancierd wordt door illegaal verkregen geld. En als je geen belasting betaald en geen rare dingen doet heb je eigenlijk helemaal niet zoveel geld nodig om te kunnen leven en dat kan dan prima gefinancierd worden door een CC 'kraak' of iets dergelijks.
Ik denk niet dat er veel mensen zijn die het criminele circuit in gaan om dan net genoeg te kunnen verdienen om van te leven ;-).
Ik denk dat het juist een 'hackers' groep kan zijn die custom code verzint. Natuurlijk is dat bij een aanval als deze nogal twijfelachtig en zal het eerder een grotere organisatie zijn, zoals bijv. een onderdeel van een overheid.
De talen die nu bekeken zijn, zijn talen die in de VS ontwikkeld zijn. Maar in andere landen zijn andere talen ontwikkeld. Глагол bijvoorbeeld is Russisch. Ik denk dat Kaspersky Lab niet naar dat soort exoten heeft gekeken. En die talen bestonden al, dus daar hoeft geen geld aan uitgegeven te zijn.
Zo kostbaar is het niet.
In mijn studie moest ik een compiler voor de PDP-11 ontwikkelen. Dat was een practicum voor een vak.
In mijn studie moest ik een compiler voor de PDP-11 ontwikkelen. Dat was een practicum voor een vak.
Het zou toch niet mogen dat software een deel van het systeem overneemt zonder dat het OS dat in de gaten heeft. Lijkt op een betere versie van een biosvirus of virus van een mbr. Werd praktisch niet opgemerkt. Maar die waren gericht op schade, die maakte geen gebruik van een netwerk.
[Reactie gewijzigd door Iblies op 8 maart 2012 19:25]
het neemt niet zomaar een deel van het systeem over, het is gewoon software dat uitgevoerd wordt op de machine net als alle andere software. het doet alleen wat anders dan je zou willen dat het doet, als je denkt een coole nieuwe screensaver geinstalleerd te hebben... (wat in windows ook gewoon een .exe is in een schilletje, en dus alles kan)
als de gebruiker die het systeem infecteerde administrator was ben je al helemaal zuur want dan kan het virus zo'n beetje alles wat het maar zou willen.
als de gebruiker die het systeem infecteerde administrator was ben je al helemaal zuur want dan kan het virus zo'n beetje alles wat het maar zou willen.
Toch wel mooi om te zien hoe die Russen het doen. Ik was eerst sceptisch (was altijd McAfee aanhanger) maar ben nu toch wel blij dat we met ons bedrijf over zijn gestapt op Kaspersky :-)
Jij bent wel heel snel over te halen. 1 nieuwsbericht dat ze ergens mee bezig zijn met een technisch staartje en hopsateee jij bent hun nieuwe consument? 
Nee we draaien het nu meer dan een jaar maar je merkt gewoon dat ze niet stil zitten. Ze blijven steeds vernieuwen en dat is met McAfee wel anders. Dat pakket is ontiegelijk zwaar en herkend haast ook niets meer (overdreven maar komt er wel op neer).
Redelijk offtopic, maar voor diegenen die geïnteresseerd zijn in de prestaties van verschillende anti-virus softwarepakketten staan hieronder wat links.
Het artikel:
http://www.pcmag.com/article2/0,2817,2372364,00.asp
Direct de vergelijking (tabel):
http://www.pcmag.com/image_popup/0,1871,iid=323802,00.asp
@mbiesheuvel
Het lijkt erop dat McAfee niet eens zó slecht presteert.
Het artikel:
http://www.pcmag.com/article2/0,2817,2372364,00.asp
Direct de vergelijking (tabel):
http://www.pcmag.com/image_popup/0,1871,iid=323802,00.asp
@mbiesheuvel
Het lijkt erop dat McAfee niet eens zó slecht presteert.
Jammer dat ze in het vrij recente verleden niet zo vernieuwend waren met hun eigen website
nieuws: Kaspersky-site verspreidt nep-virusscanner na hack
nieuws: Hacker kraakt Kaspersky-website met sql-injectie
nieuws: Kaspersky-site verspreidt nep-virusscanner na hack
nieuws: Hacker kraakt Kaspersky-website met sql-injectie
Al keer op keer is bewezen dat bij Kaspersky de pro's onder de pro's werken. Om de zero days te ontdekken waarvan het virus gebruik maakte heeft MS zelfs samengewerkt met hen. Zonder de hulp uit Rusland waren andere nooit zo ver gekomen of in ieder geval lang niet zo snel.
Is de code niet gewoon door een obfuscator gehaald toevallig? Kan me voorstellen dat het dan iets moeilijker is te achterhalen.
Ben benieuwd wat ze gaan onthullen inderdaad, wie weet zit er een overheid achter
Ben benieuwd wat ze gaan onthullen inderdaad, wie weet zit er een overheid achter
Een obfuscator kan de calling convention niet aanpassen, natuurlijk. Zie ook mijn 1e reaktie helemaal bovenaan. Een obfuscator heeft verder alleen echt nut bij de zogenaamde script talen waarbij de bron het programma zelf is. Uiteraard is er een obfuscated C contest, maar dat is opnieuw het onleesbaar maken van de broncode. De uiteindelijke gecompileerde code zal na decompileren net zo (on)leesbaar zijn als dezelfde code netjes geprogrammeerd.
Dan nog wordt het op een bepaalde manier omgezet in machinecode waarbij je bepaalde patronen kan herkennen. Compilers doen vaak heel veel om de code zo efficient mogelijk te compileren. Echter zal je met verschillende compilers zien dat ze soms hele andere manieren hebben om het op te lossen. Uiteindelijk komen ze tot het zelfde "resultaat" maar de manier waarop kan met sommige stukken code heel erg uiteen liggen.
Ik neem aan dat ze door te zoeken naar die specifieke verschillen kunnen zien dat deze code niet door een bekende compiler gecompileerd is.
Wat natuurlijk makkelijk kan is dat een al bekende compiler intern door een groepje mensen gemod is voor hun doeleinden (of omdat ze het zelf uit een vorm van perfectionisme doen, ik ken een programmeur die zelf vaak de binaries van zn programma's na gaat lopen kijken omdat ze van hem PERFECT moeten zijn. Ik neem aan dat hij niet de enige is
) Ook hij gebruikt een standaard compiler waar wat wijzigingen in gemaakt zijn zodat dat ding (in zijn ogen) betere binaries maakt.
Ik neem aan dat ze door te zoeken naar die specifieke verschillen kunnen zien dat deze code niet door een bekende compiler gecompileerd is.
Wat natuurlijk makkelijk kan is dat een al bekende compiler intern door een groepje mensen gemod is voor hun doeleinden (of omdat ze het zelf uit een vorm van perfectionisme doen, ik ken een programmeur die zelf vaak de binaries van zn programma's na gaat lopen kijken omdat ze van hem PERFECT moeten zijn. Ik neem aan dat hij niet de enige is
) Ook hij gebruikt een standaard compiler waar wat wijzigingen in gemaakt zijn zodat dat ding (in zijn ogen) betere binaries maakt.
Een obfuscated executable kan je redelijk simpel deobfuscaten, zelfs als het om een onbekende obfuscatietechniek gaat. De ontsleutelde code moet namelijk érgens in het geheugen geladen worden.
Ik vraag me af waarom er voor zou zijn gekozen het in een speciale taal te doen en niet een van de honderden bestaande programmeertalen.
Het is logisch dat de 'terug-naar-huis-bel'-functie geschreven wordt in een taal die voor ons nog onbekend is. Als jij bij een inbraak 'perse' je adres moet achterlaten ga je dat niet in een taal doen die iedereen zou kunnen achterhalen.
De betreffende module doet iets zeer specifiek dat van groot belang is voor het virus, zonder de programmeertaal te kennen kunnen ze die dan ook niet decompileren en weten wat die module exact doet. En ik denk dat het juist daarom is dat ze dit hebben gedaan: om het lastiger te maken voor onderzoekers om uit te pluizen wat er nu werkelijk gebeurt in die module.
Dit is onzin, ook al ken je een taal niet, kan je nog wel achter halen hoe een programma werkt. Ze moeten namelijk allemaal met de CPU communiceren en deze taal is wel bekent
En heb je enig idee hoeveel lastiger het is om ASM te lezen dan bv C++? Zeker als het om een taal gaat met een "highly event driven architecture". Uiteraard is het te doen, maar het kost je minstens 10 keer zoveel tijd, zo niet meer.
Misschien is dat ook wel het doel, dat het lastiger te ontcijferen is.
Het antwoord zit eigenlijk al in je vraag: waarom zijn er honderden programmeertalen.
Een domein-specifieke taal kan dingen een stuk makkelijker maken. Daarom hebben we bijvoorbeeld HTML, en niet LaTeX op het web (eigenlijk wel jammer).
Een domein-specifieke taal kan dingen een stuk makkelijker maken. Daarom hebben we bijvoorbeeld HTML, en niet LaTeX op het web (eigenlijk wel jammer).
Ja, en op HTML, XHTML, HTML5 gebruiken we vervolgens CSS, CSS2, CSS3, een bult javascript en flash om alles lekker bij elkaar te houden? Als er iets niet standaard is dan is het wel webdesign.
Pak een taal als Python, en dan zie je dat daar ook diverse varianten op zijn (Jython, b.v). Ook voor een taal als C c.q. C++ zijn er diverse versies. Met C++ heb je dan ook nog dat niet alle compilers alle (nieuwe) dingen aan kan, enz. Dit soort dingen blijf je houden tot iets helemaal af is. En zeker in de IT zal je dat niet snel tegenkomen, want dan is de lol er vanaf.
Kortom, (X)HTML, HTML5, CSS(2/3) is zeker niet vreemder dan andere (programmeer)talen.
Tenslotte, je moet er niet aan denken dat het web bij dit http://www.w3.org/History...text/WWW/MarkUp/Tags.html was blijven steken, toch?
Kortom, (X)HTML, HTML5, CSS(2/3) is zeker niet vreemder dan andere (programmeer)talen.
Tenslotte, je moet er niet aan denken dat het web bij dit http://www.w3.org/History...text/WWW/MarkUp/Tags.html was blijven steken, toch?
De standaard signature databases van virusscanners kunnen er niets mee bijvoorbeeld?
Dat heeft weinig met de taal te maken. Signature scanning is als techniek ontwikkeld in de tijd dat virussen kleine stukjes hand-coded assembly waren.
Heuristic scanners zijn een ander verhaal; die proberen de intentie van onbekende code te achterhalen. Daarbij wordt nogal eens gebruik gemaakt van bekende fragmenten code (van bestaande compilers) om de onbekende code op te breken in bekende delen, en zo een analyse op hoger nivo te kunnen doen.
Heuristic scanners zijn een ander verhaal; die proberen de intentie van onbekende code te achterhalen. Daarbij wordt nogal eens gebruik gemaakt van bekende fragmenten code (van bestaande compilers) om de onbekende code op te breken in bekende delen, en zo een analyse op hoger nivo te kunnen doen.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
