- těch 14 dnů jste si vymyslel
- i kdyby to trvalo 14 dnů, tak hrozba bude trvat déle a má smysl se před ní chránit
- varianty je možné odhalit heuristickou analýzou
Je samozřejmě otázka, jestli je AV nezbytný pro každého. Ale pro spoustu lidí, kteří se orientují v IT jako vy v zemědělské technice vyráběné ve Finsku, to význam má.
Ne soudruhu, to sem si nevymyslel, osobne sem nekolikrat soudruhum z avastu i esetu reportoval a posilal vzorky, driv nez za 14 dnu to nezvladli nikdy.
Za 14 dnu se bude sirit uz neco uplne jinyho ... a to nemluvim o tom, ze realne davno zadny viry neexistujou. Jedinej virus je picus u klavesnice. Kde sou casy onehalfa .... to stacilo strcit disketu do mechaniky.
S tím se nedá souhlasit. Samozřejmě, kdo nic nedělá, nic neposere.
Ale kromě opravdu vykoledovaných nákaz (otevírání příloh, lezení na zabreberené weby, ...), objevily se hrozby, které vyžadovaly jen minimální interakci uživatele.
Dále patrně vycházíte i z toho, že od dob XP chrání Vaše data servery. Mailservery mají antiviry a detekce malwaru, fileservery se často chrání, ... Kdyby toto všichni zase zrušili, možná byste se divil, kolik hrozeb by zase bylo.
Nejsem také ale ani zastánce paranoidně nastavených antivirů, které dovedou zabít veškerý výkon PC, nebo člověka uotravovat dialogy.
Nejsem insider, ale nebyl to puvodne nejaky univerzitni projekt, kde cilem bylo vic targetu? ....
Cílem projektu je vytvořit kompaktní systém pro podporu platformě nezávislé analýzy potenciálně škodlivého kódu. Tento systém bude schopen pracovat s binárním spustitelným kódem bez ohledu na jeho formát či platformu, pro kterou byl kód vytvořen
Pociatocna sprava vyzerala super a po precitani informacneho textu na ich webe to vyzeralo az bombasticky. Po jemnom otestovani to ale teda nieje nic moc. Nepodporuje x64, nenormalne je to nenazrane na pamet. V zasade hocijake trochu komplikovanejsie exe a 10-18GB RAM je hned dolu a je to dost pomale. Ked to porovnam s IDA, tak fakt neviem preco to pouzivat. Mozno jedine preto ze je ten dekompiler zdarma.
Co prosím?
64bitové mainstream (x86) CPU tu máme od roku 2003 (podpora v OS od roku 2001). Neexistuje žádný racionální důvod, proč používat 32bitové aplikace (ve všech ohledech jsou horší.. jediná výhoda je velikost pointeru 4B vs 8B, ale od toho tu je x64_32 ABI). Jejich stálé hojné rozšíření je čistě vinou lenosti a neschopnosti vývojářů pro Windows.
Pokud jde někomu o cenu a udržitelnost, má investovat do FOSS. Tam se nemůže stát, že člověk zůstane s archaickým a neudržovaným SW bez možnosti s tím cokoliv udělat.
Přitom přechod 32b->64b je ve většině případů pouze otázka rekompilace a maximálně nějakých drobných úprav platformně závislých částí kódu.
Pokud mám tedy v rukou zdroják, je přechod levná záležitost. Chápu ale, že pokud po mě chce dodavatel za každý update nekřesťanské peníze, tak si to dvakrát rozmyslím.
Po dodavateli zase chtějí peníze jeho zaměstnanci a zákazníci vyžadují support. Nemusíme chodit ani do "vod" emoce budícího Internet Exploreru, který se kvůli doplňkům a kompatibilitě zastavil na 32 bitech (x64 verzi skoro nikdo nepoužíval, už jen kvůli flashi, který zase Adobe (zaplať pánbu!) zmrazila). Ale můžete se podívat např. na to, jak dlouho Adobe musí držet 32bitové verze svých produktů (PS, IL), a zase kvůli doplňkům třetích stran.
Ten řetězec ekonomické závislosti prostě je, a je dlouhý a rozvětvený.
A pak si vezměte, že pro většinu lidí přechod na 64bit nic nepřinesl (ničeho si nevšimli), ale určitě by si všimnuli, kdyby něco nefungovalo.
Já s Vámi jinak souhlasím, jen vysvětluji, proč to ve skutečnosti nefunguje.
Toto je +- to, co jsem myslel leností a neschopností vývojářů.. :) Každopádně jsem rád, že takové věci nemusím už dlouho řešit.
Jinak hlavní přínos je vyšší výkon (více registrů, rychlé syscally). Ono se vyplatí SW každý rok rekompilovat i když nikdo změnu v kódu neudělá - kompilátory se vyvíjejí a jsou v optimalizacích lepší a lepší.
No, predstav si, ze 32bity se prodavaly jeste pred nekolika lety a predstav si, ze nekteri lide je koupili, protoze byly levnejsi a jim to stacilo a stale staci. A v nekterych kategoriich jine, nez 32bitove CPU vubec nebyly, treba netbooky s 64bitovym Atomem se objevily mozna tak pred peti lety, pricemz vetsina jich stale byla 32 bitova. Takze kvuli tobe ted honem vsichni vybehnou do obchodu a nakoupi novy HW, kdyz stary stale slouzi? Nehlede na to, ze konkretne v kategorii netbooku na trhu neni snad jediny, ktery bych chtel aspon zadara. Klavesnice jsou katastrofalni, leskle displaye, misto disku 32 GB eMMC, mechanicke provedeni casto zoufale.... Ostatne v kategorii dospelych stroju neni vyber o moc lepsi. Secure boot, UEFI (implementace casto na par facek), zrcadlo misto displaye, chiclety, HD LED pryc, konektivita rok od roku horsi....
Nemáš pravdu - pouze úplně první generace Atomů (a to jen nejnižší jednojádra) nepodporovala x86_64.. A to bylo před 9 lety. Pozdější Atomy podporovaly x86_64 bez výjimky.
Taky si troufnu tvrdit, že ty první Atomy dnes opravdu nikdo nepoužívá (nebyly použitelné ani v době svého uvedení - možná tak na nějaké IoT) a pokud ano, tak takoví lidé svůj SW stejně neaktualizují, takže není problém.
Zároveň také není můj problém, že Intel byl minulou dekádu se svými CPU těžce pozadu a lídrem bylo AMD. Každopádně stále existují distribuce s i386 podporou, případně si uživatel prvních Atomů může požadovaný systém pro i386 zkompilovat sám ;)
Nemáš pravdu - pouze úplně první generace Atomů (a to jen nejnižší jednojádra) nepodporovala x86_64.. A to bylo před 9 lety. Pozdější Atomy podporovaly x86_64 bez výjimky.
Kecas jak Palacky. Mam N270, dvojjadro a umi jen 32 bitu.
Taky si troufnu tvrdit, že ty první Atomy dnes opravdu nikdo nepoužívá (nebyly použitelné ani v době svého uvedení - možná tak na nějaké IoT) a pokud ano, tak takoví lidé svůj SW stejně neaktualizují, takže není problém.
Ja mam dva a nejsem tu sam. S vhodnym SW jede velice slusne, zejmena ted, kdyz jsem z nej sundal to #@¹&§ Ubuntu a nahodil MX Linux a strcil pod nej SSD.
N270 je jednojádro první generace z roku 2008.. Doporučuji ověřovat, když paměť už tak neslouží ;)
N270 je jednojádro první generace z roku 2008..
Dobre, tak kecam ja, on se jen tak tvari kvuli HT.
Nicmene situace neni takova, jak by se podle tebe zdalo, tedy ze po roce 2003 32bity uplne a okamzite vymrely. Napriklad vselijake Intel Core tu s nami jeste nejakou dobu byly a stale jedou a nevim, proc by s nimi lidi honem meli bezet do popelnice.
Všechny procesory architektury Intel Core jsou 64bitové.. Tj. od roku 2006 jsou všechny stroje 64bitové (s výjimkou prvních Atomů, ale na ty vývojáři opravdu brát ohled nemusí - to je jako kdyby chtěl někdo dnes podporovat Pentium IV)..
Ono dokonce i to Pentium IV má od roku 2005 64bit podporu (Prescott 2M) a v čipu jako takovém je od roku 2004 a Prescott.
Jinými slovy.. 32bitové x86 CPU jsou asi taková rarita jako používání IE 6.0.. Možná to někdo má někde ve sklepě, ale vážně pochybuju, že to používá. Nebo ty snad právě teď píšeš z toho úžasného Aromu N270? ;)
Všechny procesory architektury Intel Core jsou 64bitové.. Tj. od roku 2006 jsou všechny stroje 64bitové (s výjimkou prvních Atomů, ale na ty vývojáři opravdu brát ohled nemusí
To se doctu kde? Wikipedia uvadi Core jako 32 bitu. A nejake Core Duo nebo co tu bezi nekde v prizemi a pokud vim, ma 32 bitu. A zrovna Core Duo cpali do kdejakeho stroje.
Jinými slovy.. 32bitové x86 CPU jsou asi taková rarita jako používání IE 6.0.. Možná to někdo má někde ve sklepě, ale vážně pochybuju, že to používá. Nebo ty snad právě teď píšeš z toho úžasného Aromu N270? ;)
To asi tezko, kdyz ve svete porad bezi miliony Widli XP.
A ano, pisi ze sveho uzasneho Atomu. Umi vse, co potrebuju a takovy stroj uz dnes nekoupim. Na trhu neni jedina masina s 10" matnym displayem, normalnim HD a poradnou klavesnici. Clovek by se poblil, kdyz kouka na to, co dnes prodavaji.
Najdete to nejlépe zde: https://ark.intel.com/
Starší Core Duo byly jen 32bitové, Core 2 Duo už myslím ne, ale ruku bych do ohně nedal.
N270 je jednojádro první generace z roku 2008..
Podle mě první generace byly Atomy Z Silverthorne (32 bit) z dubna 2008. Atomy N jsou Diamondville (2. generace) z června 2008 a jako jediné z této generace jsou 32 bit, ostatní Diamondville jsou 64 bit (osobně bych se nedivil, kdyby to pro ty N bylo nastaveno jen microkódem). Všechny ostatní Atomy jsou 64 bit. Koneckonců to máte i v tom prvním odkaze.
Ked som sa v ramci OSS vikendu nedavno zucastnil workshopu o reverse engineeringu malware (slo o zakladniacky workshop, ale chcel som vediet, ci je niekto, kto NEpouziva IDU) tak mi typek tvrdil, ze valna vacsina Widlieho malware, ktoru analyzoval bola 32bitova.
Ono by to na widliach aj davalo zmysel. Payload moze byt mensi a kazde 64bitove widle si so sebou tahaju multilib.
takze mi staci napisat 64bit malware a targetnut ho na windows servery ktore budu s vysokou pravdepodobnostou 64bit a povedzme sifrovat disky ako ransomware a som v suchu. Nikto mi ten malwer nezachyti, lebo sak vecsinou je vsetko 32bit.
Co sa tyka payloadu tak v densnej zmagorenej skriptovacej dobe je toto najmensi problem. Ked firmy nemaju, respektive maju problem si vsimnut ze im niekto taha GB internych dat zo serveru tak ci bude mat pyaload malwaru 500kb alebo 2MB je fakt jedno. Dnes to aj tak nikto nebude buchat v asm alebo cistom c ale skor to bude nejaka skriptovacia zlatanina ktora si bude tahat zo sebou este aj interpreter.
Reverse engineering v praci pouzivam, tak mne projekt velmi zaujal.
Je videt snaha prevest kod do citelneho C/Python- zdrojaku, bohuzel ale vysledek neodpovida vstupu, casto je C-kod nesmyslny. Nemusi byt pouzity ani zadne obfuskacni techniky na to, aby vysledek byl jeste mene citelny nez assembler (a hlavne nefunkcni).
Nesmyslne mi prijde se snazit analyzovat vyznam dlouheho kodu (z nekolika C funkci mi vznikl jeden velky reversnuty C blob ktery byl naprosto necitelny). Naopak, kdyz se funkce omylem rozdeli do vice, neni to na skodu.
Dale je podle meho nazoru blbost zakryvat puvodni kod, lepsi by mi prislo kdyby to jen oznacilo promenne na stacku + registry a s temi normalne pracovalo ve stylu for (eax=0;eax<10 && intvar55/*esp+55*/ !=0 ; eax++) { ... } a k tomu to klidne michalo inline assembler kdyz neco nejde snadno prelozit.
Tak ono hlavne je dolezite co ma byt vlastne cielom takehoto programu/analyzeru. Vygenerovanie nejakeho funkcneho a skompilovatelneho C kodu je blbost. Z toho vznikne zasa len nieco necitatelne a vo vecsine pripadov prave jeden velky blob.
Daleko prinosnejsie pre analyzu by bolo keby to generovalo kod s urcitou pravdepodobnostou co by to mohlo byt. Ono aj tak 80-90% veci co sa valaju vo windowse je generovanych bud MS kompilerom, Mingw/GCC a Delphi/Borland. Este kde tu nieco od intelu a osatne kompilery len minimalne. No a da sa docela slusne odhadnut ze co vlastne ten ms kompiler a linker vyplul, minimalne co sa tyka standardnych kniznic a casto pouzivaneho kodu. Otazne je ako moc narocne by bolo vytvorit taky system a aka by musela byt velka znalostna db. Toto by mohla byt mozno uloha pre nejaku AI. Ostatne pozeram ze ten retdec ma nejake patterny pre delphi a celkom velke.
Docela by ma zaujimalo kde sa v ramci prace pouziva reverse engineering :-) [teda v zmysle viac nez len ze sa pozriem ako vyzera program konkurencie :) ]
U reverse engineeringu se musim mit moznost spolehnout na to, ze to co vidim dekompilovane odpovida tomu co bezi v pocitaci. Staci jednoduchy fiktivni kod
dwordvar = 0x55aabbcc;
dwordvar |= 0xff;
se treba prelozi jako xor edx,edx; {tuna kodu}; dec edx; {tuna kodu} ; mov dword ptr [esp+n], 0x55aabbcc; or byte ptr [esp+n], dl
tak a ted' kdyz decompiler zapomene, ze jednou to je dword a jednou byte (dolni byte dwordu) nebo zapomene co je edx (dl), tak je to dost nanic.
ad reveng: treba kdysi davno jsem zkoumal komunikacni protokol nejakeho mobilu (byly to 90. leta), v protokolu byl zahadny checksum, ktery branil pouziti telefonu jako GSM brany.
"Vygenerovanie nejakeho funkcneho a skompilovatelneho C kodu je blbost."
Fakt? A jak pak teda chces zjisti, co to dela, kdyz ti to vraci kod, kterej neodpovida binarce = neda se spustit.
Ten kod pochopitelne nebude odpovidat puvodnimu kodu, ale prekompilovatelnej a spustitelnej musi byt zcela vzdy a musi delat presne to, co dela ta binarka. Jinak je to naprosto knicemu.
Pokud myslite, ze staci nedokonala dekompilace ve smyslu ze nevadi kdyz se to obcas splete a staci "ze kod vypada na to co zhruba dela", tak se dle meho nazoru hrube mylite.
Je jedno, ze kod neni kompilovatelny, to ano. A pokud je, tak je asi jedno, pokud nevznikne 100% stejny binarni kod. Ale clovek musi byt schopen po precteni kodu zcela pochopit co program dela i v meznich situacich (tzn. vsechny flow vetve musi byt dekompilovany spravne). Pokud se takova dekompilace nepodari, dekompilator musi takovy stav detekovat a napr. vydumpovat assembler nebo hlasku typu "sorry jako".
Prekladace bezne generuji ruzne uchylne konstrukce a clovek se pak divi. Hlavne u PowerPC vznikaji prekvapeni typu "je ... to jsem nevedel, ze tuto instrukci lze pouzit i k tomuto ucelu" :).
Prográmek 290KB v c#