( SzBlackY | 2017. 05. 25., cs – 21:21 )

egy jó másolásvédelem eléggé komoly "tervezési hiba", akár hardveres dongle mellett, valahogy mégis sikerül megpatchelni... ;)

Na ja, csak volt, hogy több évig tartott... ;)

gondoltál már arra, hogy nem ismered részleteiben a témát?

gondoltál már arra, hogy össze-vissza beszélsz? Most éppen valahogy a vírusok/férgek kategorizálásánál tartasz, holott az egész onnan indult, hogy egyszerűbb egy (secu) bugot forráskódban javítani és újra buildelni, mint a dissasemblált binárist patchelni.

Nagyon jó bindiff algoritmusok vannak arra már sok éve, hogy akár más fordítói beállításokkal készített binárisokat is felismerjen és csak a valódi változásokat jelenítse meg, vagy elhelyezze egy olyan evolúciós fa struktúrában, amely egy nagy bináris big data adatbázisban van felépítve és mutatja az összefüggéseket és a pontos különbségeket a különböző program verziók és malware variánsok között.

És ez hogy jön ahhoz, hogy amikor van egy (biztonsági) hiba, akkor egyszerűbb fogni a forráskódot és kijavítani, mint fogni egy random lefordított binárist, és op kód szinten javítgatni?

ja hát ha valaki egy az egyben másol komplett részleteket, akkor igen...

Látom sikerült nem megnyitni a linkelt szócikket: az USA törvényei szerint a clean room újraimplementáláshoz két külön csapat csinálhat csak dissasembly-t és újraimplementálást. Egyébként az hogy nem egy az egyben részletek másolása, ha fogod a srvnet.sys-t, ráeresztesz egy dissassemblert, megpatcheled a SrvNetWskReceiveComplete() függvényt és újrafordítod?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)