Nedenfor er en artikkel jeg fant nylig. Dette et av de mest omfattende beskrivelser av PIN Verification Value (pvv) hacking.
Jeg trodde jeg ville kopiere det her for min lokale referansen.
Som kommentar har blitt gjort med hensyn til grammatikk brukt i den opprinnelige teksten, jeg har rettet opp noen av de åpenbare feilene samtidig opprettholde en sammenheng av det opprinnelige materialet.
http://69.46.26.132/ ~ biggold1/fastget2you/tutorial.php
--- Original tekst ----
Forord
Har du noen gang lurt på hva som ville skje hvis du mister din kreditt-eller debetkort, og noen finner det. Vil denne personen kunne trekke kontanter fra en minibank for å gjette, eller annen PIN-koden din? Videre, hvis du var som mener noen kort ville du forsøke å gjette PIN og ta sjansen å få noen enkle penger? Naturligvis er svaret på begge disse spørsmålene er "nei". Dette arbeidet ikke omhandle andre spørsmål, er det et spørsmål om personlig etikk. Dette jeg forsøker å svare på det første spørsmålet.
All informasjon som brukes til dette arbeidet er offentlig og kan fritt funnet i Internet. Resten er et spørsmål om matematikk og programmering, og dermed kan vi lære noe og ha det moro. Jeg avslører ingen hemmeligheter. Videre er målet (og endelig konkludert) av dette arbeidet er å vise at PIN-algoritmer er fortsatt sterk nok til å gi tilstrekkelig sikkerhet. Vi vet alle teknologi er ikke det svake punktet.
Dette arbeidet analyserer ett av de mest vanlige PIN-algoritmer, VISA pvv, brukt av mange minibank kort (kreditt-og debetkort) og prøver å finne ut hvor motstandsdyktige er å PIN gjette angrep. Ved å "gjette" Jeg trenger ikke bety å velge et tilfeldig PIN-kode og prøver den i en minibank. Det er velkjent at vi generelt er gitt tre påfølgende rettssaker for å angi riktig PIN-kode, dersom vi ikke minibank holder kortet. Som VISA-PIN-koden er firesifret lenge det er lett å utlede at sjansen for et tilfeldig PIN gjettet er 3 / 10000 = 0,0003, synes det lite nok til å være trygge, det betyr at du trenger å miste kortet ditt mer enn tre tusen ganger ( eller å miste mer enn tre tusen kort på samme tid:) inntil det er en rimelig sjanse for å tape penger.
Det jeg egentlig menes med "gjette" var å bryte PIN-algoritmen slik at du får noen kort kan du umiddelbart kjenner den tilhørende PIN-kode. Derfor dette dokumentet studier som mulig, analysere algoritme og foreslår en metode for angrep. Til slutt gir vi et verktøy som implementerer angrep og presentere resultater om anslått sjansen for å ødelegge systemet. Merk at så lenge andre banktjenester sikkerheten i forbindelse algoritmer (andre PIN-formater, for eksempel IBM PIN eller kort validering signaturer som CVV eller CVC) ligner på VISA-PIN-koden, den samme analysen som kan gjøres noe som gir nesten samme resultater og konklusjoner.
VISA pvv algoritme
En av de vanligste PIN-algoritmer er VISA PIN Verification Value (pvv). Kunden er gitt en PIN-kode og en magnetisk stripe kortet. Kodet i magnetiske stripen er et firesifret nummer, kalt pvv. Dette nummeret er en kryptografisk signatur for PIN-og andre data knyttet til kortet. Når en bruker skriver inn hans / hennes PIN minibanken leser magnetiske stripen, krypterer og sender denne informasjonen til en sentral datamaskin. Det en prøveperiode pvv er beregnet ved hjelp av kunden tastet PIN-kode og kort informasjon med en kryptografisk algoritme. Rettssaken pvv er sammenlignet med pvv lagret i kortet, hvis de samsvarer med den sentrale datamaskinen tilbake til minibanken autorisasjon for transaksjonen. Se mer detaljert.
Beskrivelsen av pvv algoritme kan finnes i to dokumenter knyttet i den forrige siden. Oppsummert det består i kryptering av en 8 byte (64 bit) streng med data, kalt Transformed Security Parameter (TSP), med DES-algoritmen (DEA) i Electronic Code Book modus (ECB) hjelp av en hemmelig 64 bits nøkkel. Den pvv er utledet fra utdataene for kryptering, som er en 8 byte-streng. De fire sifrene i pvv (fra venstre til høyre) tilsvarer de første fire desimaler (fra venstre til høyre) av produksjonen fra DES når betraktes som en 16 heksadesimale tegn (16 x 4 bit = 64 bit) streng. Hvis det ikke er fire desimaler blant de 16 heksadesimale tegn deretter pvv er fullført tatt (fra venstre til høyre) ikke desimal tegn og decimalizing dem ved hjelp av konvertering A-> 0, B-> 1, C-> 2, D -> 3, E-> 4, F-> 5. Her er et eksempel:
Produksjonen fra DES: 0FAB9CDEFFE7DCBA
Pvv: 0975
Strategien for å unngå decimalization ved å hoppe tegn til fire desimaler er funnet (som tilfeldigvis være nesten alle ganger som vi vil se nedenfor) er veldig smart fordi den unngår en viktig skjevhet i fordelingen av tall som har vist seg å være fatalt for andre systemer, selv om effekten på dette systemet vil være mye lavere. Se også et relatert problem ikke er knyttet til VISA pvv.
The TSP, oppfattes som en 16 heksadesimale tegn (64 biter) streng, er dannet (fra venstre til høyre) med 11 høyre sifrene i PAN (kortnummer) unntatt det siste sifferet (sjekk tall), ett siffer fra 1 til 6 som velger hemmelig nøkkel kryptering og til slutt de fire sifrene i PIN-koden. Her er et eksempel:
PAN: 1234 5678 9012 3445
Key selector: 1
PIN: 2468
TSP: 5678901234412468
Tydeligvis problemet med å bryte VISA PIN-koden består i å finne den hemmelige nøkkelen for å kryptere DES. Metoden for dette er å gjøre et "brute force" søk på nøkkelen plass. Merk at dette ikke er den eneste metoden, man kunne prøve å finne en svakhet i DEA, mange prøvde, men denne gamle standarden er fortsatt på bred bruk (nå blitt erstattet av AES og RSA, men). Dette viser at det er robust nok til at "brute force" er den eneste levedyktige metoden (det finnes noen bedre angrep, men ikke praktisk i vårt tilfelle, for en oversikt se LASEC memo og for det skitne detaljer se Biham & Shamir 1990, Biham & Shamir 1991, Matsui 1993, Biham & Biryukov 1994 og Heys 2001).
Nøkkelen selector sifret var svært sannsynlig innført for å dekke muligheten for en nøkkel kompromiss. I så fall er de bare nødt til å utstede nye kort ved å bruke en annen tast selector. Eldre kort kan erstattes med nye, eller bare minibanken kan transparent skrive en ny pvv (tilsvarende den nye nøkkelen og beholde den samme PIN-kode) neste gang kunden bruker hans / hennes kort. For riste av sikkerhet alle brukere bør bli bedt om å endre sin PIN-koder, men det ville være pinlig for banken å forklare, og derfor svært sannsynlig at de ville ikke gjøre slik forespørsel.
Forbereder angrep
En "brute force-angrep består i å kryptere en TSP med kjente pvv bruke all mulig å kryptere nøkler og sammenligne hvert fått pvv med kjente pvv. Når en kamp er funnet vi har en kandidat tasten. Men hvor mange nøkler vi har til å prøve? Som vi sa over tasten er 64 bit lang, vil det vi har å prøve 2 ^ 64 nøkler. Men dette er ikke sant. Faktisk bare 56 biter er effektive i DES-nøkler, fordi én bit (minst signifikante) ut av hver oktett var historisk forbeholdt en kontrollsum for andre, i praksis de 8 biter (ett for hvert av de 8 octets) blir oversett.
Derfor DES nøkkelen plass består av 2 ^ 56 nøkler. Hvis vi prøver alle disse tastene, vil vi finne én og bare én kamp, tilsvarende banken hemmelig nøkkel? Absolutt ikke. Vi vil få mange matchende taster. Dette er fordi pvv er bare en liten del (en firedel) av DES-utgang. Videre er det pvv er degenerated fordi noen av sifrene (de mellom 0 og 5 etter det siste, sett fra venstre til høyre, siffer mellom 6 og 9) kan komme fra en desimal siffer eller fra en decimalized heksadesimale siffer av DES-utgang. Dermed mange nøkler vil gi en DES-utgang som gir de samme matchende pvv.
Så hva kan vi gjøre for å finne den virkelige nøkkelen blant de andre falske nøklene? Bare vi har til å kryptere et andre forskjellige TSP, også med kjente pvv, men ved hjelp av kun kandidat nøkler som ga en positiv samsvarer med det første TSP-pvv paret. Imidlertid er det ingen garanti vil vi ikke få igjen for mange falske positiver sammen med den virkelige nøkkelen. Hvis det er slik, trenger vi en tredje TSP-pvv pair, gjentar du prosessen og så videre.
Før vi starter våre angrep må vi vite hvor mange TSP-pvv parene vi trenger. For at vi må beregne sannsynligheten for at en tilfeldig DES utgang for å gi en målrettet pvv bare ved en tilfeldighet. Det er flere måter å beregne dette tallet, og her vil jeg bruke en enkel tilnærming lett å forstå, men som krever noe bakgrunn i matematikk av sannsynlighet.
En sannsynlighet kan alltid bli sett på som forholdet mellom gunstige tilfeller til mulige tilfeller. I vårt problem antall mulige tilfeller er gitt av Permutasjon av 16 elementer (0 til F heksadesimale siffer) i en gruppe på 16 av dem (16 heksadesimale sifre av DES output). Dette er gitt ved 16 ^ 16 ~ 1,8 * 10 ^ 19, som selvfølgelig faller sammen med 2 ^ 64 (forskjellige tall for 64 biter). Dette settet med tall kan være delt opp i fem kategorier:
De med minst fire desimaler (0 til 9) blant de 16 heksadesimale siffer (0 til F) av DES-utgang.
De med nøyaktig bare tre desimaler.
De med nøyaktig bare to desimaler.
De med nøyaktig bare én desimal siffer.
De uten desimaler (alt mellom A og F).
La oss regne ut hvor mange tall faller i hver kategori. Hvis vi markere 16 heksadesimale sifre av DES-utgang som X1 til x16 så vi kan merke de første fire desimaler av et gitt antall den første kategorien som Xi, XJ, Xk og XL. Antall ulike kombinasjoner med denne profilen er gitt ved produktet 6 i-1 * 10 * 6j-i-1 * 10 * 6k-j-1 * 10 * 6 Luk-1 * 10 * 1616-l hvor 6 ' er kommet fra flere muligheter for en A til F siffer, de 10 er kommet fra mulighetene for en 0 til 9 siffer, og 16 kommer fra mulighetene for en 0 til F siffer. Nå er det totale antallet i den første kategorien er bare gitt av summering av dette produktet over i, j, k, l fra 1 til 16, men med i <j <k <l. Hvis du gjør noen matematiske arbeider du vil se denne lik til produktet av 104 / 6 med summering over i fra 4 til 16 av (i-1) * (i-2) * (i-3) * 6i-4 * 16 16-i ~ 1,8 * 1019.
Analogously antall tilfeller i den andre kategorien er gitt av summering over i, j, k fra 1 til 16 med i <j <k av produktet 6i-1 * 10 * 6j-i-1 * 10 * 6k-j -1 * 10 * 616-k som du kan arbeide det ut til å være 16! / (3! * (16-13)!) * 103 * 6 13 = 16 * 15 * 14 / (3 * 2) * 103 * 613 = 56 * 104 * 613 ~ 7,3 * 1015. Tilsvarende for tredje kategorien vi har summering over i, j fra 1 til 16 med i <j av 6 i-1 * 10 * 6j-i-1 * 10 * 616-j som tilsvarer til 16! / (2! * (16-14)!) * 102 * 614 = 2 * 103 * 615 ~ 9,4 * 1014. Igjen, for fjerde kategori har vi en summering over i fra 1 til 16 av 6i-1 * 10 * 616-i = 160 * 615 ~ 7,5 * 1013. Og til slutt mengden av saker i den femte kategorien er gitt av Permutasjon av seks elementer (A til F siffer) i en gruppe på 16, det vil si 616 ~ 2,8 * 1012.
Jeg håper du fulgt beregninger opp til dette punktet, den harde delen er ferdig. Nå som et bevis på at alt er rett, kan du summen av antall tilfeller i 5 kategorier, og se det tilsvarer det totale antallet mulige tilfeller vi beregnet før. Gjøre operasjoner ved hjelp av 64 biters tall eller avrunding (for svever) eller overflow (for heltall) feilene vil ikke la deg få nøyaktig resultat.
Fram til nå har vi beregnet antall mulige tilfeller i hver av fem kategorier, men vi er interessert i å skaffe det antall gunstige tilfeller i stedet. Det er veldig lett å avlede den sistnevnte fra den tidligere så dette er bare oppussing av kombinasjonen av de fire desimaler (eller de nødvendige heksadesimaltall hvis det ikke er fire desimaler) av pvv stedet for å la dem gratis. I praksis betyr dette å snu 10 står i formelen ovenfor i 1 og den nødvendige mengden 6 står i 1's hvis det ikke er fire desimaler. Det er vi nødt til å dele det første resultatet av 104, den andre ved 103 * 6, den tredje ved 102 * 62, den fjerde en av 10 * 63 og den femte av 64. Da antall gunstige tilfeller i de fem kategoriene er omtrent 1,8 * 1015, 1,2 * 1012, 2,6 * 1011, 3,5 * 1010, 2,2 * 109 hhv.
Nå har vi muligheten til å få tak i hva som er sannsynligheten for et DES utgang for å matche en pvv ved en tilfeldighet. Vi må bare legge til de fem numre av gode saker og dele den med det totale antall mulige tilfeller. Gjøre dette får vi at sannsynligheten er svært ca 0,0001 eller én av ti tusen. Er det rart dette godt avrundet resultat? Ikke i det hele tatt, bare ta en titt på tallene vi beregnet ovenfor. Den første kategorien dominerer ved flere bestillinger i størrelsesorden antall gunstige og mulige tilfeller. Dette er ganske intuitivt som synes det klart at det er svært lite sannsynlig ikke å ha fire desimaler (10 sjansene ut av 16 per siffer) blant 16 heksadesimale sifre. Vi så tidligere at forholdet mellom antall mulige og gode saker i den første kategorien var en divisjon med 10 ^ 4, det er der vårt resultat p = 0,0001 kommer fra.
Vår målsetting for alle disse beregningene var å finne ut hvor mange TSP-pvv parene vi trenger for å drive en vellykket "brute force-angrep. Nå er vi i stand til å beregne den forventede antall falske positiver i en første søket: det vil være det antall ganger sannsynligheten for at en enkelt tilfeldig falske positive, dvs. t * p der t = 2 ^ 56, størrelsen på nøkkelen plass. Dette beløper seg til ca 7,2 * 10 ^ 12, en ganske stor tall. Den forventede antall falske positiver i andre søk (begrenset til den positive nøkler funnet i den første søk) vil være (t * p) * p, for en tredje søk blir ((t * p) * p) * p og så videre. Dermed for n søker den forventede antall falske positiver blir t * p ^ n.
Vi kan skaffe det antall søk som kreves for å forvente at bare en falsk positiv ved uttrykker ligningen t * p ^ n = 1 og løse for n. Så n lik til logaritmen i basen p av 1 / t, som ved egenskapene til logaritmer gir n = log (1 / t) / log (p) ~ 4,2. Siden vi ikke kan gjøre en brøk-søk er det greit å runde opp dette antallet. Derfor hva er forventet antall falske positiver om vi utfører fem søk? Det er ikke * p ^ 5 ~ 0,0007 eller ca 1 av 1400. Således bruker fem TSP-pvv parene er trygt å få oppfylt hemmelig nøkkel med ingen falske positiver.
Angrepet
Når vi vet at vi trenger fem TSP-pvv parene, hvordan får vi dem? Selvfølgelig må vi ha minst ett kort med kjent PIN, og på grunn av beskaffenheten til pvv algoritmen, som er det eneste vi trenger. Med andre PIN-systemer, for eksempel IBM, og vi ville trenge fem kort, men dette er ikke nødvendig med VISA pvv algoritme. Vi må bare lese den magnetiske stripen og deretter endre PIN-fire ganger, men leser kortet etter hver endring.
Det er nødvendig å lese magnetisk stripe av kortet for å få pvv og kryptere nøkkelen selector. Du kan kjøpe en kommersiell magnetisk stripe reader eller lage en selv følge instruksjonene finner du i den forrige siden og koblinger der. Når du har en leser se denne beskrivelsen av standard magnetiske spor for å finne ut hvordan du får pvv fra data leses. I dette dokumentet den pvv feltet i spor 1 og 2 sies å være fem tegn lang, men faktisk sant pvv består av de fire siste sifrene. Den første av de fem sifrene er nøkkelen selector. Jeg har bare sett kort med en verdi på 1 i dette tallet, som er i overensstemmelse med standarden og med den hemmelige nøkkelen aldri blir kompromittert (og derfor er de ikke trenger å flytte til en annen viktig endring velgeren).
Jeg gjorde en enkel C-program getpvvkey.c, for å utføre angrepet. Det består av en loop til å prøve alle mulige nøkler for å kryptere den første TSP, hvis utledet pvv matcher den sanne pvv en ny TSP er prøvd, og så videre, helt til det er en mismatch, hvor nøkkelen er forkastet, og en ny er forsøkt, eller de fem utledet PVVs samsvarer med tilsvarende sant PVVs, og da kan vi anta at vi fikk banken hemmelig nøkkel, men loop går videre til den opp nøkkelen plass. Dette er gjort for å forsikre seg om vi finner den virkelige nøkkelen fordi det er en sjanse (men svært lav) den første nøkkelen funnet er en falsk positiv.
Det er ventet at programmet vil ta svært lang tid å fullføre og å minimere risikoen for en strøm kuttes, maskinen henger seg, osv. det gjør sjekkpunkter i filen getpvvkey.dat fra tid til annen (det nøyaktige tidspunktet avhenger av hastighet av datamaskin, er det rundt en time for de raskeste datamaskiner som nå er i bruk). Av samme grunn dersom en positiv nøkkelen er funnet som den er skrevet på filen getpvvkey.key. Programmet viser bare én melding ved inngangen, startpunktet posisjon hentet fra Checkpoint fil hvis noen, etter at noe mer blir vist.
The DES-algoritmen er et sentralt punkt i programmet, er det derfor svært viktig for å optimalisere hastighet. Jeg testet flere implementasjoner: libdes, SSLeay, openssl, cryptlib, NSS, libgcrypt, catacomb, libtomcrypt, cryptopp, UFC-krypten. The DES funksjoner av de fire første er basert på samme kode av Eric Young, og er den som ga best resultat (inkluderer optimalisert C og x86 monterer code). Derfor jeg valgte libdes som var den opprinnelige gjennomføring og kondensert alle relevante koden i filene encrypt.c (C-versjon) og x86encrypt.s (x86 monterer versjon). Koden er litt endret for å oppnå noen forbedringer i et "brute force-angrep: de første Permutasjon er en fast felles bratt i hvert TSP kryptering, og kan derfor bli gjort bare én gang på begynnelsen. En annen forbedring er at jeg skrev en helt ny setkey funksjon (jeg kalte det nextkey) som er optimalt for et "brute force" loop.
For å få programmet arbeider du bare å skrive inn i de tilsvarende plass fem TSPs og deres PVVs og deretter kompilere den. Jeg har testet det bare i UNIX-plattformer ved hjelp av Makefile Makegetpvvkey for å kompilere (bruk kommandoen "make-f Makegetpvvkey"). Det kan kompilere på andre systemer, men du må kanskje fikse noen ting. Være sikker på at definisjonen av type long64 tilsvarer et 64 bits heltall. I prinsippet er det ingen avhengighet på endianness av prosessoren. Jeg har blitt utarbeidet og kjøre den på Pentium-Linux, Alpha-Tru64, MIPS-Irix og SPARC-Solaris. Hvis du ikke har og ikke ønsker å installere Linux (du vet ikke hva du mangler ;-) du har fortsatt mulighet til å kjøre Linux på CD og bruke programmet, se siden min å kjøre Linux uten å installere den.
Når du har funnet den hemmelige bank-tasten hvis du vil finne PIN for et vilkårlig kort du bare nødt til å skrive et lignende program (Beklager at jeg ikke har skrevet det, jeg er for lat:) som ville prøve alt 10 ^ 4 PIN-koder ved å generere tilsvarende TSP, og krypterer den med (ikke lenger) hemmelig nøkkel, deriving den pvv og sammenligne den med pvv i magnetisk stripe av kortet. Du vil få en kamp for den sanne PIN. Bare én match? Husk hva vi så ovenfor, har vi en sjanse til 0,0001 at en tilfeldig kryptering matcher pvv. Vi prøver 10000 PIN-koder (og dermed TSPs) og dermed forventer vi 10000 * 0,0001 = 1 falsk positiv i gjennomsnitt.
Dette er et meget interessant resultat, betyr det at det i gjennomsnitt hvert kort har to gyldig PIN-koder: kunden PIN og forventet falske positive. Jeg kaller det "falske", men merk at så lenge den genererer den sanne pvv det er en PIN-kode som gyldig som kunde er én. Videre er det ingen måte å vite noe som er der, selv for minibanken; eneste kunde kjenner. Selv om de falske positive ble ikke gyldig som PIN, vil du fortsatt ha tre utprøvinger i minibank uansett nok i gjennomsnitt. Derfor sannsynligheten vi beregnet ved begynnelsen av dette dokumentet om tilfeldige gjettet av PIN-kode har til å bli korrigert. Egentlig er det to ganger denne verdien, dvs. det er 0,0006 eller en av mer enn 1600, fortsatt trygt lav.
Resultater
Det er viktig å optimalisere kompilering av programmet og kjøre det i den raskeste prosessoren på grunn av lang forventet kjøre tid. Jeg fant ut at kompilatoren optimalisering flagg-O får bedre ytelse, trodde noen bedring er oppnådd å legge til-fomit-ramme-pekeren flagget på Pentium-Linux, de-spiss flagget på Alpha-Tru64, den IPA-flagget på MIPS-Irix og-rask-flagget på SPARC-Solaris. Spesielle flagg (-DDES_PTR-DDES_RISC1-DDES_RISC2-DDES_UNROLL-DASM) for DES-koden generelt har fordeler også. Alle disse flaggene har allerede blitt testet og jeg valgte den beste kombinasjonen for hver prosessor (se Makefile), men du kan prøve å fine tune andre flagg.
Ifølge mine tester de beste resultatene er oppnådd med AMD Athlon 1600 MHz prosessor, som overstiger 3,4 millioner nøkler per sekund. Interessant det blir bedre resultater enn Intel Pentium IV 1800 MHz og 2000 MHz (se figur nedenfor, klikke på dem for større versjon). Jeg mener at dette skyldes enkelte I / O-metning, sikkert hurtigbuffer eller minnekortet, at AMD-prosessor (som har en halv buffer av Pentium) eller hovedkortet som det er i drift, klarer å unngå. I den første figuren nedenfor kan du se at DES bryte hastighet på alle prosessorer har mer eller mindre en lineær relasjon med prosessor hastighet, unntatt for de to Intel Pentium jeg nevnt før. Dette er logisk, det betyr at for en dobbelt prosessor hastighet får du dobbelt bryte fart, men pass på metning effekter, i dette tilfellet er det bedre for AMD Athlon 1600 MHz, noe som vil bli enda billigere enn Intel Pentium 1800 MHz eller 2000 MHz.
I den andre figuren ser vi i mer detalj hva vi ville kalle egenverdi DES bryte strømmen til prosessoren. Jeg får denne verdien bare dele bryte hastighet av prosessor hastighet, som er, får vi antall DES-nøkler prøvde per sekund og per MHz. Dette er et mål på ytelsen til prosessoren skriver uavhengig av dens hastighet. Resultatene viser at den beste prosessor for denne oppgaven er AMD Athlon, deretter kommer det alfa og svært tett etter at den er Intel Pentium (unntatt for høyere hastighet de som utfører svært dårlig på grunn av metning i kraft). Neste er MIPS-prosessoren og i den siste plassen er SPARC. Noen Alpha og MIPS-prosessorer er plassert nederst på skalaen fordi de tidlige utgivelsene ikke inkludert ekstrautstyr for sent versjoner. Merk at jeg inkluderte resultatene av x86-prosessorer for C og monterer koden så er det en stor forskjell. Det synes som gcc er ikke en god generator av optimalisert maskin kode, men selvfølgelig vet vi ikke om en manuell optimalisering av monterer koden for andre prosessorer (Alpha, MIPS, SPARC) ville øke sine resultater i forhold til de opprinnelige C-kompilatorer (Det gjorde jeg ikke bruke gcc for disse andre plattformer) som det skjer med x86-prosessor.
Oppdatering
Her er en artikkel hvor disse teknikkene kan ha blitt brukt.
http://redtape.msnbc.com/2008/08/could-a-hacker.html
