Kung Fu programiranje

Besplatni sklopovski rootkit sa Intel strojevima

2007-06-12T07:16:00.000+02:00

http://www.mail-archive.com/cryptography@metzdowd.com/msg07606.html

http://en.wikipedia.org/wiki/Intel_Active_Management_Technology

Zlouporaba sklopovske virtualizacije ili NGSCA modula je ništa prema ovome. Ovo je dostupno već danas, i radi kao curica, neovisno o OS-u (SOAP - dakle XML!) i direktno komunicira sa MMU/CPU/NIC sklopovljem.

Slammer 2, here I come..

Linux audio džungla

2007-06-08T23:05:00.000+02:00

http://blogs.adobe.com/penguin.swf/2007/05/welcome_to_the_jungle.html

A eto..graf je aciklički......uglavnom :P

Dream Theater

2007-06-08T02:02:00.000+02:00

rox!

Teorem o linearnom ubrzanju

2007-06-04T13:10:00.000+02:00

Jako je zanimljivo kako zaista malo programera i programskih inženjera razumije zašto ustvari koristimo Veliko-O (Big-O) notaciju u svrhu označavanja asimptotske gornje granice funkcije. Dobar ih dio u podne i ponoć zna izrecitirati formalnu matematičku definiciju za veliko i malo O, thetu, omegu i tildu ~, kao i odokativno procijeniti vremensku složenost nekih jednostavnijih algoritama s kojima se susretnu u praksi - no pravi razlozi korištenja takve asimptotske definicije im, izgleda, ostanu vječna enigma.

Stvar je inače jako jednostavna: u računskoj teoriji složenosti postoji jedno teoremče koje slovi kao Teorem o linearnom ubrzanju (linear speedup theorem) i formalno se može iskazati ovako:

Za proizvoljan rekurzivan (odlučiv) jezik L i za svaki Turingov stroj T koji ga odlučuje, za neku realnu nenegativnu konstantu c, postoji Turingov stroj S nad istom abecedom koji odlučuje L i za kojeg vrijedi:

time_S(n) ≤ c*time_T(n) + n, ∀n∈ N

Drugim riječina, za bilo koji TS koji rješava problem rabeći f(n) resursa, postoji stroj koji rješava isti problem u c*f(n) resursa, za c>0. To je razlog zašto se linearni faktori u konačnici ignoriraju i koristimo Veliko-O notaciju definiranu preko limesa.

Postoji još i općenitiji teorem o ubrzanju (speedup theorem) koji govori samo o postojanju ubrzivog jezika i koji nije primjenjiv samo na odlučive jezika, kao što je slučaj sa teoremom o linearnom ubrzanju. Za dokazivanje teorema koji bi za proizvoljani odlučiv jezik pokazao postojanje više od linearnog ubrzanja ne bi ginula Turingova nagrada ;)

Kvadratno se ubrzanje za neke klase algoritama (Groverov algoritam pretrage) može ostvariti kvantnim računalima, poput onoga kakvog je prototipno konstruirala kompanija D-Wave. Općenito se može pokazati da bilo koji problem koji može biti riješen brute-force pretragom slučajno odabranih instanci, može kvadratno ubrzati

Par bisera

2007-06-03T02:34:00.001+02:00

na koje naletih baš danas:

http://www.xml.com/ldd/chapter/book/ch04.html

Many readers may be wondering why the kernel does not have any more advanced debugging features built into it. The answer, quite simply, is that Linus does not believe in interactive debuggers. He fears that they lead to poor fixes, those which patch up symptoms rather than addressing the real cause of problems. Thus, no built-in debuggers.

http://osdir.com/ml/sysutils.autoconf.general/2004-09/msg00086.html

Please do not port software to Windows, or, by extension, assist in
porting software to non-free operating systems. While GPL licensed
software specifically permits this, DON'T DO IT AND DON'T HELP. Making
Windows more usable gives users less reason to switch to free software
and more reason to continue funnelling time, effort and money into
people and companies who take away freedom at every opportunity.

Genijalno! :)

Koprocesi

2007-06-01T19:52:00.000+02:00

UNIX sistemski filter jest bilo program koji čita sa standardnog ulaza i piše na standardni izlaz. Obično se ulančavaju cjevovodima u shellu (koji su pri tome, kao što je Oleg Kiselyov jednoć pokazao, pri tome monadi!), filtar se nazivno promovira u koproces u trenutku kada isti program generira filtrov ulaz i čita mu izlaz, efektivno ga utilizirajući kao subsidijalnu računsku jedinku.

Iako popularniji shellovi ne podržavaju izravno koprocese (pingvinski bash/sh/csh), neki kao ksh jesu, i to uz poprilično gadnu sintaksu. No svejedno, sa stajališta sistemskih programa, koprocesi su jako korisna koncepcija. Obično ih ostvarujemo kreiranjem po para jednosmjernih (unidirekcionalnih, half-duplex - iako POSIX.1 dozvoljava ali ne zahtijeva full-duplex) cjevovoda (pipes), koje u roditelju otvaramo za čitanje/pisanje, dok u forkanom djetetu u kojem exec*-amo koproces komplementarno za pisanje/čitanje.

U 5. labosu iz kolegija Operacijski Sustavi 1, koncept se koprocesa rabi za provjeru ispravnosti korisničkih aritmetičkih izraza, projvjeravajući njihovu validnost i krajnji rezultat transparentno preko bc(1) koprocesa. Sva rješenja dotičnog zadatka koja sam ja vidio od svojih kolega, a bome i primjeri koji su asistenti-pingvini dali na većspomenutim stranicama, imaju jedan kritičan race condition.

Naime, problem leži u standardnoj I/O buffering polisi, koja se programski dade kontrolirati (sa setvbuf(3), odnosno eksplicitnim fflush(3)-anjem nakon svakog pisanja), no to postaje malo nedohvatljivo u slučaju pretkompiliranog binarya kojeg ne možemo izmjeniti (bar ne koristeći neki platformski-nezavisan POSIX-kompatibilan način). ISO C zahtijeva sljedeće buffering karakteristike:

Standardni ulaz i standardni izlaz su u potpunosti buffered, akko se ne odnose na interaktivni uređaj.
Standardni izlaz za greške nikad nije u potpunosti buffered.

Ovo, međutim, ne kaže mogu li stdin/stdout biti unbuffered ili linijski bufferirani ukoliko su vezani za interkativni uređaj, kao i treba li stderr biti unbuffered ili linijski buffered. Većina implementacija (POSIX je specifikacija, ne implementacija!) po defaultu koriste sljedeće tipove:

Standardni izlaz za greške je uvijek unbuffered.
Svi su drugi streamovi linijski bufferirani ako se odnose na terminal, inače su fully buffered (obično po 1024B).

Standardni ulaz i izlaz koprocesa evidentno nisu vezani za terminal - i tu leži problem. Oni read(2)-ovi na izlaz iz koprocesa mogu potencijalno zauvijek blokirati pozivatelja koji čita sve dok ne dobije '\n' (bez obzira čak i ako koristimo neblokirajuće čitanje u petlji - još gore, sad imamo livelock!). Pozivatelj čeka na izlaz iz koprocesa, koproces čeka na ulaz iz pozivatelja, I/O podsustav čeka da u potpunosti bufferirani izlaz iz koprocesa pređe predefinirani prag popunjenja pa da ga može flushati i poslati pozivatelju - deadlock smrdi na kilometar.

Teži način rješavanja ovog potencijalno cirkularnog čekanja jest pokretanje koprocesa pod pseudoterminalom kojeg ustvari exec*-amo i koji najposlije pokreće koproces. Pisanje drivera za vlastiti pseudoterminalni uređaj je netrivijalno (dobro ne baš toliko teško, ali u svakom slučaju previše za nekoga tko samo želi naučiti elementarne IPC koncepte, a osim toga postoje i začkoljice o tome radi li se o BSD ili SystemV...), iako dakako postoje već gotova rješenja na netu.

Drugi je, lakši i hax0rskiji način, redefinirati isatty(2) tako da uvijek vraća istinu:

_isatty(int fd) { return 1;}

cc -G moj_isatty.c -o moj_isatty.so -Kpic

i potom na Solaris kanti na pinusu (naziv studentskog stroja) dinamički linkati na tu verziju podešujući okolinu koprocesa (odmah nakon forkanja):

LD_PRELOAD=/path/to/moj_isatty.so

Lijena evaluacija u F#

2007-05-31T03:00:00.000+02:00

let rec fibs = Seq.delay (fun() -> fibs |> Seq.cons 0I |> Seq.cons 1I |> Seq.pairwise |> Seq.map (fun (x,y) -> x+y))

Ovo je inače prijevod u F# Haskell onelinera:

fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

seq<_> je inače tipni sinonim za CLR IEnumerable<T>, i sve su mu metode (osim nekoliko njih koji se ticu konverzija u striktno reducirane liste i nizove) lijeno (po potrebi) evaluirane:

> Seq.take 10 fibs;;
val it : bigint list = [1I; 1I; 2I; 3I; 5I; 8I; 13I; 21I; 34I; 55I]

Verzija koristeći ireffutable as-pattern:

let fib@(1:tfib) = 1 : 1 : [ a+b (a,b) <- zip fib tfib ]

Nije toliko trivijalno translatabilna, s obzirom da nije moguce napraviti strukturalni pattern-matching na seq<_> i njegove konstrutore tipa kojih (koliko vidim) - nema.

Phrack #64

2007-05-30T04:01:00.000+02:00

Nakon duge i teške bolesti, izašao je Phrack 64, ovaj put pod novim, razmlađenim uredništvom koji se naslovljavaju kao The Circle of Lost Hackers.

Phrack degradira već više od dekade, kako kvalitetom članaka tako i nedostatkom duha undergrounda, koji se u moru industrijski-certificiranih InfoSec profija raspršio na kojekakve anonimuse koje više zanima kako da zajebu Warcraftov Warden nego ganjaju pikanterije libc-ovog alokatora.

Preseravanja o povijesti scene, međunarodnim scenama (vraćanje u prošlost uvijek dobro dođe za prebjeg iz tmurne svakodnevice), freudovsko pretakanje iz šupljeg u prazno o "hakiranju svijesti" (..is but a dream within a dream) i novim revolucijama, začinjenim dozlaboga isfuranim paranojama o orwellovskom svevidećem oku koje jedva čeka analizirati što je h4k3r_17zg nasrao na ICQ bareći neku masnu kozurinu. Kako funkcionira DMA i mmaped IO je više mjestu OS udžbeniku opće namjene, a ne nečemu što pretendira na tron najelitnijeg haxorskog zinea. Hello World primjer spremanja podataka u GPU memoriju koji je maltene copy/pasted iz NVIDIA-inog CUDA SDKA da i ne spominjemo.

Na razini su jedino papiri Attacking the Core: Kernel Exploitation Notes (tehnički ekscelira) i Blind TCP/IP hijacking is still alive (originalnost - rabeći prethodnika ove tehnike je Shimomura uhvatio Mitnicka! :) Ostalo sve već viđeno/reciklirano na ovaj ili onaj način.

U međuvremenu, dok se vodstvo phracka reorganiziralo i pohvatalo izmakle konce, svi koji nešto znaju su prešli u komercijalne vode i za objavljivanje članaka u nekim 31337 zineovima pod pseudonimima im je stalo koliko je i crno pod noktom. Koga briga za "ugled" u zajednici anonimusa kad puno veći (a usto i financijski blagoslovljen) ugled donosi održavanje predavanja/radionice na konferencijama klase BlackHat ili CanSecWest.