TL;DR

  • M-Vave FM-1의 패키지·SPL·SDK 출처 분석 결과, 대상은 pi32v2 CPU와 0x02000000 XIP 플래시를 사용하는 JieLi AC791N/WL82이며, Dexed/msfa 파생 6오퍼레이터 FM 엔진을 탑재한 것으로 식별됨.
  • 펌웨어에 포함된 JL-BR22 문자열은 상속된 라이브러리 명칭이며, SoC 식별의 신뢰할 만한 근거가 아님.
  • 현재 기본 브랜치에는 대체 펌웨어나 사용자 지정 이미지 빌더가 없으며, 이전 실험 구현은 with-custom-firmware 브랜치에 보존됨.
  • USB-MIDI 업데이트 프레이밍, 세션 흐름, 로더 동작과 업데이트 경로의 미확인 게이트를 분석했으나, 해당 프로토콜은 입증된 복구 수단이 아님.
  • 단일 뱅크 구성에서 ROM 복구, 롤백, 안전한 쓰기 중단 동작이 확인되지 않았으므로 업데이트 또는 플래시 도구 사용 전 TODO_aug2.md를 확인해야 함.

펌웨어 역공학 분석

  • M-Vave FM-1 신시사이저의 펌웨어 역공학 및 업데이트 프로토콜을 조사함.
  • 패키지, SPL, SDK 출처를 통해 대상 하드웨어를 pi32v2 CPU를 사용하는 JieLi AC791N/WL82로 식별함.
  • XIP 플래시는 0x02000000에 있으며, FM 엔진은 Dexed/msfa 파생 6오퍼레이터 방식임.
  • 내장된 JL-BR22 문자열은 상속된 라이브러리 명칭으로, SoC를 식별하는 신뢰할 만한 표식이 아님.
  • 기본 브랜치에는 대체 펌웨어나 사용자 지정 이미지 빌더가 의도적으로 포함되지 않음. 이전 실험 구현은 with-custom-firmware 브랜치에서 확인 가능함.

시작 안내

  • 하드웨어 매핑, 부트 체인, 메모리 레이아웃, 주요 하위 시스템은 아키텍처 개요에서 확인 가능함.
  • 캡처한 USB-MIDI 프레이밍, 세션 흐름, 로더 동작, 미해결 게이트는 OTA 프로토콜 문서에서 다룸.
  • 복구 가능한 업데이트 경로로 간주하기 전에 필요한 증거는 안전성 평가와 미해결 질문 문서에 정리됨.
  • 콘솔, 공장 모드, 테스트 명령, 복구 진입점을 정적으로 검색한 결과는 디버그 표면 감사 문서에 있음.
  • OTA 로더 추출, 제어 흐름, 플래시 게이트, 종료 핸드셰이크 추적은 장치 OTA 로더 및 완료 게이트 분석에서 다룸.
  • M-UPGRADE 상태 머신 디컴파일과 장치 식별자 파싱은 Windows 업데이터 분석에 포함됨.
  • Linux 프로토콜 클라이언트, 도구 참고 사항, 오프라인 테스트도 제공됨.

저장소 구성

  • analysis/: V13 디스어셈블리, 바이트 단위로 동일한 재조립 결과, 함수 데이터베이스, 분류 정보, OTA 로더 분석, 호스트 업데이터 디컴파일 자료.
  • docs/: 펌웨어 특성 분석, 아키텍처, 하위 시스템 분석, 함수 색인, OTA 조사 결과.
  • scripts/: 디스어셈블리, 추출, 색인, 분류 파이프라인.
  • tools/: USB-MIDI 업데이트 프로토콜 클라이언트와 오프라인 테스트.
  • ghidra/scripts/: 저장소에 포함된 pi32v2 헤드리스 분석 스크립트.
  • firmware-images/: 변경 불가 상태로 보관되는 V13·V14 패키지와 압축 해제 입력 자료.
  • reference/: scripts/setup_reference.sh로 채워지는 무시 대상 SDK, Ghidra 설치 파일, 업스트림 소스 미러.
  • 3rd-party/jl-misctools 및 3rd-party/jl-uboot-tool: 펌웨어 파싱과 부트 도구 참고에 사용되는 고정 서브모듈.
  • 저장소에는 서로 독립적으로 개발된 V13 분석 파이프라인 두 개가 유지됨. 각 파이프라인의 역할은 analysis/README.md에 설명됨.
  • 현재 분류 결과는 analysis/db.json과 docs/function-index.md에 있으며, 독립적인 교차 검증과 출처 확인에는 analysis/function_db.json과 analysis/master_index.json을 제공함.

재현 방법

  • 모든 명령은 저장소 루트에서 실행함.
  • 저수준 디스어셈블리와 독립 함수 맵 생성에는 scripts/run_ghidra.sh, scripts/build_funcdb.py, scripts/resolve_strings.py, scripts/match_libs.py, scripts/build_master_index.py, scripts/build_slices.py를 차례로 사용함.
  • OTA 로더를 추출하고 벤더 맵을 생성하며 이를 뒷받침하는 Ghidra 분석을 수행하려면 scripts/analyze_ota_loader.sh와 scripts/run_ghidra_loader.sh를 사용함.
  • 현재의 보강 분류 데이터베이스와 문서를 생성하려면 scripts/build_db.py, scripts/disasm_toolchain_libs.sh, scripts/match_libs.py, scripts/mech_tag.py, scripts/export_shards.py, scripts/aggregate.py를 실행함.
  • 오프라인 OTA 프로토콜 검사는 python3 -m unittest discover -s tools/tests -v로 실행함.

안전성 현황

  • 업데이트 프로토콜은 복구 수단으로 입증되지 않음.
  • 현재까지 단일 뱅크 구성에서 ROM 복구, 롤백, 쓰기 도중 안전하게 중단되는 동작을 확인하지 못함.
  • analysis/device/debug-surfaces.md의 콘솔·공장 모드 감사에서는 대체 복구 진입점을 찾지 못함.
  • 업데이트 또는 플래시 유틸리티를 사용하기 전에 TODO_aug2.md를 확인해야 함.

외부 참고 자료

  • USB_KEY | jielie: D+/D- 신호를 이용해 JieLi USB 부팅을 호출하는 방법에 관한 역공학 메모로, 키 파형, 응답, 타이밍, USB 버스 관련 주의 사항을 다룸.
  • JL SoC forum thread: JieLi SoC, SDK, 툴체인, 프로그래머, 부트 활성화 장치, USB/ISP/UART 키 실험을 다루는 장기간의 러시아어 커뮤니티 토론임. 보고 내용은 커뮤니티 관찰이며 논의 대상 칩 계열에만 적용될 수 있음.
  • SMK-37 Pro community notes: 패키징, 업데이트, 하드웨어 관례의 공통점을 식별하는 데 참고할 수 있는 관련 M-Vave/JieLi 키보드 관찰 자료임.
  • kagaimiq/jl-misctools (3rd-party/jl-misctools, ../jl-misctools에도 체크아웃됨): JieLi 펌웨어 컨테이너, 키 파일, UI 리소스, 구형 형식 처리를 위한 유틸리티임.
  • kagaimiq/jl-uboot-tool (3rd-party/jl-uboot-tool): UBOOT 장치 검색, RAM 코드 로드, 플래시 읽기·쓰기·삭제를 위한 Python 도구임. 지원 표에서 WL82/AC791N은 미확인 상태이므로 FM-1용 플래셔로 입증된 도구가 아님.
  • Jieli-Tech/fw-AC79_AIoT_SDK (../fw-AC79_AIoT_SDK): 주변 장치 및 MaskROM API 헤더, 부트·업데이트 설정, 라이브러리, 빌드 도구, 애플리케이션 예제를 포함하는 공식 AC791N/WL82 SDK이며, 기본 펌웨어 동작 식별에 사용됨.