오디오 인터페이스에 기본으로 SSH가 활성화되어 있음

• 펌웨어 파일을 풀어보면 장치 내부 구조를 쉽게 확인할 수 있었고, Rodecaster Duo는 기본 상태에서 SSH가 열려 있음
• 업데이트 패키지는 gzipped tarball 형태였고, 장치에는 손상 시 다른 쪽으로 부팅하는 두 개의 파티션과 업데이트용 셸 스크립트가 들어 있었음
• 들어오는 펌웨어에는 서명 검증이 없었고, 실제 SSH 접속은 Ethernet 연결에서 확인됐으며 pubkey 인증만 허용하는 상태였음
• Windows에서는 USB 업데이트 흐름을 캡처해 M과 U라는 단일 ASCII 명령으로 업데이트 모드 진입과 플래싱 실행이 이뤄짐을 확인했고, archive.tar.gz와 archive.md5를 복사한 뒤 재부팅으로 새 펌웨어가 올라감
• macOS에서는 커스텀 펌웨어로 SSH 비밀번호 인증을 켜고 공개키를 추가해 실제 접속까지 가능했고, 기본 SSH 활성화와 기본 키 포함 이유는 끝내 밝혀지지 않음

---

펌웨어 업데이트와 SSH 기본 활성화

• Rodecaster Duo는 펌웨어 업데이트 과정에서 장치로 전달되는 파일을 쉽게 확인할 수 있었고, 기본 상태에서 SSH가 활성화되어 있었음
  • macOS에서 디스크 활동을 추적해 펌웨어 저장 위치를 찾았고, 펌웨어는 단순한 gzipped tarball 형태였음
  • 업데이트를 시도한 장치에서는 USB 디스크 쓰기 기능이 비활성화되어 있어 해당 업데이트는 실패함
• 장치 내부에는 실행 바이너리와 업데이트용 셸 스크립트가 있었고, 디스크에는 두 개의 파티션이 있어 하나가 손상되면 다른 쪽으로 부팅되게 되어 있었음
  • 들어오는 펌웨어에는 서명 검증이 없음
  • Ethernet 케이블을 연결해 확인한 결과 SSH가 실제로 열려 있었고, pubkey 인증만 허용하는 상태였음
• 기본으로 추가된 SSH 키 두 개가 확인됨
  • ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCX/bCFTDgViuPvdFL/VMMVRrw9b5S8HcDQk17qoCEYwmI+IIG8rEAsLiaeCOwyhf9IN+8/LRaN0Z5ZfU3WMbmsKEg8zd1Yvqq74nFbhO47vbtzmCi9S4ucIKkBEVOyvyN5lt9hWf5t5nZSmlfldZK3Pem5y8wHM5A+K/gSnzp4gwQ1QYfFb068uQ+ciIdOhb8SkUs8CwzotglIbp19I6ZmXmsNj/TmpbUf5rMfUAf1gysZ5j1UdRWrvWVh5daqvZRsBBPbXEeJfDU3Nr3HR14XYt9mgexrz/5oyKSj/lQYLmh9cDfsxvkGNIQ8fF9l+n2L1KZM4lLgiGk4KFBjQHaIBZx9OebCiiZCO4NTJUBDk9a+SZpiDiipADV07s7vTInYyFA6GrmKtnq3M6upT4WJBvVuL/BMnK5yY1RZtoqox2/pcCg2rH5S1GIy0v0HFJisl7kWInlaG2mdsaCx19wAjCFe/qT9LyxjQ6+0rArI55/JJFDkNeMjrewRQwNdASjCox8vqXCBfjvsR9qv70/ywcymgsnLAnq2LuYg5FYwMMDYOvVnhACC+BYTdNDTn5oeMIjQCUenY/DPCHpJkf4YOf3YCMUTEU9tExhtwW/X+m21hS3+STLtTfqbUeg9CeuPQZgfl9vc65n3tMxAdlEGEDoTaNMAgr2TzJv92Ka9iQ==
  • ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaNyzPfIcEeQsfzyQs/wyX6mX52kiS+4eNHfCaxFlgj

업데이트 흐름과 커스텀 펌웨어

• Windows에서는 Wireshark와 USBPcap으로 업데이트 트래픽을 캡처해 RODECaster App이 장치에 보내는 제어 흐름을 확인함
  • 장치를 업데이트 모드로 넣는 'M' 명령과 업데이트를 실행하는 'U' 명령이 있었음
  • 두 명령 모두 HID report 1으로 전송되는 단일 ASCII 문자였음
• 실제 업데이트 구조는 단순했음
  • M 명령을 보낸 뒤 새로 노출된 디스크에 archive.tar.gz와 archive.md5를 복사함
  • archive.md5는 아카이브의 md5sum 값이었음
  • 그 뒤 디스크를 언마운트하고 U 명령을 보내면 플래싱이 시작되고, 이후 장치가 재부팅되어 새 펌웨어로 올라감
• macOS에서는 컨테이너를 사용해 SSH 비밀번호 인증을 켜고 자신의 공개키를 authorized keys에 추가하는 커스텀 펌웨어를 만듦
  • 플래싱에 필요한 최소한의 함수 예시는 여기에서 확인할 수 있음
  • 스크립트를 실행해 플래싱한 뒤 장치에 SSH로 접속할 수 있었음
• 이 장치는 펌웨어를 매우 쉽게 플래싱할 수 있었고, 기본 SSH 활성화와 기본 키 포함 이유는 확인되지 않은 채 남아 있음
  • 이 문제는 RODE에 티켓으로 전달했지만 답변은 받지 못함
  • 이후 펌웨어 업데이트에서 변화가 생기는지 계속 확인할 예정임

[GN⁺]

Hacker News 의견들

• 이런 얘기에서 늘 답답한 건 signed firmware와 open firmware가 원래 반대말이 아니라는 사실임
  기본값으로 검증을 켜 두는 건 괜찮지만, 하드웨어를 산 사람이 자기 키를 등록하거나 점퍼를 바꾸거나 부팅 때 버튼을 누르는 식으로 소유자 제어권을 가져야 함
  실제로 이렇게 해 주는 곳은 일부 Chromebook과 네트워크 장비 정도라서, 펌웨어 보안 얘기만 나오면 늘 "꽉 잠그자"와 "완전히 열어 두자" 싸움이 되고 정작 돈 낸 사용자가 결정하는 구조는 사라짐
  Rode가 tarball + hash로 배포하는 건 아주 좋고, 나중에 더 빡빡하게 만든다 해도 내가 가진 장비에 내가 원하는 걸 올릴 수 있는 방식이길 바람
• 펌웨어 이미지가 그냥 tarball + hash인 건 정말 마음에 듦
  이런 식으로 열린 장치가 더 많았으면 좋겠고, Rode가 이걸 보고 펌웨어 업그레이드를 잠가 버리지만 않았으면 함
  • 혹시 Rode 쪽 사람이 이걸 본다면, 이런 점 때문에 장비를 사고 싶어짐
    제발 바꾸지 않았으면 함
  • 몇 년 전 HP 프린터 펌웨어를 올려야 했는데, 의외로 방식이 아주 단순해서 좋았음
    2009년쯤 나온 프린터였고 RAM을 256MB로 올리려면 펌웨어 업데이트가 필요했는데, 네트워크로 프린터에 tarball을 FTP로 보내기만 하면 됐음
    FileZilla로 넣었더니 몇 분 동안 돌아가고 바로 업데이트가 끝났고, 그 뒤로는 펌웨어 업데이트가 이보다 복잡할 이유가 있나 싶어졌음
    보안 때문에 checksum 정도는 하더라도, 그냥 FTP나 SCP나 SFTP로 blob 하나 올리고 끝내게 해 주면 좋겠음
  • 그래도 물리 버튼 같은 입력으로만 업데이트 명령을 활성화하는 편이 맞다고 봄
    일종의 DFU mode로 들어가야만 되게 해야지, 아니면 USB에 접근할 수 있는 아무거나 잘못된 펌웨어를 밀어 넣어서 기기를 벽돌로 만들 수 있음
  • 개인적으로 내 오디오 인터페이스가 SSH를 돌리고, 거기에 누가 임의의 authorized key를 추가할 수 있는 구조는 원치 않음
• 제목이 내 오디오 인터페이스는 64비트 Linux 컴퓨터다였으면 더 흥미로웠을 듯함
  10년, 20년 전쯤이면 이런 기능은 아마 작은 16비트나 32비트 SoC에서 VxWorks 같은 RTOS로 구현됐을 가능성이 큼
  물리 컨트롤도 많으니, 다음 단계는 게임 콘솔로 만드는 게 자연스러워 보이기도 함
  • 내 오디오 인터페이스도 사실 Linux computer고 내부에 실제로 field-programmed 되는 FPGA가 들어 있음
    게다가 1GbE 포트가 두 개 있고 각각 기계의 다른 부분과 통신함
    다만 이런 구성은 프로 오디오 세계에선 그렇게 특이하지 않아서, 집 책상 위에 놓고 쓰면 인상적일 뿐 업계에선 꽤 평범한 편임
    나중에 root shell을 따내거나 벽돌로 만들고 나면 그 얘기가 더 재미있을 수도 있겠음
  • 네 video dongle도 Unix 컴퓨터일 수 있음: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
  • 지금은 RAM/storage 압박이 있긴 해도 칩 가격이 워낙 쌈
    비용과 호환성 면에서 Linux를 이기기도 쉽지 않음
• 장치에 제대로 된 DSP가 들어가기 시작하면 이런 구조는 꽤 흔함
  보통 아래에는 ARM SoC에서 도는 최소한의 Linux가 있고, 벤더 BSP가 우연히 sshd를 켠 채로 나가기도 함
  악의라기보다 오디오 쪽에서 rootfs를 제대로 책임지는 사람이 없는 경우에 더 가까움
  핵심은 이게 USB 쪽 네트워크에만 열려 있느냐, 아니면 실제 LAN에도 열려 있느냐임
  전자는 귀찮은 수준이고 후자는 정말 신경 쓰임
  • 아쉽게도 Linux 기본값은 이런 종류의 장치 양산에 썩 좋지 않음
    그에 비해 Android는 eng / userdebug / user처럼 기본 이미지 타입이 나뉘어 있어서, 사전 구성된 기본값만 잘 골라도 이런 실수를 피하기 쉬움
  • 이건 실제로 LAN에서도 듣고 있음
    특정 기능을 쓸 때만 Wi‑Fi에 연결돼서 그 인터페이스도 열려 있는지는 확인하지 못했음
• 이제는 누구나 주머니 속에 AI-hacker를 들고 다니는 느낌이라 여전히 놀라움
  에이전트에 던져 주기만 하면 몇 분 안에 펌웨어를 들여다보고 장치를 수정할 접근법을 줌
  작년만 해도 이런 건 적어도 Hotz급 해커이거나, 아니면 엄청 오래 버티며 파고들 사람이 해야 하는 일이었음
  • 그건 전혀 사실이 아님
    LLM이 분석, 디버깅, 우회를 훨씬 쉽게 만든 건 맞지만, 이 장치는 보호 수준이 워낙 낮아서 중간 정도 실력만 있어도 동기와 시간을 들이면 충분히 가능했음
    암호화된 펌웨어도 없고, 서명 검사도 없고, 내장 SSH access까지 있었음
    반면 George Hotz가 뚫었던 PS3 hypervisor는 공격자 기준으로 훨씬 단단하게 설계돼 있었고, 실제 익스플로잇에는 FPGA를 이용한 voltage glitching까지 필요했음
    그런 류의 공격은 LLM이 도와줄 수는 있어도 완전한 피드백 루프가 없어서 여전히 사람 손이 많이 감
    https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
  • 글을 보면 Claude Code는 사실상 Wireshark와 Google 대신 USB HID 트래픽 해석과 프로토콜 문서 찾기에 쓴 정도로 보임
    Wireshark가 안 깔려 있다면 시간을 조금 아낄 수는 있겠지만, 환각 위험도 조금 있음
    그 밖에는 Docker 안에서 펌웨어 tarball의 ~root/.ssh/authorized_keys와 /etc/shadow를 수정하고, 관련 HID 메시지를 보내고 수정한 tarball을 장치가 USB 드라이브처럼 노출한 볼륨에 복사하는 간단한 Python 스크립트를 쓴 정도였음
    그러니 이건 미친 해커가 필요한 일이 아니라, Linux sysadmin 기본기와 USB HID 라이브러리를 붙여 사소한 프로그램 하나 짤 수 있는 수준이면 됨
    다만 왜 Ubuntu 컨테이너에 whois 패키지를 깔았는지는 순간 의아했는데, Debian 계열에선 역사적인 이유로 mkpasswd가 거기에 들어 있어서 이해됐음
    또 장치의 sshd_config가 기본값 그대로였다면 PermitRootLogin 때문에 root 비밀번호 로그인은 애초에 안 됐을 가능성이 큼
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
  • 나도 AI를 써서 내가 가진 Phase One digital back 하나에서 SSH를 켰고, 다른 하나는 펌웨어를 리버스엔지니어링해서 다른 모델로 인식하게 패치했음
    Credo 50을 IQ250으로 속였는데 내부는 사실상 같음
  • 예전엔 패킷 캡처와 이런저런 데이터를 몇 시간씩 뒤져야 했는데, 이제는 그 시간을 안 써도 되는 게 좋음
    파고드는 재미는 있지만 나이가 들수록 랜덤한 펌웨어 blob을 붙잡고 16시간씩 보내긴 어려워짐
  • 대부분의 경우 LLM은 그런 수준의 일을 해내지 못함
    게다가 SSH가 열려 있는 장치를 다루는 데는 특별한 기술이 필요한 것도 아님
• 나도 같은 문제가 있어서, 글쓴이가 이걸 어떻게 풀었는지 정말 궁금했음
  같은 방에서 게임하고 Discord를 쓰면서 나와 여자친구가 각자 자기 컴퓨터에 마이크를 물리되 echo 없이 쓰고 싶다는 부분이 특히 그럼
  • Rodecaster는 컴퓨터 두 대에 연결할 수 있음
    둘 다 같은 Discord 통화에 들어가되, 두 마이크를 한쪽 컴퓨터 입력으로 합쳐 보내고 다른 사람은 마이크를 음소거한 채 클라이언트에서 오디오만 받게 하면 됨
    믹싱이 로컬에서 일어나니까 에코가 생기지 않음
    더 궁금한 게 있으면 메일 달라고 하고 싶을 정도로 간단함
  • 최근에 Rust로 jack mixer를 대충 vibe coding 했는데, LAN으로 오디오를 받아서 다시 내보낼 수 있음
    지연은 대략 40ms, Wi‑Fi 경유면 50~60ms 정도 나옴
    한 PC에서 믹서를 돌리고 로컬 마이크를 입력 채널 하나로 받고, 다른 PC는 자기 마이크를 방송해서 믹서의 채널 2로 넣으면 비슷하게 해결 가능함
    로컬 PC에서 음악도 틀 수 있고, 믹서나 broadcaster가 로컬 sink를 만들 수 있음
    마지막에 전부 믹서에서 섞어서 메인 아웃은 Discord로 보내고, 모니터 라인은 Discord 오디오를 내보낸 뒤 다른 PC로 다시 릴레이해서 실시간 청취에 쓸 수 있음
  • 지향성 붐 마이크가 달린 headset이면 해결되는 문제 아닌가 싶기도 함
    물론 내가 상황을 잘못 이해했을 수도 있음
• 글도 좋고 도메인도 멋짐
  Zola는 잘 모르지만 이게 흔한 템플릿인지 커스텀인지 모르겠어도 보기 아주 좋음
  • 아마 https://www.getzola.org/themes/radion/ 테마인 듯함
• 많은 벤더가 security를 사실상 복제 방지와 같은 뜻으로 보는 것 같음
  그래서 signed image 같은 걸 강제하는 듯함
• 왜 목표가 disclosure였는지 궁금했음
  이런 인터페이스라면 오히려 열어 둔 채로 두고 싶은 것 아닌가 싶었음
  • 그게 꼭 목표는 아니고, 나도 RODE가 계속 열어 두길 바람
• 호주 쪽 Rode 사람들은 비교적 소통이 잘 되는 편이라, 뭔가 보고할 게 있으면 그냥 전화해도 될 것 같음
  여기선 거의 영어 비슷한 것도 하니까 말은 통할 듯함