속닥속닥

Flashback을 지원하지 않는 메인보드를 수리했던 경험을 공유한다.

BIOS Flashback 기능 없이 BIOS가 망가졌을 때(BIOS Corrupted)는 어떻게 수리할까?

보통 시중에 판매하는 5천원짜리 롬 찝개(?)와 CH341A 프로그래머, 더 필요하다면 3.3V to 1.8V 레귤레이터만 있으면 가능하다.

근데 문제는 요즘 ITX 보드가 작은 곳에 왕창 뭔가를 다 때려박는 것에 모자라 PCI-E 걸쇠 밑에 BIOS IC를 넣어버린다.... ㅡㅡ

그럼 롬 찝개가 들어갈 공간도 안나오고, 걸쇠를 썰어버리자니 아깝고, 미치고 팔짝 뛸 노릇이다.

(이런 보드는 업체 들고 가도 환대받지는 못한다.. 열풍기를 쏴서 떼자니 플라스틱 걸쇠가 녹는다.)

그래서 생각해 낸 것은 Intel PCH의 SPI 인터페이스를 활용하는 방법이다.

OC3D에 게재된 그림을 들고와봤다. 밑에 보면 PCH가 SPI 인터페이스를 통해 TPM과 Flash를 연결하는 것을 볼 수 있다.

바로 MSI 홈페이지에 pdf를 하나 보고 JSPI1 port pinout과 롬라이터 pinout을 매치시켜줬다.

문제는 CS 부분에 FET가 있어 Chip이 select 되었다는 것을 알려줘야 했는데, 이건 쉽게 그냥 벌서는 것 처럼 칩에 직접 핀을 그대로 매치 시키니 인식에도 별 문제가 없었다. ㅎㅎ

인식시키고 나니 실제 플래시 시간은 4분 40초대면 모두 다 쓸 수 있었다. 확실히 프로그래머가 저속 I/O를 사용하고 있기 때문인지 Flashback이나 BIOS Flash 유틸보다 훨 느렸다.

결론은 성공이다. 작동에 전혀 지장없고 잘 돌아준다.

nugu candle의 하드웨어 스펙이다.

분석에 앞서 펌웨어 취득을 위해 adb 및 root permission이 enabled된 recovery image를 fastboot로 live upload하려 했지만...

zimage magic error로 aarch64, arm, armhf 이미지 모두 업로드 실패하고 뱉어서 포기했다.

AI스피커 대상 UART 포트가 대부분 살아 있는 특징을 이용해보았다.

기가지니나 누구는 외형으로 드러나 있고 클로바와 카카오는 네이밍이 따로 되어있지 않아 찾아야 한다ㅜㅜ

uboot의 mmc 명령어를 활용하면 파티션 테이블을 활용한 파티션 레이아웃을 얻을 수 있다.

---

ESPRESSO7570 # mmc part

Partition Map for MMC device 0  --   Partition Type: EFI

Part    Start LBA       End LBA         Partition_Size(MB)      Name

        Attributes

        Type GUID

        Partition GUID

  1     0x              22      0x           32021      100     "fat"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   a2a0d0eb-e5b9-3344-87c0-68b6b72699c7

  2     0x           32022      0x          226021      1000    "system"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   af3dc60f-8384-7247-8e79-3d69d8477de4

  3     0x          226022      0x          514001      1501    "userdata"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   af3dc60f-8384-7247-8e79-3d69d8477de4

  4     0x          514022      0x          640021      600     "cache"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   af3dc60f-8384-7247-8e79-3d69d8477de4

  5     0x          640022      0x          672021      100     "modem"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   af3dc60f-8384-7247-8e79-3d69d8477de4

  6     0x          672022      0x          67c021      20      "efs"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   af3dc60f-8384-7247-8e79-3d69d8477de4

  7     0x          67c022      0x          6ae021      100     "recovery"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   af3dc60f-8384-7247-8e79-3d69d8477de4

  8     0x          6ae022      0x          6e0021      100     "misc"

        attrs:  0x0000000000000000

        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

        guid:   af3dc60f-8384-7247-8e79-3d69d8477de4

Total partition size     : 3729 MB

Available capacity       : 208 MB

숨겨진 파티션의 경우 이미지 자체에 하드코딩 되어 있어서 펌웨어를 뜯기 전에는 모른다.

uboot에서 fastboot 돌리면 파티션정보가 주르륵 튀어나오긴 한다. 오프셋이 없어서 그렇지ㅜㅜ

펌웨어 취득은 uboot의 mmc dump x y를 통해서 진행할 수 있는데 uart로 4gb 뽑아 내는 데에 상당한 시간이 소요된다 ㅜㅜ

115200baud인데도 start/stop비트 + ascii 전달 + space 값 + offset 필드 때문에 실질적으로 4kbps정도밖에 안나오기 때문이다.

도구 만들어서 뽑았다. FTDI로 넉넉잡아 21일 정도 걸렸던걸로...

---

기기가 한대 더 생겨서...

신기하게 이 친구는 실드가 따로 없다. 보통은 차폐랑 열때문에 실드가 있던데 말이다.

chip-off하면 붙히기 어려울수 있으니 어찌저찌 와이어링 해보고 싶었으나... 실패해서 그냥 chip-off로 이미지 획득했다.

crc 떠보니 uart를 통한 dump값은 서로 동일하다.

GUID partition table에 기술된 파티션 목록이다.

일반적인 android 파티션과 동일하다.

self-signed ca 넣어서 덮어봤는데 자꾸 벽돌이 되길래...

순정 이미지를 fastboot로 밀어넣어도 벽돌이 되는 기이한 현상을 보았다 ㅜㅜ

벽돌은 아예 안켜지는게 아니라 bootup은 되는데 shell에서 hang이 걸리는 현상이다. (surfaceflinger segfault)

logcat이랑 dmesg찍어보니 system파티션 라이브러리에서 심볼을 못찾는다고 한다.

근데 심지어 찾는 심볼이 있는 파일은 문제가 없는 기기에도 없다 (?!)

* 이때 첨 알았는데 요 제품은 root permission이 기본이다.

nu110****이라고 디바이스 컨트롤(fastboot bootup, led 제어 등)하는 바이너리가 있는데 요놈이 루트를 요구한다 ㅡ.ㅡ

그래서 아예 새제품 뜯어서 바로 chip-off하고 죽은 기기 낸드에 펌웨어 덮어씌우고 rework해보았는데 잘 된다.

뭔가 exynos7570에 탑재된 fastboot가 내가 아는 fastboot가 아닌거 같다고 할 정도로ㅜㅜ

fastboot 켜고 erase -> flash 도 해보고 format -> flash 도 해보았지만 음.. 여전히 똑같은 결과...

시간이 없어서 chip-off하고 데이터 넣은 담에 볼납가지고 rework 했다.

CA injection하고 떠보니 네이버 클로바 인젝션 할 때와 똑같은 현상이다.

certification pinning 때문에 ssl encryption된게 보이지 않는 모양이다.

롬을 뜯어보고 싶긴 한데 요놈 분석은 이정도로 마무리지으려 한다. 머리가 아파오는 기기야...