Rejtélyes, új programozási nyelvben íródott a Duqu vírus

Rejtélyes, új programozási nyelvben íródott a Duqu vírus
2012-03-11T21:52:30+01:00
2012-03-20T08:35:10+01:00
2022-10-25T11:45:36+02:00
  • Azt hiszem megpróbáltam, de a kommentelő rendszere valamiért nem engedett és hagytam. Biztos megfertőzte a duqu és nem akarta hogy fény derüljön az igazságra.
    Mutasd a teljes hozzászólást!
  • Gratz!
    Igazan beirhattad volna a tippet az ottani forumba is
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Szerintem reklám.
    Mutasd a teljes hozzászólást!
  • Jo felvetes volt szerintem a COM, mert ahogy nezem, 2 calling conv is van benne hasznalva: 4 The Component Object Model

    stdcall a funkciokra
    cdecl az metodusokra

    Aztan ha pl. Delphibol hasznalsz COM-ot, ott akkor mar befigyel a default register call.conv is (eax,edx,ecx,stack). Erre kicsit az is hajaz, hogy ecx-be csinal stack eltakarito pop-okat. Ebben a call conv-ban ecx lenne az egyik szabadon elronthato temp reg es ugyanakkor az utolso param reg is.

    Aztan ha jol lattam (ha nem jol, akkor bocs :D) volt egy olyan is, hogy [this] vmt szeruseg eltolva negativ index-el. Ez szerintem nem annyira furcsa, mert az optimizalas miatt a fordito torekszik arra, hogy a (signed) eltolas beleferjen -128..127 ertektartomanyba, ekkor 3byte-al rovidebb lesz a kod.
    Mutasd a teljes hozzászólást!
  • Hmm, jogos, és akár egybe is vághat azzal, amit erdeszt linkelt, hogy COM is van a dologban. (Nem ismerem a COM-ot, lehet, hogy így nem tud működni.)

    És akkor még mindig megvan az a lehetőség, hogy a publikus/protected metódusok hívási konvenciója különbözik a privátokétól, és a privátokéban akár lehet mindig más-más regiszterben a this. (Elvben a fordító látja a privát metódus összes hívását, és akár metódusonként más-más konvenciót gyárthat, bár a gyakorlatban még nem láttam, hogy bárki ilyet csinált volna.)
    Mutasd a teljes hozzászólást!
  • Nem tudom, mi értelme lenne teljesen különböző konvenciót használni metódushívásokra és függvényhívásokra

    Pl. mert a metódusoknak akár valami publikus/bővítő interfészen keresztül is hívhatónak kell lenniük, és így valami standard (pl. cdecl) hívási konvenciót kell használniuk, amihez minden eszközzel lehet illeszkedni - míg a belső használatú függvények esetében nincs ez a követelmény, így optimálisabb, de nem szabványos konvencióval is működhetnek (pl. register).
    Mutasd a teljes hozzászólást!
  • Én nem ezt mondtam - sőt, az első hozzászólásom a témában az volt, hogy "valami register+cdecl kombó lehet".


    Igen, de aztán azt is mondtad, hogy
    Miért, te hol látsz a mutatott kódrészletekben olyant, ahol hol vermet, hol regisztert használ a paraméterek átadásához? Én csak vermes paraméterátadásokat látok, méghozzá cdecl konvencióval (ti. a hívó takarítja el a vermet).

    úgyhogy szerintem itt kezdtünk elbeszélni egymás mellett.

    Amit valóban vitattam az az az állítás volt, hogy "Duqu Framework classes can receive 'this' parameter in any register or in stack"

    Ezt lehet, hogy jobban ki kellett volna emelned, mert nekem nem jött le.

    Nem tölti be, hanem továbbnyomja a stackre ill. ott hagyja a valójában vele azonos, a this-t a stacken fogadó class2_free hívásnak.

    (javítva, elnéztem a vermet) Elég furcsa megoldás lenne, hogy a class_2.clear a kapott paramétert kapja this-ként a veremben, a két class2_free meg azt, ami a hívónak épp az ESI-ben volt hívás előtt. Nem tűnik konzisztensnek se az, hogy két különböző dolgot takarít, se az, hogy kétféleképpen kapja meg a takarítandó objektumot.
    Ha nem, akkor pedig a class2_free valójában nem metódus, hanem tök sima procedurális függvény.

    Szerintem se kap this paramétert, csak az EAX-ben a felszabadítandó memóriacímet. Hogy ezt függvénynek vagy static metódusnak nevezzük, az ezen a szinten már tökmindegy.

    Nem, nagyon nem mindegy, mert pl. míg sok nyelvben a konstruktor jellemzőn osztálymetódusként kerül meghívásra (hiszen még nincs objektum amin dolgozzon, nincs memória se foglalva neki, hanem maga a konsruktor foglalja le a memóriát az éppen példányosított objektumnak), addig a destruktor már teljesen sima metódusként (hiszen már egy létező objektumpéldányt semmisít meg).

    Én úgy mondanám, hogy a konstruktor nem kap this paramétert, a destruktor meg igen, de ezen kívül nincs sok különbség köztük. Hívási konvencióban ez általában annyi különbséget jelent, hogy vagy kap a this egy dedikált regisztert, vagy teljesen úgy adódik át, mint egy függvény első paramétere. Nem tudom, mi értelme lenne teljesen különböző konvenciót használni metódushívásokra és függvényhívásokra, de persze attól még lehet, hogy tényleg így tervezték.

    Viszont ha már itt tartunk, megint csak azt tudom mondani, hogy ezen a szinten már nincs sok különbség függvény és metódus között. Mert végül is az érvelésed oda lyukadt ki, hogy az egyik hívási konvencióval hívott dolgot nevezzük el önkényesen függvénynek (aminek az egyik paramétere objektum-mutató), a másikat metódusnak. Senki nem tudja bizonyítani, hogy a hívási konvenció különbsége tényleg azért van, mert az egyiket függvényként írták a forrásban, a másikat metódusként. Én inkább a használata szerint definiálnám, hogy melyik a this paraméter (pl. a te utolsó két példádban explicit van kiírva a this paraméter, de attól még ugyanaz a szerepe), és akkor meg igaz lesz, hogy a this-t regiszterben és stack-en is kaphatja egy metódus.
    Mutasd a teljes hozzászólást!
  • szerk: szerintem nem kellene belekeverni, hogy mi a metódus, a globális függvény meg a static függvény. Ezen a szinten már inkább csak függvények vannak, amik közül néhány kap "this" paramétert, meg néhányat VMT-n keresztül hívnak.

    Nem, nagyon nem mindegy, mert pl. míg sok nyelvben a konstruktor jellemzőn osztálymetódusként kerül meghívásra (hiszen még nincs objektum amin dolgozzon, nincs memória se foglalva neki, hanem maga a konsruktor foglalja le a memóriát az éppen példányosított objektumnak), addig a destruktor már teljesen sima metódusként (hiszen már egy létező objektumpéldányt semmisít meg). Az osztálymetódusoknak és a mezei metódusoknak pedig eltérnek a hívási konvenciói, ill. az, hogy a paramétereik hol kerülnek elhelyezésre vagy hogy el kell -e menteni a mondjuk az önreferenciának fenntartott regisztert vagy sem, mert az osztálymetódusokban ugye nincs "this" referencia, és nem őrzendő meg.

    A valóság az, hogy bár nagy ravaszan a visszafejtők elnevezték class2_ctor-nak, class2_dtor-nak, class2_free-nek a metódusokat, de egyáltalán nem biztos, hogy ezek valóban mind ugyanannak az egy osztálynak a metódusai ill. hogy egyáltalán metódusok mind a felhasznált fejlesztőeszköz szintjén. Pl. class2_ctor simán lehet akár egy mezei függvény is, csak úgy mint class2_free is. Sőt, a class2_XXX metódusok közül is tetszőleges lehet osztálymetódus, míg mások mezei metódusok lesznek - amit viszont nem tudunk megállapítani, mert hogy kulcsfontosságú kódrészletek (pl. class2_free törzse) nem ismertek. Amely eltérések ugyanakkor megmagyarazhatnának eltéréseket a paraméterek átadásának módjában, anélkül is, hogy ehhez az ugyanolyan típusú rutinok hívási konvenciói között eltérés lenne.

    Ha nem lenne érthető, hogy miről beszélek, akkor gondolj bele, hogy a visszafejtésben class2_count-nak hívott rutin deklarációja és hívása így is kinézhet a nyelv szintjén:

    function Class2.Count: integer .. if (Class2Instance.Count>0) then ...

    meg így is

    class function Class2.Count(Instance: Object): integer; .. if (Class2::Count(Class2Instance)>0) then ...

    és így is

    function class2_count(objref: pointer): integer .. if (class2_count(Class2Instance)>0) then ...

    amely esetekben bár valójában ugyanazokat a paramétereket kapja meg és adja vissza a rutin, de nyilvánvalóan akár teljesen eltérő is lehet a hívás és a rutin mögé generált kód, beleértve a paraméterek átadásának módját is.
    Mutasd a teljes hozzászólást!
  • 1. Azt az ESI-t a hívó állította be, vagyis regiszteres paraméterátadás történt, ami véleményed szerint nem szerepel a kódban.

    Én nem ezt mondtam - sőt, az első hozzászólásom a témában az volt, hogy "valami register+cdecl kombó lehet". Amit valóban vitattam az az az állítás volt, hogy "Duqu Framework classes can receive 'this' parameter in any register or in stack", azaz, hogy bizonyos metódusok más hívási konvenciót használnának, mint a többi. Ami viszont hülyeség, mert mint az előbb megmutattam, vagy az a helyzet, hogy bizonyos class2_XXX-nek elnevezett rutinok valójában nem osztálymetódusok (és így nem is kapnak this-t, legalábbis nem this-ként, hanem max. memóriapointerként), vagy az nem igaz, hogy eltérő lenne a hívási konvenció.

    2. Az ESI-be mégis betölti később a stackről az első paraméterét, aminek ugye nincs sok értelme, ha az ESI értéke már amúgy is a kívánt volt

    Nem tölti be, hanem továbbnyomja a stackre ill. ott hagyja a valójában vele azonos, a this-t a stacken fogadó class2_free hívásnak. Ha nem, akkor pedig a class2_free valójában nem metódus, hanem tök sima procedurális függvény, ami az objektumreferenciát mezei paraméterként, és nem this-ként kapja meg.
    Mutasd a teljes hozzászólást!
  • Ha ez így lenne, akkor semmi értelme nem lenne a class2_ctor-ban látható "call class2_dtor" körüli "push esi"-"pop ecx" párosnak, hiszen teljesen redundáns művelet lenne.


    Biztosan félreértjük valahol egymást. A class2_dtor szerintem is stacken kapja a paraméterét, mert mezei cdecl konvenciót követ. Így persze az említett utasítások nem redundánsak, hanem a cdecl hívás paraméterátadását és takarítását alkotják. Más szóval: nem elmenti az esi-t, hanem átadja.

    A válasz természetesen az,hogy ennek csak akkor van értelme, ha az esi paraméterként került átadásra a stacken a class2_dtor-nak, ill. hogy a class2_dtor-on belül is paraméterként kerül felhasználásra a class_free hívásokban.


    Akkor ezt most gondoljuk át. Ha a class2_dtor legelső "push esi" utasítása a this-t rakja le paraméterként, az két dolgot jelent:
    1. Azt az ESI-t a hívó állította be, vagyis regiszteres paraméterátadás történt, ami véleményed szerint nem szerepel a kódban.
    2. Az ESI-be mégis betölti később a stackről az első paraméterét, aminek ugye nincs sok értelme, ha az ESI értéke már amúgy is a kívánt volt

    De még egyszer mondom, ha lennél szíves te is annotálni a kódot, ahogy én csináltam, akkor egyből világosabb lenne, hogy mire gondolsz. Így nagyon nehéz követni, hogy miről van szó, és lehet, hogy csak elbeszélünk egymás mellett.

    szerk: szerintem nem kellene belekeverni, hogy mi a metódus, a globális függvény meg a static függvény. Ezen a szinten már inkább csak függvények vannak, amik közül néhány kap "this" paramétert, meg néhányat VMT-n keresztül hívnak. Könnyebb úgy megfogni, hogy más hívási konvenciókról beszélünk. Szerintem szám szerint három van: a default a cdecl, a class2_free valamiért regisztereset használ, a WinAPI meg a szokásos stdcall-ját használja.
    Mutasd a teljes hozzászólást!
  • (A hívási konvenció szerint az esi-t nem szabad elrontani, ezért le kell menteni az elején az értékét.

    Ha ez így lenne, akkor semmi értelme nem lenne a class2_ctor-ban látható "call class2_dtor" körüli "push esi"-"pop ecx" párosnak, hiszen teljesen redundáns művelet lenne. A hívó a hívás előtt miért mentené le az esi-t ha a hívott class2_dtor is egyrészt definíció szerint nem ronthatja el, másrészt amúgy is mindjárt lementi, majd közvetlenül kilépés előtt visszaállítja?

    A válasz természetesen az,hogy ennek csak akkor van értelme, ha az esi paraméterként került átadásra a stacken a class2_dtor-nak, ill. hogy a class2_dtor-on belül is paraméterként kerül felhasználásra a class2_free hívásokban.

    A másik lehetőség, hogy a class2_free-nek valójában köze nincs a class2-höz, hanem csak egy teljesen sima procedurális függvény - és csak "átverés" az hogy ugyanúgy class2_XXX-nek van hívva*, mint a nyilvánvalóan valóban osztálymetódust képező class2_dtor. Ekkor viszont megint nincs keveredés, hiszen nyilván egy osztálymetódus hívási, paraméterátadási és regisztermegőrzési konvenciói mások lesznek, mint egy sima függvényé.

    *az már csak hab a tortán, hogy közben ráadásul pedig a simán "free"-nek hívott metódus, ami viszont szintén egyértelműen vár a stacken egy esi/this paramétert (mert egyébként megint csak nem lenne értelme a körülötte lévő push-pop párosnak), viszont nincs class2-vel prefixálva, ami azt sugallja, hogy procedurális függvény, miközben nagyon nem annak, hanem sokkal inkább osztálymetódusnak tűnik előbbiek miatt.
    Mutasd a teljes hozzászólást!
  • Az oké, hogy a végén van egy pop esi a második (első) push esi-hez is, de ez nem változtat azon, hogy amikor a második class2_free meghívásra kerül, akkor a vermen az első paraméter a mindjárt az elején push-olt esi értéke, azaz egy "this" objektum-referencia lesz.


    Az elsőnek push-olt esi az nem egy "this" referencia, hanem egy, a hívott által nem ismert érték. (A hívási konvenció szerint az esi-t nem szabad elrontani, ezért le kell menteni az elején az értékét. Hogy mi van benne, az a hívó dolga. Ha az esi-t el lehetne rontani a konvenció szerint, akkor az idézett kódnak minden hívás után vissza kéne állítgatnia, ami nyilvánvalóan nem történik meg.) Ha viszont az első push-olt esi nem a "this"-t tartalmazza, akkor borul az elméleted, hogy a paraméterátadás része lenne. (Nyugodtan javíts ki, ha tévednék.)

    De tudod mit, ez így kezd kicsit követhetetlenné válni. Inkább ideírom, hogy szerintem melyik sor mit csinál, te pedig hasonló módon kérlek írd le, hogy szerinted mit csinál, és akkor könnyebb lesz követni egymás érvelését.

    push esi # hívó ESI-jének mentése mov esi, [esp+4+lpMem] # első paraméter töltése stack-ről ESI-be push esi # this átadása stack-en a köv. híváshoz call [esi+class_2.clear] # cdecl hívás mov eax, ds:(_class_2.allocated_block_1 - _class_2.setup_class13)[esi] # class2_free paraméter készítése az EAX-be # (azért ilyen bonyolult a képlet, mert az ESI nem az objektum elejére mutat) pop ecx # takarítás az előző (cdecl) hívás után call class2_free # regiszteres hívás, se előtte, se utána nincs takarítás mov eax, ds:(_class_2.allocated_block_2 - _class_2.setup_class13)[esi] # class2_free paraméter készítése az EAX-be call class2_free # második regiszteres hívás lea eax, (_class_2.csec.DebugInfo - _class_2.setup_class13)[esi] # critical section handle címének kiszámolása az EAX-be push eax # paraméter átadása stdcall híváshoz call ds:__imp__InitializeCriticalSection@4 # WinAPI hívás stdcall konvencióval # (stdcall után nincs takarítás) push esi # paraméter átadása stack-en a köv. híváshoz call free # cdecl hívás pop ecx # takarítás cdecl hívás után pop esi # a hívó ESI-jének visszatöltése retn

    Szerk: főleg arra lennék kíváncsi, szerinted mire szolgál az első két "mov eax, " kezdetű sor. Szerintem paraméterátadásra szolgálnak, de ha az elméleted igaz és minden stack-en megy, akkor ezek felesleges utasítások, ahol ráadásul a második felülcsapja az első értékét.
    Mutasd a teljes hozzászólást!
  • Amit te írsz, a két class_free hívással, ott szerintem félreértetted a kódot. A legelső "push esi" egy regisztermentés, amit a kód legvégén levő "pop esi" szépen vissza is állít. Így tehát nem vesz részt paraméterátadásban.

    Az oké, hogy a végén van egy pop esi a második (első) push esi-hez is, de ez nem változtat azon, hogy amikor a második class2_free meghívásra kerül, akkor a vermen az első érték a mindjárt class_dtor elején push-olt esi, azaz egy "this" objektum-referencia lesz. Ezt pedig (ti. a vermen lévő első értéket) a class2_free egyértelműen paraméterként használja, mert csak ezzel magyarázható az első class2_free előtti push esi, majd aztán utána a "dummy" pop ecx, ami gyakorlatilag csak a verem eltakarítását szolgálja (lásd C-konvenció), mivel az ecx később sehol nem kerül felhasználásra. Tehát ennek a push-pop párosnak a célja nem az esi értékének mentése, hanem egy paraméter lenyomása a stackre, majd annak eltakarítása onnan.

    Ráadásul a call class2_dtor előtt is van egy push esi (ami aztán viszont szintén egy dummy pop ecx-szel kerül visszaállításra), ezért logikus feltételezni, hogy a nyilván ugyanúgy "statikus" osztálymetódus-hívást képező call class2_free is vermen várja az objektum-referenciát - és ez ugye pont a fent említett módon valósul meg, és azon keresztül, hogy a class_dtor elején két push esi is van majdnem egymás után.

    Tehát a második (végrehajtási sorrendben első) "push esi" is igenis résztvesz a paraméterátadásban (is), illetve, elmondható, hogy minden metódushívás esetén a "this" referencia a vermen utazik, első paraméterként. Szóval ahogy én látom, itt semmi keveredés nincs, és minden metódus (statikus és/vagy osztálymetódus, ill. a VMT-ből, metódustáblázatból vettek is) ugyanazzal a hívási konvencióval kerül meghívásra. Ami viszont egyben ezt is jelenti, hogy hülyeség amit a gyerek írt a blogposztban, hogy ti. a "this" paraméter hol stacken, hol regiszterben utazik.

    QED
    Mutasd a teljes hozzászólást!
  • Simán előfordulhat, hogy állami hivatal van a dologban; az idevágó Wikipedia-cikk szerint a Duqu nem általános kártevő, hanem direkt az ipari vezérlési rendszerekből információt gyűjtő eszköz. Gondolom amíg sikerül titokban tartani a készítőket megbízó országot, lehet a segítségével szabotálni ellenséges országokat anélkül, hogy válaszcsapástól kellene tartani.

    Ijesztő belegondolni, hogy húsz éve még csak sci-fi könyvekben volt olyan, hogy kiberhadviselés, ma meg már valóság...
    Mutasd a teljes hozzászólást!
  • Upsz, my bad. Felületesen olvastam...
    Mutasd a teljes hozzászólást!
  • Csatlakozom. Nem szántam rá időt, de feltételezem, hogy valóban van itt valami "rejtély". (Ha nem, akkor egyszerűen egy média heck.)

    A kérdés az, miért nem "standard" a tárgykód?
    Vagy komoly optimalizálás (assembly szinten) egy alapvetően OO nyelv kódjára, vagy valóban valami új "nyelv".

    Talán a hívási konvenció ismétlődését kellene figyelni, ha az szabályszerű, akkor valószínűleg a fordító gyártja, ha nem, akkor inkább kézi munka.
    [mindenesetre regiszter+stack paraméter átadás és van ahol az egyetlen paraméter stack-en? Nem tünik jól optimalizált kézi beavatkozásnak.]

    Ha egy új vagy hackelt fordító, akkor komolyabb szervezet van (valószínűsíthető) a víruskód mögött. És ez a fontos kérdés!
    Valamilyen titkosszolgálat vagy állami hivatal, nagyvállalat gyárt víruskódot?
    Mutasd a teljes hozzászólást!
  • Azt előrebocsátanám, hogy én feltételeztem, hogy az eredeti cikkíró érti a dolgát, ezért ha azt mondja, hogy van regiszteres paraméterátadás, akkor tényleg van. Mielőtt ezt a hozzászólást megírtam, nem néztem át alaposabban az idézett ASM részleteket.

    Amit te írsz, a két class_free hívással, ott szerintem félreértetted a kódot. A legelső "push esi" egy regisztermentés, amit a kód legvégén levő "pop esi" szépen vissza is állít. Így tehát nem vesz részt paraméterátadásban. Az első és az utolsó utasítást kivéve az esi végig a (stacken) paraméterként kapott értéket tartalmazza, ami eléggé úgy néz ki, mint egy "this", de valami okból az objektum belsejébe mutat, nem pedig az elejére.

    Ezeket figyelembe véve a "call [esi+class_2.clear]" és a "call free" sorok valószínűleg cdecl konvenciójú függvényeket hívnak, a "call class2_free" előtt az eax-be töltődik a felszabadítandó terület címe, tehát ez regiszteres parméterátadás, a "call ds:__imp__InitializeCriticalSection@4" pedig a windowsos stdcall konvenciót használja, ahogy te is mondod.

    De ha van alternatív kódértelmezésed, szeretném hallani, mert én is elnézhettem a dolgot
    Mutasd a teljes hozzászólást!
  • Miért, te hol látsz a mutatott kódrészletekben olyant, ahol hol vermet, hol regisztert használ a paraméterek átadásához? Én csak vermes paraméterátadásokat látok, méghozzá cdecl konvencióval (ti. a hívó takarítja el a vermet). Egyetlen kivétel az InitializeCriticalSection hívás, ami viszont WinAPI, és mint ilyen Pascal konvenciót használ (ott is a veremben megy a paraméter, de a hívott takarítja ki, amit nyilván nem látunk).

    Egy trükkös szitu van még a két egymás után class2_free hívás, de annál meg korábban két "push esi" van és csak egy "pop" köztük - szóval az is teljesen rendben lévőnek tűnik, csak úgy látszik kicsit át vannak rendezve az utasítások, nyilván a pipeline optimalizáció miatt. Gondolom ugyanezért van sok helyen egy mov a call utána és csak utána a veremtakarítás pop-pal.

    Szóval tudom, hogy a szövegben azt írják, de a képeken látható kódokon én nem látok sokfajta hívást, csak egyfajtát (mármint az objektumon belül, mert nyilván ott van még a WinAPI hívás ami más).
    Mutasd a teljes hozzászólást!
  • Most az a beszélgetés célja, hogy megmutassuk, melyikünk tud többet a hívási konvenciókról, vagy lehetne koncentrálni az eredeti témára? Igen, ha nem fér el a paraméter, akkor nem megy regiszterben, de a példában a this-ről volt szó. A this mutató. A mutatók elférnek az általános célú regiszterekben.

    Tudsz mutatni olyan hívási konvenciót, ami bizonyos esetekben használ regisztereket, de ha egyetlen, mutató paramétert kell átadnia, azt mégis a stacken csinálja?
    Mutasd a teljes hozzászólást!
  • @Sting: ha egy paraméter van, az előre is, meg fordított sorrendben is pont ugyanaz. És ha egyébként regisztereket használ a hívási konvenció, elég fura, ha pont ebben az esetben meg nem használja őket...

    Márpedig register konvenció esetén is van ilyen, ha pl. az átadandó paraméter nem fél el egy regiszterben (mert hosszabb). Akkor stackre nyomja, teljesen függetlenül attól, hogy hányadik paraméter és hogy van még esetleg "üres" regiszter neki.
    Mutasd a teljes hozzászólást!
  • Szelektív idézés rulez. Eredetileg ezt írtam:

    Márpedig én nem tudok olyan hívási konvencióról, ami regiszterben ad át paramétereket, de ha csak egyetlen paraméter van, azt mégis stacken adja.

    Mert hogy ami hívási konvenció regisztereket használ, az általában az első pár paramétert rakja regiszterbe, nem találomra választ.

    @Sting: ha egy paraméter van, az előre is, meg fordított sorrendben is pont ugyanaz. És ha egyébként regisztereket használ a hívási konvenció, elég fura, ha pont ebben az esetben meg nem használja őket...
    Mutasd a teljes hozzászólást!
  • Az oldal generálása közben hiba történt. proghu@prog.hu
  • Rejtélyes, új programozási nyelvben íródott a Duqu vírus


    Vagy nem: A DuQu Keretrendszer rejtélye
    Mutasd a teljes hozzászólást!
  • Az eredeti cikket olvasva nekem is az volt a tippem, hogy ki tudja, milyen okból, valami OO nyelvre emlékeztető formátumban, de assembly-ben írt kódról van szó.

    Mutasd a teljes hozzászólást!
  • Ennek ellentmondani látszik, hogy a metódusok a "this"-t néha regiszterben, néha stacken kapják; egy C fordító szerintem ezt konzisztensen csinálná, már feltéve, hogy a programozó konzisztensen mindig az első paraméternek vette fel a "this"-t.

    Kivéve ha fordított sorrendben nyomja be a paramétereket a regiszterekbe ill. a verembe, mert ilyenkor a paraméterek számától függően változik, hogy az objektum önreferenciája melyik regiszterbe, vagy stackre kerül -e. Valami register+cdecl kombó lehet.
    Mutasd a teljes hozzászólást!
  • Én inkább azt vizsgálnám, hogy az elrabolt programozó team, rejtett-e el titkos üzi kódot az új prognyelvben. Ki kell őket szabadítanunk.
    Mutasd a teljes hozzászólást!
  • "...Márpedig én nem tudok olyan hívási konvencióról, ami regiszterben ad át paramétereket..."

    Delphi : x86 calling conventions - Wikipedia, the free encyclopedia
    Mutasd a teljes hozzászólást!
  • Én személy szerint arra tippelnék, hogy objektum-orientált stílusú C-ben íródott.


    Ennek ellentmondani látszik, hogy a metódusok a "this"-t néha regiszterben, néha stacken kapják; egy C fordító szerintem ezt konzisztensen csinálná, már feltéve, hogy a programozó konzisztensen mindig az első paraméternek vette fel a "this"-t. Ráadásul a kiemelt példában pont egy olyan metódust mutatnak, aminek a "this"-en kívül nincs paramétere, a "this"-t mégis a stacken kapja. Márpedig én nem tudok olyan hívási konvencióról, ami regiszterben ad át paramétereket, de ha csak egyetlen paraméter van, azt mégis stacken adja.

    Persze nem lehet ennyi alapján kizárni egy szokatlan C fordító használatát, de ilyen erővel azt sem, hogy közvetlenül assemblyben írták a kódot.
    Mutasd a teljes hozzászólást!
  • Őszintén szólva én meglehetősen szkeptikus vagyok, és fölöslegesnek tartom a hype-ot. Ugyan mi a bánatért implementálnának egy teljesen új nyelvet? Mert az menő? Azért egy OO magaszintű compiler megírása nem kis feladat, főleg hogy még azt is akarod, hogy kicsi és gyors kódot fordítson a malware-ednek.

    Én személy szerint arra tippelnék, hogy objektum-orientált stílusú C-ben íródott. Az generál ilyen kódot, amikor kézzel inicilizálgatják a vtable-t. Nem is értem hogy nem gondoltak erre, legalább eshetőségként felmerülhetett volna. Legalábbis valószínűbb, mint a "rejtélyes, új nyelv".
    Mutasd a teljes hozzászólást!
  • most komolyan meglepődtek azon hogy egy új programnyelv keletkezett? - ami mondjuk még nem is biztos.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd