Uchopitelná ukázka, jak funguje reverzing

[Kockatá hlava]

Většinou je problém někomu vysvětlit, proč je reverzing zajímavej. Pro laika je to většinou těžko uchopitelná představa o něčem silně specializovaným. Tenhle článek to ale podává šikovným způsobem, přitom k tomu použil klasickej RE tool, fuzzer, v běžné praxi, ale pěkně ilustačně, protože při tom jako vedlejší produkt vznikají obrázky:

http://lcamtuf.blogspot.cz/2014/11/pulling-jpegs-out-of-thin-air.html

Vzpomněl jsem si na to při čtení o DQN, kde je použitej podobnej postup, akorát že DQN má přístup jenom k obrazovce a k pár hodnotám, zatímco fuzzer má přístup ke strojáku.

http://www.zive.cz/clanky/deep-q-network-inteligence-ktera-se-naucila-hrat-hry/sc-3-a-177329/default.aspx

[NeptuN]

Clanek zajimavej, alespon co jsem to zbezne zkouknul, ale pouziti fuzzeru mi prijde spis jako nouzovka nez neco, na co by se dalo spolehat nebo pouzivat bezne. Pro ilustraci RE a spol. mi prijde nejvystiznejsi citat jednoho fyzika (Feymann): "Co umim vytvorit, tomu rozumim." No a RE je vlastne jen zpusob, jak neco vytvorit, kdyz po ruce neni zadna ucebnice/dokumentace.

Jinak si uz dlouho pohravam s jednou myslenkou a rad bych si poslechl nazor ostatnich. Kazda funkce ci procedura je ve sve podstate jen zobrazeni, ktere danemu vstupu priradi vystup. Tj. pro kazdou funkci ci proceduru muzu napsat definicni obor (pripustne vstupni hodnoty) a obor hodnot (mozne vystupni hodnoty). Kamenem urazu mi v programovani prijde to, ze si programator nezjisti definicni obor ani obor hodnot a pak zacne kombinovat funkce. Napriklad: uvazujme dve funkce - prvni ma obor hodnot treba signed integer tj. od -32000 do + 32000 - druha ma definicni obor unsigned integer 0 az 64000. Kombinace obou funkci pak pro 0 - 32000 funguje, ale v pripade, ze prvni funkce da te druhe treba -5, ejhle brekot.

Ma myslenka se podoba tomu, co dela kompiler u silne typovanych jazyku, ale jde jeste dal - pokud bych pred implmentaci kazde funkce/procedury si sepsal definicni obor, obor hodnot a samotnou funkci/proceduru bych si vyjadril pomoci matematickeho vzorecku (matematiky se fakt nebojim) - napisu 'dokonaly' program? Tj. dokonale osetrim vsechny mozne stavy?

[Kockatá hlava]

Tu myšlenku jsem úplně nepobral. Jde o vytvoření teoretickýho programu, co vždycky pracuje bezchybně, to znamená, nikdy se nedostane do nedefinovanýho stavu?

[NeptuN]

Ano, presne tak. Tj. neuvazuji chybu v samotne myslence/logice programu, ale jak jsi rekl - v osetreni nedefinovanych stavu. Je to mozne, nebo jsem na neco zapomnel?

[Kockatá hlava]

U teoretickýho programu, co nedostává data odjinud a co nepoužívá nějaký API, aby se za běhu dostal k externím zdrojům, by to možný bylo. (Když uvažujeme o tom, že teoretickej počítač, na kterým ten program běží, není kompromitovanej a že zaručuje konzistentní pamět programu.)

Jenže většina programů se musí spolíhat na nějaký API, to znamená na "cizí" kód. Když třeba dynamicky alokuješ paměť něčím jako malloc(), nemůžeš si ověřit, jestli dostals platnej pointer a jestli došlo k alokaci veškeré paměti, kterou požadovals. Pokud bys to chtěl ošetřit exception handligem, ten stejně zase spouští kód, co je mimo tvou kontrolu.

Nefunkční malloc() je samozřejmě krajní případ, ale jde o princip. Prakticky může tvůj program čekat, až mu nějaký API pošle data z jiné aplikace. Můžeš sice testovat, jestli samotný data mají očekávanou strukturu, ale nemůžeš testovat, jestli dostals správnej pointer a tudíž jestli nebudeš číst z nealokované paměti (paměť mohla být špatně alokovaná, nebo mohlo dojít k jejímu uvolnění dřív, než se k tobě ten pointer dostal, nebo ten pointer může ukazovat na alokovanou paměť, ale omylem úplně jinam, než by měl).

Vzpomněl jsem si přitom na tenhle článek, tím se dostávám k praktické stránce věci: U user-mode programů se nepovažuje za chybu, pokud program při nesprávným vstupu prostě spadne:

IsBadXxxPtr should really be called CrashProgramRandomly
http://blogs.msdn.com/b/oldnewthing/archive/2006/09/27/773741.aspx

When you crash, make sure you crash in the right place
http://blogs.msdn.com/b/oldnewthing/archive/2006/09/28/775446.aspx

[NeptuN]

Dobre, ale stejne - kazda API funkce je zase jen funkci, ktera ma omezenou mnozinu vstupnich a vystupnich hodnot (konkretni akci s periferii lze povazovat za vystupni hodnotu). Vzdyt co je to dokumentace - vlastne jen popis, co ta funkce dokaze schroustat a co pak ze sebe vyhodi, obcas i s popisem (vice ci mene vystiznym), co dela. Osobne mam pocit, ze pokud by cely kod - vcetne operacniho systemu a jeho knihoven - byl napsan objektove a kvalitne zapouzdren + precizni dokumentace (tj. ne pomoci vagnich popisu - zaplat panbuh za typovane promenne = aspon neco, ale pomoci precizni matematiky), pak by odpadlo spoustu chyb a rozcilovani programatora nad kodem.

Nakousl jsi tema platnosti ukazatele, ale neni to vlastne jen zpusobeno spatnou/nepresnou komunikaci mezi OS a programem? Vzdyt OS tu pamet alokoval a pri te alokaci zjistil, ze treba uz nema misto - ale aby to nejakym zpusobem sdelil tomu programu, to ne - potouchle mu vrati 'jen' ukazatel a s usmevem ceka, az si program vylame zuby. Koneckoncu, vzdyt i dnes uz existuji chytrejsi ukazatele jako objekty, ktere si sebou nesou informace navic. Fakt mi prijde, misto aby OS s programem tahli za jeden provaz, tak se misto toho perou.

V pripade ukazatele, jehoz pamet nekdo jiny uvolni - neni to zase jen chyba OS resp. toho, ze pamet neni jako objekt a neni poradne zapouzdrena? Ano, pokud OS ti da pamet a ty si udelas na ni ukazatel, a OS to pak uvolni - tvoje smula. Ale nemel by ten ukazatel byt vlastne majetkem toho OS? Pokud dojde k uvolneni - tak pak OS muze zmenit priznak u toho ukazatele a zneplatnit ho.

Co se tyce tech vyjimek a toho padu programu pri spatnych parametrech, zminenych v tech odkazech - s tim vsim souhlasim. Premyslel jsem nad tim celkem dlouho a je pravdou, ze me nic lepsiho nenapadlo - ono totiz unvitr programu by k te chybe vubec dojit nemelo (prosim, na vstupu, pri kontrole vstupnich parametru - to je misto, kde si uzivateli postezovat, ale ne uvnitr). Bud at uzivatel zada jine vstupni parametry - pokud ten pad byl zpusoben daty - anebo at programator opravi chybu. V ten okamzik je lepsi padnout hned.

Jinak ja se snazil ve svych programech neustale kontrolovat data, jestli jsou ve spravnym rozsahu apod, ale vysledkem bylo pouze
1. moje zahlceni - misto vypoctu jsem delal jen tupou byrokracii
2. spomaleni pocitace.

Proto mi prave prijde, ze kontrolu vsutpnich dat udelat jen jednou a pote uvnitr programu (ale pro vicero oddelenych objektu) uz uvazovat, ze vsechna data jsou OK. Pak staci precizne implementovat me funkce, aby na sebe navazovaly (tj. aby jedna nepredala tu -5 a navazujici nebrecela, ze tu zpracovat neumi - pro to hodlam vyjadrit kazdou fci matematikou: definicni obor, obor hodnot a samotnou fci jako matematicke zobrazeni) a hotovo = nikdy mi uvnitr programu nenastane 'nepovoleny' stav.

Asi je hodne zoufale se ptat, jestli existuje nejaka verze linuxoveho jadra napsana objektove? Aby si pointer (v majetku OS, ale pouzivan mym programem) sebou zaroven nesl info o sve platnosti?

[Kockatá hlava]

Jo, myslel jsem to tak, že kód mimo tuhle teoretickou, dokonalou aplikaci se musí považovat ze nedůvěryhodnej, protože není pod kontrolou toho programu a můžou tam být neznámý bugy.

Reálnej stav je, že všude je bordel, jak v aplikacích, tak v API. Já jsem měl na mysli spíš teoretickej model než něco, čeho se dá dosáhnout v praxi.

A Windows API bylo napsaný v době, kdy bylo C++ úplně jinde než dneska, takže tenkrát neřešili nějaký smart pointery. Stejnětak třeba neexistoval thread pool. Mám dojem, že na Windows by toto měl řešit COM, co tě izoluje od WinAPI, ale nikdy jsem v tom nekódoval.

Jo, vstupní (nedůvěryhodný) data je potřeba kontrolovat v nějakým front-endu a z nich dál odvozený data už není potřeba tak důkladně prověřovat. Praxí člověk přijde na to, jak to dělat efektivně.

Pochybuju, že existuje nějaká použitelná verze Linuxu, napsaná objektivně, se smart pointerama. Ale ani ty smart pointery nevyřeší úplně všechno. Low-level kód, třeba nějaký propietární ovladače HW, nemusí s těma smart pointerama umět pracovat, takže s nima musí OS komunikovat pomocí "hloupých" pointerů. A zase jsme u původního problému, ovladač třeba udělá v paměti nějaký změny, ty se ale už nepromítnou do vlastností toho smart pointeru.

[pr0p4g4nd4]

vdaka chalani, pocital som si fajnovo. haluz je v tom, ze nemam ani anung o com je rec (hlavne teda prvy prispevok od NeptuN-a je klenot, haha) - ale kazdopadne, moja ucta vam obom za skvely konverzaciu.

k teme nastolenej MazeGen-om: neviem cim je reversing zaujimavy - ja som zacinal uz tak davno, ze ani neviem co ma zaujalo (jedine co mi tak napada, snad to boli recc compa u picassa - celkovo ta vyzva v crakovani, craknut nieco rychlejsie nez niekto iny - a rad som cital aj po ukonceni compa vzdy uverejnovane riesenia, to bolo super). nicmenej, ako som dosiel k tej samotnej myslienke hladat na nete take nieco ako re sajt (okrem ineho, teda hlavne picassov sajt) to netusim.. to je vylozena zahada.

nic proti, ale tie linky mna osobne by len odstrasili - take nieco by citali len fakt nejaki it geekovia so zamascenymi vlasmi. reverzerom moze byt aj normalny clovek. ;P zjavne ale zalezi od vkusu, co cloveka zaujme, no.