Etikettarkiv: verktyg

Bli en BIOS-ninja och skydda din kod

För dig som verkligen vill grotta ner dig på lågnivå i en PC kan det vara trevligt att veta att Darmawan Salihun släppt sin bok BIOS Disassembly Ninjutsu Uncovered fritt tillgänglig på nätet.

Boken börjar med en introduktion till hur en PC är uppbyggd inklusive PCI-protokoll och chipset. Men sedan trillar boken snabbt ner i saker som hur BIOS är uppbyggt, hur man plockar isär och dekompilerar binärfiler. Boken använder verktyg som IDA Pro, men är egentligen rätt verktygs- och OS-neutral. En bra bok, väl värd att titta en stund i. Och kanske testa lite exempel.

IDA Pro
IDA Pro.

Om man nu vill veta hur man skyddar sin kod mot dekompliering, analys och isärplockning, och därmed även vill veta mer hur trojaner och annan elak kod på olika sätt fungerar för att skydda sig mot att bli hittade och rensade, finns en mycket bra artikel. Josh Jacksons An Anti-Reverse Engineering Guide är från 2008, men fortfarande högst relevant. Artikeln tar upp hur debugsystemet i x86 ser ut och används. Sedan visar artikeln på ett antal olika metoder för att detektera debuggningsförsök, försvåra för debuggning och till och med direkt ge sig på debugverktygen. Även om attacken på Ollydbg patchats för länge sedan.

Detekterad debugger.
Detekterad debugger.

För dig som vill börja doppa tårna i x86-assembler finns Randy Hydes bok Art of Assembly Language på nätet. Det finns versioner såväl för den som fokuserar på 32-bit Windows som för den som vill hacka Linux/UNIX. Och 16-bit DOS. På den webbplatsen finns även HLA-biblioteket.

Bra samling av bithanteringstrick

Vid konstruktion av digitala tekniska lösningar är det inte ovanligt att man behöver göra olika bitmanipulationer och trick med bitar. Detta gäller inte minst inbyggda system med begränsningar i utrymme och prestanda. Alla erfarna konstruktörer har några favorittrix dom tar till för att effektivt lösa ett problem. Typiska trick är kopiering av data i internregister, hitta mest signifikanta biten som är satt i ett ord eller beräkna paritet.

Sidan Bit Twiddling Hacks har den största samlingen av bithanteringstricks jag sett. Det som gör trixen speciellt intressanta är att i stort sett samtliga tricks formellt verifierats med verktyget UCLID. De flesta trick är mest effektiva på en processor med 32-bitars operatorer (och fungerar ofta bra på mindre arkitekturer). Men vissa av dom är avsedda för maskiner med 64-bitars operatorer eller generellt oavsett bitstorlek.

Jag hittade ett bra trick för att beräkna rank parallellt som i hårdvara fungerade riktigt bra. Du kanske också hittar något matnyttigt?

sphlib 3.0

För ett tag sedan släpptes version tre av biblioteket sphlib. Sphlib implementerar samtliga finalister samt flera av de tidigare kandidaterna till hashfunktionstävlingen för att få fram hashfunktionen SHA-3. Om man vill börja underrsöka och testa SHA-3-algoritmer är sphlib trevlig att arbeta med.

Sphlib ger inte maximal prestanda och har därför fått kritik för att kanske inte ge en perfekt bild av vad de olika kandidaterna kan åstadkomma. För den som vill se den typen av resultat finns EBASH-projektet att titta på. Men för den som inte är ute efter prestanda, utan titta på funktion, struktur etc är sphlib bra.

Kostnaden för att knäcka CAPTCHAs

För en vecka sedan skrev jag om Pensionsmyndighetens beslut att införa en teknisk lösning kallad CAPTCHA för att stoppa robothandel. Det jag försökte visa var att det problem myndigheten sade sig ha inte är en bra lösning – en CAPTCHA stoppar inte datorer, samtidigt som den valda lösningen försvårar för mänskliga användare och slår ut bra tjänster.

reCAPTCHA
reCAPTCHA

En metod för att forcera CAPTCHAs myndigheten öppnar upp sig för som jag beskrev är att använda människor som stödfunktion för datorer. Jag fick efter min postning frågor om hur realistiskt det är  – om det går att göra och om det inte kostar för mycket. Som tur postade Boingboing en artikel om tjänster där människor används för att attackera CAPTCHAs. Och där finns det bra prisinformation. Artikeln handlar om ett ryskt företag, KolotiBablo som kopplar samman arbetare med applikationer som behöver knäcka CAPTCHAs:

Paying clients interface with the service at antigate.com, a site hosted on the same server as kolotibablo.com. Antigate charges clients 70 cents to $1 for each batch of 1,000 CAPTCHAs solved, with the price influenced heavily by volume. KolotiBablo says employees can expect to earn between $0.35 to $1 for every thousand CAPTCHAs they solve.

Dvs maximalt en tusendels dollar för en CAPTCHA. KolotiBablo är lång ifrån den enda tjänsten. Tjänsten med det vackra namnet Deathbycaptcha tar 1.39 USD för 1000 CAPTCHAS och redovisar dessutom lite statistik för sin tjänst. Medeltiden att knäcka en CAPTCHA är 17 sekunder och har 90% chans att lyckas.

För den som vill läsa mer om KolotiBablo finns mer i en artikel om företaget och dess tjänster hos KrebsonSecurity (en artikel som Boingboing pekar på). Det finns även en bra forskningsartikel som tittar närmare på ekonomin för att knäcka CAPTCHAs, en artikel väl värd att läsa om du vill förstå hur denna marknad fungerar.

LLVM 3.0 släppt

Version 3.0 av kompilatorsystemet LLVM släpptes den första december.

LLVM-loggan.

LLVM är ett öppen kod-projekt (med BSD-liknande licens) som sponsras av bland annat Apple, och är även den kompilator som finns i Apples utvecklingsmiljö Xcode – både för iOS och Mac OS X. Dock är LLVM inte specifikt för Mac, utan finns till många olika OS, bland annat som del av FreeBSD sedan ett drygt år tillbaka. Här är och en lista på produkter, system och projekt där LLVM används.

Det jag gillar med LLVM och inte minst dess C-kompilator clang är att dess förmåga att detektera fel och generera bra felmeddelanden. Speciellt i jämförelse med gcc är clang mycket mer hjälpsam. I mina tester genererar clang+LLVM mer kompakt kod än gcc, och oftast även snabbare program. Dessutom kompilerar oftast clang+LLVM snabbare än gcc.

LLVM inkluderar inte bara clang, utan flera andra bra verktyg. Debuggern LLDB är fortfarande ett relativt ungt verktyg, men är redan riktigt bra. Inte minst att LLDB går att integrera med Python öppnar upp för automatiserad debugging och analys. Ett annat verktyg i familjen jag tidigare skrivit om är den statiska kodanalysator som finns till clang.

Clang STA-rapport.
Exempel på rapport från Clangs STA-verktyg.

Det pågår även ett aktivt arbete med att utveckla nya funktioner runt LLVM. Projektet SAFECode är ett exempel. SAFECode försöker att genom en kombination av statiska och dynamiska kontrollmekanismer generera säker kod med minimala kostnader i form av kodstorlek och prestanda.

LLVM+clang är stabila verktyg som integrerar väl med befintliga kompileringsmijöer, speciellt GCC. Om du använder GCC men inte redan testat LLVM+clang tycker jag att det är dags att göra det.

OpenCL för FPGA-konstruktion

Uppdaterat med referens till artikel om OpenCL från Altera.

En ny version av OpenCL

För ett par veckor sedan släppte organisationen Khronos version 1.2 av OpenCL. OpenCL är en utökning av programspråket C99 samt ett ramverk med verktyg och bibliotek. Med OpenCL är det möjligt att bygga program som utnyttjar parallell beräkningskapacitet i processorer (CPU), grafikprocessorer (GPU) m.m. Inte minst viktigt är att OpenCL gör det möjligt att programmera heterogena system, dvs system där det finns olika typer av processorelement.

Kärnan i OpenCL är möjligheten att skapa segment kallade kernels av kod och data koden skall bearbeta. Det är upp till dig som programmerare att beskriva hur de parallella operationerna ska utföras, vilka dimensioner problemet ska ha etc. När väl din kernel är skapad och kompileras genereras kod som körs på den parallella hårdvaran samt sekventiell kontrollkod avsedd för en kontrollprocessor. Kontrollkoden ser till att skicka kernel och data till den parallella hårdvaran, får kernel exekverad och tar slutligen emot resultatet.

Den vanligaste användningen av OpenCL är för att programmera GPU:er i datorer. OpenCL börjar även användas för att programmera den ökande mängden processorkärnorna i vanliga processorer, nätverksprocessorer och digitala signalbehandlingsprocessorer (DSP). Inte minst är detta intressant i högpresterande inbyggda system som basstationer för mobilsystem.

För den som vill titta närmare på OpenCL 1.2 finns specifikationen här (pdf).

Sponsorer av OpenCL är företag som Apple, AMD, Intel och IBM, men även Ericsson stödjer Khronos och OpenCL.

En ny version av OpenCL är egentligen inte så intressant. Det som fick mig att reagera på EE Times artikel var istället att företaget Altera officellt börjat stödja OpenCL. Altera tillverkar inte processorer – hårdvara som har en fix instruktionsuppsättning man kompilerar sin kod till. Altera bygger FPGA:er.

Sidospår om FPGA-konstruktion

En FPGA är en digital krets fylld med små byggblock, ledningar och kopplingselement. Hur byggblocken fungerar och hur dom kopplas samman via ledningar och kopplingselementen styrs av bitar lagrade i kontrollregister. Genom att skriva ner en konfiguration i kontrollregistren går det att få FPGA:n att implementera olika digitala funktioner. Gränssnitt för Ethernet, MP3-avkodare, filter för bildbehandling och faktiskt hela processorer och digitala system går att implementera i en modern FPGA. Man kan till och med implementera en FPGA i en FPGA.

Poängen med en FPGA är att den är väldigt parallell med massor av små byggblock, men det finns ingen egentlig instruktionsuppsättning eller schemaläggare som styr hur exekveringen går till. Det är en ren digital struktur och det är upp till dig som användare att skapa den konfiguration du behöver. Detta arbete är mer likt traditionell digital konstruktion än att programmera en processor, även om du använder assembler.

Normalt används konstruktionsspråk som Verilog, SystemVerilog (SV) eller VHDL. Den generella abstraktionsnivån i dessa konstruktionsspråk är relativt låg. Så länge som jag arbetat med digital konstruktion (sedan mitten av 1990-talet) har det dock funnits en strävan, en trend mot att försöka lyfta abstraktionsnivån.

Det har kommit och gått en massa försök med högnivåsyntes till nya språk som SystemC. En i min åsikt gemensam egenskap med dessa lösningar har varit en stor komplexitet och oförmåga att leva upp till de produktivitetsökningar man utlovar. Genom att gräva ner sig i schemaläggningar, delning av resurser, optimeringar etc har verktygen blivit komplexa, svåra att arbeta med och kräver mycket datorresurser.

Altera C2H

En som tog en liten annan väg var faktiskt Altera som för några år sedan lanserade C2H. C2H är ett verktyg för att ta vanlig C-kod och konvertera till digital hårdvara. Och det som gör C2H så smart, var att de är så dum.

Du som konstruktör får hela ansvaret att skriva din C-kod så att C2H kan fatta hur motsvarande hårdvara ser ut. Använder du 17 multiplikationer i din funktion får du 17 multiplikatorer. Vill du använda färre multiplikationer får du skriva om din kod så att samma multiplikationsuttryck används flera gånger.

Å andra sidan är C2H snabb. På några minuter kan du generera hårdvara och få återmatning. Eftersom C2H även är en del av utvecklingsverktygen för Alteras processor Nios II kan du dessutom testa att köra koden som ren SW, profilera din kod och sedan försöka konvertera de kritiska funktionerna till hårdvara.

Den magi som finns i C2H är kopplingen mellan hårdvaran och den kontrollkod som skapas för Nios II-processorn som krävs för att styra den genererade hårdvaran och använda den i resten av applikationen.

För den som vill veta mer finns det utbildningsmaterial och användarguide för C2H. Det finns även ett exempel på acceleration av beräkning av Mandelbrotmängder. Den arkitektur som används ser ut så här:

Arkitekturen hos Alteras Mandelbrotsberäknare.

I exemplet nås 60 gångers prestanda jämfört med en ren SW-implementation.

Acceleratorn blir alltså en applikationsspecifik stödprocessor till processorn. Men det går att bygga coprocessorer som är kapabla att själva läsa och skriva till minnen och arbeta självständigt.

FPGA – den nya OpenCL-arkitekturen

När jag tittar igenom det material från Altera som finns om OpenCL får jag samma känsla som när jag såg C2H första gången.

Du som konstruktör får ansvaret för att styra vad som ska bli parallell hårdvara och att det data som skall bearbetas finns i rätt format etc. Och kanske det viktigaste – att försöka parallellisera de delar som spelar roll för applikationen. Den magi, infrastruktur får att få systemet att hänga ihop sköter Altera och OpenCL.

Att ha FPGA som målplattform för OpenCL öppnar upp för nya typer av heterogena arkitekturer med mulicore, GPU och FPGA:er blandat. En FPGA kommer aldrig att komma upp i de klockfeekvenser som en GPU snurrar i så för vissa applikationer kommer en FPGA inte att ersätta CPU eller GPU.

(En tumregel att en FPGA når en tiondel av klockfrekvensen som en direktimplementerad digital krets. Den funktion som implementeras kräver dessutom ungefär tio gånger så mycket digitala grindar i en FPGA.)

Fördelen med FPGA:n är istället att den är en generisk digital struktur med mängder av “processorelement”. Antalet element och hur elementen fungerar kan direkt anpassas (skapas) för att processa en OpenCL-kernel. Detta gör att du kan få mycket högre prestanda i en mer flexibel arkitektur. Och precis som med C2H kan du med OpenCL alltid pröva, och analysera din kod som ren SW-lösning på en multicore-maskin eller på GPU innan du konverterar valda delar till hårdvara.

Det finns en bra preso om OpenCl för FPGA (pdf) av Desh Singh från Altera som visar hur Altera tänker sig att det ska fungera. Från preson är det klart att Altera stödjer både system med FPGA:er på kort i traditionella datorer och system där även processorn implementeras i FPGA:n.

Det finns även en mycket bra artikel från Altera om hur OpenCL är tänkt att fungera (pdf). Artikeln visar hur OpenCL används för att skapa parallella instanser av kernelspecifik logik som processar data. Instanserna styrs sedan av kontrollkod som körs på mjuka processorer i FPGA:n (exempelvis Nios), hårda ARM-kärnor (Altera har FPGA:er med ARM-kärnor) eller x86-processorer.

I artikeln finns även ett prestandatest i form av en Black Scholes. Enligt artikeln är själva OpenCL-koden är på ungefär 300 rader och är porterbar till CPU, GPU och FPGA.

en fyrkärnig Intel Xeon-processor ger 240 miljoner simuleringar/s, en GPU 950 miljoner/s och Alteras Stratix IV-krets 2200 miljoner simuleringar/s.

Slutsatser

För hårdvaruarkitekturer är det en gammal sanning av det är programmeringsverktygen som avgör. Oavsett hur bra, snygg och smart din arkitektur är, kommer ingen att vilja använda den om det inte finns verktyg – program som gör att det effektivt går att programmera applikationer för arkitekturen. Detta gäller microcontrollers, desktopprocessorer, DSP:er, närverksprocessorer. Och FPGA:er.

Jag tror att Altera med satsningen på OpenCL visar att man faktiskt fattar detta och ger sina kunder och användare nya sätt att bygga hårdvara som implementeras i deras FPGAer. Själva poängen är ju för Altera att sälja fler FPGA:er – och gärna genom att hitta nya marknader och kunder än de som traditionellt bygger egna digitala konstruktioner.

Jag ser inte OpenCL som ersättning för C2H. Visst, du kan bygga motsvarande hårdvara med C2H som OpenCL, men egentligen är verktygen för olika typer av problemdomäner.

OpenCL ancvänder du för att bygga parallell hårdvara för att maximera prestanda i problem där du parallellisera upp delberäkningar. C2H använder du för att bygga systemet runt din parallella hårdvara.

När du byggt din AES-kernel till din parallella AES-kryptoknäckare i OpenCL använder du C2H för att bygga paketprocessing och koppla Gbit Ethernet-gränssnitten med AES-motorn. Slutligen lägger du kontrolllkod i Nios II-processorn för att få allt att arbeta ihop.

Heterogent. Inbyggt. I en FPGA-krets. Snyggt.


Säkerhetsfunktioner i Javascript

Javascript har utvecklats från att vara ett enkelt scriptspråk som körs i en webbläsare till att bli ett populärt språk som även används på servrarsidan, i desktopapplikationer och i inbyggda system. Javascript i sig är ett mer kapabelt språk än man kanske tror, och dessutom utvecklas mycket, spännande funktioner till Javascript. Bland annat inom säkerhetsområdet.

Techworld och Slashdot berättar att tyska företaget Recurity Labs har utvecklat en implementation av OpenPGP (RFC 4880) i Javascript. Implementationen, GPG4Browsers är i dag implementerad som en plugin till Google Chrome. Med GPG4Browsers går det bland annat att kryptera, dekryptera och signera, verifiera epost samt importera och exportera certifikat direkt i webbläsaren. GPG4Browsers stödjer de symmetriska kryptona AES, CAST5, DES, Blowfish och Twofish, hashfunktionerna SHA (från SHA-1 tom SHA-512), MD5 och RIPEMD-160. Slutligen stöds även de asymmetriska funktionerna RSA, DSA och El Gamal.

Även om GPG4Bwosers i dag är en plugin finns källkoden tillgänglig. När jag tar en titt på kryptofunktionerna ser jag inga uppenbara beroenden till Chrome, utan det ser ut att vara ren, väkommenterad och troligen portabel kod. För att vara kryptokod är den faktiskt ovanligt väl strukturerad och kommenterad. Ser dock inte ut att vara optimerad för prestanda (mycket loopar och funktionsanrop). Koden är öppen kod enligt LGPL.

Ett annat bibliotek som ger kryptfunktioner i Javascript är Stanford Javascript Crypto Library (SJCL). Detta bibliotek är byggt för att vara litet (kodmässigt och RAM-mässigt), vara enkelt att använda samt använda vettiga grundinställningar. De funktioner som tillhandahålls är AES, SHA-256 samt några olika kryptomoder (CTR, CCM, OCB2). Dessutom finns lösenordsfumktionen PBKDF2. Det skall även finnas en experimentell version som implementerar de asymmetriska funktionerna ECDH och ECDSA. SJCL är licensierad antingen under BSD eller GPLv2. Det finns en testsida för att se att en port av SJCL fungerar. Så här såg det ut när jag testade:

Test av SJCL. Notera prestasiffrorna
Test av SJCL. Notera prestasiffrorna

Den sista länken jag vill peka på är en sida som diskuterar slumptalsgeneratorer i Javascript. Den generator som finns i Javascript (definierad i ECMA-262) är inte den speciellt bra. Den duger speciellt inte i säkerhetsfunktioner. Sidan ovan beskriver de tekniska skälen till kvaliteten hos standardgeneratorn samt presenterar en samling med olika slumptalsgeneratorer med bättre egenskaper. Notera att vi i det här läget pratar om pseudoslumptalsgeneratorer (PRNG). Använder du slumptal mycket i dina Javascript-applikationer kan detta vara en sida värd att lägga en stund på. Den kod som finns är BSD-licensierad.

WaterRoof – grafiskt gränssnitt till IPFW på Mac

Jonas Lejons blogg sprang jag på verktyget WaterRoof. WaterRoof är ett grafiskt gränssnitt till brandväggen IPFW som finns i Mac OS X. IPFW är en mycket kompetent brandvägg som utvecklas som del av operativsystemet FreeBSD.

WaterRoof gör det möjligt att på ett enkelt sätt skriva och applicera brandväggsregler för IPFW. Men den gör dessutom mycket mer än så. Waterroof gör det möjligt att kolla loggar, statistik, nätverksprocesser och mycket mer. Det är snarare ett verktyg för att övervaka och kontrollera din dators nätverksanslutning.

I Mac OS X (och i FreeBSD) finns även OpenBSDs brandvägg pf, och den är på många sätt, mer modern bättre och enklare att arbeta med. Jag tycker dock att WaterRoof i sig är ett verktyg värt att titta på om man använder Mac OS X.

STEED – Initiativ för kryptering mellan ändpunkter

Sprang på ett nytt säkerhetsinitiativ kallat STEED. Tanken med STEED är att utveckla kryptering som spänner hela vägen mellan ändpunkterna i en kommunikation och skall vara så enkel att använda att det alltid (ofta) används. Initiativtagarna till STEED skriver:

End-to-end e-mail encryption is still ignored by almost all users. The mails are left in the clear in the mailboxes of the web mail providers, where they are frequently collected by attackers and lead to an escalation of the attack due to the sensitivity of the mail content. We suggest a new and simplified infrastructure to protect mail that is compatible with OpenPGP and S/MIME and relies on an easy-to-use trust model without a central administration.

Initiativtagarna är i det här fallet Marcus Brinkmann och Werner Koch från Tyska företaget g10CODE, kanske mest kända för att driva utvecklingen av GnuPG.

Det SPEED är tänkt att erbjuda är saker som:

  • Automatisk nyckelgenerering
  • Automatisk nyckeldistribution
  • Opportunistisk kryptering
Tillsammans är detta egenskaper avsedda att göra säkehetsanvändningen så osynlig som möjligt som användaren. I första hand verkar STEED vara fokuserat på mailtjänster. Det finns en artikel av Marcus och Werner som närmare beskriver vad de vill åstadkomma med STEED och hur detta är tänkt att ske. Vi får se om STEED flyger eller inte, men initiativ som gör säkerhet enklare att använda och därmed mer utbredd gillar jag.

Libmich – ett bibliotek för att generera och analysera mobiltrafik

Sprang i dag på ett Pythonbibliotek kallat libmich. Likt mitt gamla favoritbibliotek ScaPy är libmich avsett att sätta ihop och plocka isär trafik i olika lager. Det som gör libmich speciellt är att det är inriktat på mobiltrafik.

Basen i libmich är ett antal formatklasser som går att använda för att generera eller konsumera olika typer av trafik. Just nu finns det bland annat stöd för EAP, L3GSM Resource Records, SIGTRAN m.m. Libmich har utvecklats av Benoit Michau på France Telecom och libmich är GPLv2-licensierat.

Jag ser att libmich är användbart på flera sätt. Vid utveckling där man behöver förstå hur trafiken hänger ihop och ser ut. Vid verfiering för att skapa mer eller mindre korrekt trafik samt för att sedan kunna analysera trafik från annan utrustning.