SGI O2 PROM 펌웨어 리버스 엔지니어링: 900MHz CPU 업그레이드를 향한 여정

SGI O2 PROM 리버스 엔지니어링: CPU 업그레이드를 위한 펌웨어 해부기

• Silicon Graphics O2는 MIPS CPU를 탑재한 유닉스 워크스테이션으로, 2000년대 초반부터 커뮤니티에서 CPU 업그레이드를 시도해왔음
• RM5200(300MHz), RM7000A(350MHz)를 600MHz RM7000C로 교체하는 것은 펌웨어 수정 없이 가능했으나, 900MHz RM7900 업그레이드는 PROM 펌웨어 수정이 필수적이었음
• 당시 SGI에 소스코드 접근을 요청할 수 있었으나, SGI가 사라진 지금은 소스코드도 함께 소실된 상태임
• 저자는 ip32prom-decompiler를 직접 제작해 512KiB PROM 바이너리를 수정 가능한 어셈블리(.S) 파일로 역컴파일하는 데 성공함
• 역컴파일된 어셈블리를 재조립하면 원본과 bit-identical한 이미지가 생성되어, 역컴파일의 정확성이 검증됨

SHDR 구조 발견 과정

• mips64-unknown-linux-gnu-objdump로 바이너리를 디스어셈블한 결과, 오프셋 0x08에서 0x53484452라는 값을 발견했고, 이것이 ASCII "SHDR"임을 strings 명령으로 확인함
• SHDR은 각 섹션의 헤더로, branch+delay slot 패턴으로 경계가 구분되며 총 72바이트 크기임
• 바이너리 내에 5개의 SHDR이 존재: sloader, env, post1, firmware, version

graph TD
    subgraph "PROM 512KiB 바이너리 구조"
        A["sloader
@0x00000000
16,384 bytes
type=1 (code)"]
        B["env
@0x00004000
1,024 bytes
type=0 (data)"]
        C["post1
@0x00004400
19,780 bytes
type=1 (code)"]
        D["firmware
@0x00009200
393,212 bytes
type=3 (code+metadata)"]
        E["version
@0x00069200
904 bytes
type=0 (ELF)"]
    end
    A --> B --> C --> D --> E

SHDR 필드 구조

• [0x00-0x08): 엔트리 명령어 — 코드 섹션은 branch로 SHDR을 건너뛰고, 데이터 섹션은 nop
• [0x08-0x0C): 매직 넘버 "SHDR"
• [0x0C-0x10): 섹션 길이 (다음 SHDR 오프셋 계산에 사용, 256바이트 경계로 라운드업)
• [0x10-0x12): name 길이 + version 길이 (각 1바이트)
• [0x12-0x13): 섹션 타입 — bit 0이 코드 여부, bit 1이 메타데이터 존재 여부를 나타냄
• [0x14-0x34): 섹션 이름 (32바이트 고정), [0x34-0x3C): 버전 문자열 (8바이트 고정)
• [0x3C-0x40): SHDR 체크섬, [0x40-0x48): 메타데이터 (타입에 따라 존재 유무 결정)

코드 식별: BFS 기반 접근

• Capstone 디스어셈블러를 활용해 branch 타겟을 따라가는 BFS(너비 우선 탐색)로 코드를 자동 식별함
• 초기에는 전체의 약 10%만 코드로 식별되었는데, jal 명령어의 점프 타겟 계산 방식을 이해하지 못했기 때문임
• MIPS에서 리셋 후 실행은 0xBFC00000부터 시작됨 — --adjust-vma=0xbfc00000 플래그 적용 후 jal 타겟이 정상적으로 해석됨
• 점프 테이블이나 런타임에 주소를 조립하는 함수, dead code 등은 자동 발견이 불가능해 functions.json에 수동 어노테이션으로 보완함

바이너리 시각화의 위력

• XPM 포맷으로 바이너리 구조를 이미지로 시각화함: 빨강=코드, 파랑=헤더/체크섬, 초록=ASCII, 노랑=접근된 메모리, 검정=0x0, 흰색=0xFFFFFFFF, 회색=미식별
• 시각화를 통해 미식별 영역의 존재를 직관적으로 파악할 수 있었고, 진행 상황을 확인하는 동기 부여 수단으로도 유용했음

firmware 섹션의 서브섹션 구조

• firmware 섹션은 PROM의 91%를 차지하며(384KiB/422KiB), 섹션 타입 필드의 bit 1이 설정된 유일한 섹션임
• SHDR 메타데이터의 첫 4바이트 0x81000000이 실행 시 로드 주소였음 — kseg0 영역(캐시 가능, TLB 불필요)의 물리 주소 0x01000000(16MiB)에 해당
• 두 번째 메타데이터 값 0x00048e70은 .text 섹션 길이였고, 각 서브섹션 끝에 (로드 주소, 길이) 쌍이 연결 리스트처럼 이어져 있었음
• 서브섹션은 .text(실행 코드), .rodata(읽기 전용 데이터/문자열/점프 테이블), .data(읽기-쓰기 초기화 데이터)로 구성되며, 길이 0인 센티널 값으로 종료됨
• C로 작성되어 정적 ELF 바이너리로 컴파일된 후, 섹션을 추출해 커스텀 포맷으로 리패킹한 것으로 추정됨

체크섬 알고리즘

• sloader의 is_section_checksum_valid 함수를 분석한 결과, 단순한 2의 보수 체크섬 방식임
• SHDR 이후의 모든 32비트 워드를 더한 값을 부정(negate)하여 저장하면, 체크섬 포함 전체 합이 0이 됨
• SHDR 체크섬도 동일한 방식이며, 유효한 SHDR 체크섬의 기여분은 항상 0이므로 섹션 체크섬 계산 시 SHDR을 건너뛸 수 있음

version 섹션의 정체: ELF 바이너리

• version 섹션의 초기 바이트 0x7F454C46이 ELF 매직 넘버(\x7fELF)임을 뒤늦게 발견함
• ELF 헤더와 SHDR이 오버레이되어 있었음 — e_ident의 패딩 영역에 "SHDR" 매직과 섹션 길이가 들어가 있었고, e_machine(0x08 = EM_MIPS) 필드가 섹션 타입 0에 자연스럽게 대응됨
• 패딩 바이트에 8이 들어있던 것도 ELF 헤더의 e_machine 필드 값이었던 것임

의의와 향후 전망

• 2004년 메일링 리스트에서 "SGI 엔지니어급 실력과 카페인이 필요하다"며 불가능에 가깝다고 평가받았던 작업이 실제로 완수됨
• 1996년산 512KiB 펌웨어의 주된 난이도는 복잡성이 아니라, 무수히 많은 세부 사항을 하나하나 맞추는 인내심이었음
• 이 작업으로 RM7900(900MHz) CPU 지원을 위한 "distinctly modified IP32 PROM image" 생성이 가능해졌으며, SGI의 도움 없이도 O2의 CPU 업그레이드 경로가 열림