Egret GT 전동킥보드 리버싱: USB-C 핀에 숨은 CAN 버스와 Rust 펌웨어 재작성
- Egret GT 전동킥보드의 USB-C 포트 데이터 핀 두 개가 CAN 버스로 쓰이고 있었고, ESP32-C6와 SN65HVD230, MCP2515로 스니퍼를 만들어 부팅 시퀀스 메시지를 기록함
- 디스플레이 유닛 펌웨어를 Rust로 새로 작성했으며, Slint는 빈 UI만 넣어도 플래시 한계를 넘겨서 buoyant를 택함
- 전원을 켤 때 down 버튼을 누르면 펌웨어 업데이트 모드로 진입하고, 그 메뉴에서 나오면 PIN 없이 주행 모드로 들어가는 문제가 있었음
- 스쿠터는 앱이 접속해 설정하기 전까지 VIN을 모르며, 앱은 주행 모드별 시간, 배터리 전압, 충전 이력을 제조사에 전송하는데 앱에는 명시되지 않음
- 독일 StVO 위반 소지가 있으나, 브레이크 레버 센서가 모터 컨트롤러에 직접 연결돼 있어 디스플레이 펌웨어 교체로 안전 기능이 바뀌지는 않음
Hacker News opinions
이런 거 만지는 사람들 진짜 조심해야 함. 거리에서 보면 제한 우회한 킥보드 타는 애들 많은데 결국 다침.
LLM 덕분에 이런 것도 할 수 있게 됐다는 게 좋음. 나도 예전엔 엄두도 못 냈는데.
나도 이번 봄에 전동킥보드 사서 공식 앱이랑 BLE 로그 리버싱해서 앱 직접 만들었음. 펌웨어까지 건드릴 용기는 없더라.
64바이트 청크를 CAN 0x384 프레임 9개로 나눠 보낸다니, 클래식 CAN은 프레임이 8바이트인데 typo 아님? CAN-FD 쓰는 거 아닌가.
ISO-TP 같은 멀티패킷 프레이밍일 거임. 아마 typo일 듯.
나도 하드웨어에 Rust 쓰는 중. 지난주엔 마우스, 이번 주엔 EUC. 메모리 오염보다는 크래시가 낫지.
EUC가 뭐임? 그리고 킥보드 크래시 나는 건 싫은데 ㅋㅋ
Slint 먼저 써봤는데 빈 UI만 넣어도 플래시를 다 먹어서 buoyant로 감. slint는 allocator도 필요함.
브릭 안 나게 어떻게 디버깅했는지 궁금함. SWD 프로브 씀이냐 아니면 그냥 믿음이냐.
처음엔 디스플레이 뜯어서 SWD 프로브 썼음. 주변장치 드라이버 포팅할 때 필요했고, 안정된 뒤에 실물 스쿠터에서 테스트함.
Bosch 같은 데 좀 풀어줘야 함. 오픈소스 라이브러리는 잔뜩 쓰면서 배터리 같은 건 다 막아놔서 서드파티 배터리를 못 씀.
서드파티 부품 쓰면 안전이랑 신뢰성 문제가 진짜 많음. 돈 때문만은 아니고 생태계 만드는 게 폐쇄하는 것보다 훨씬 비쌈. 경쟁 제품이 열려 있으면 그게 차별점이 돼서 시장이 움직임.
이런 거 할 바엔 그냥 하드웨어 케이스 뜯어버리고 아두이노나 SBC로 갈아버리는 게 훨씬 빠르고 덜 지루함.
독일에선 공도에서 쓰려면 인증된 기기여야 함. 사고 나면 보험 적용도 안 되고 상황이 더 나빠질 수 있음.
StVO 위반인 건 맞는데 원래 펌웨어로 되돌릴 수 있음. 브레이크 레버 센서는 모터 컨트롤러에 직접 물려 있고 디스플레이가 스로틀 위치를 계속 보고해야 해서, 디스플레이에 악의적 코드가 없으면 문제 없음.
USB-C 핀을 CAN으로 쓴다니 끔찍함. SBU1, SBU2 같은 전용 핀도 있는데 왜 그랬담.
비용 때문임. 1억 대에 1센트 아끼면 100만 달러니까.