1P by GN⁺ | ★ favorite | 댓글 1개
  • 2015년에 완공된 영국 아파트의 정체불명 터치스크린은 NETTHINGS의 에너지 모니터링 시스템 일부로, 전력 사용량의 현재값과 과거 데이터를 보여주는 장치였음
  • 구조는 계량기 쪽 에너지 매니저와 방 안 Android 태블릿형 클라이언트로 나뉘며, 가까운 거리와 벽 몇 개 사이에서도 케이블 대신 WiFi로 통신함
  • 화면이 동작하지 않았던 직접 원인은 에너지 매니저 회로의 3A 퓨즈가 빠진 것이었고, 퓨즈를 교체하자 WiFi 네트워크와 웹 기반 사용량 화면이 되살아남
  • 태블릿 UI는 웹뷰였고 서버는 Node.js, Express, Socket.IO를 사용했으며, 계량기 장치는 172.16.0.254에서 DNS, HTTP, SSH, TCF 서비스를 열고 있었음
  • 열린 tcf-agent가 root 권한으로 파일시스템과 프로세스 접근을 제공해 SSH 비밀번호 없이도 장치를 수정할 수 있었고, 내부는 Linux 3.10 기반 ARM9 장치와 CSV 기반 전력 데이터 저장 구조였음

정체불명 터치스크린의 용도

  • 새 아파트 방 안에는 버튼이나 라벨 없이 작은 노란 전원 표시등만 있는 터치스크린이 설치돼 있었음
  • 집주인도 무엇을 제어하는 장치인지 알지 못했고, 이사 뒤 한동안 잊힌 상태로 남아 있었음
  • 가전 설명서 바인더에서 같은 장치가 실린 브로셔가 나오면서 정체가 드러남
    • 장치는 에너지 모니터링 시스템의 일부
    • 현재 전력 사용량과 과거 사용량 데이터를 표시함
  • 브로셔에는 전기 계량기에 직접 연결되는 두 번째 구성요소인 에너지 매니저도 소개돼 있었음
  • 공동 계량기함에는 NETTHINGS 브랜드 장치가 다른 세대 장치들과 함께 설치돼 있었음

WiFi로 연결된 에너지 매니저와 Android 태블릿

  • 시스템은 데이터를 수집하는 “서버” 역할의 에너지 매니저와, 이를 읽어 화면에 보여주는 “클라이언트” 역할의 터치스크린으로 구성됨
  • 두 장치 사이 거리는 몇 미터에 불과하고 벽도 2~3개 정도였지만, 브로셔에는 SSIDPwd가 적혀 있었음
  • 실제 통신도 케이블이 아니라 WiFi로 이뤄짐
  • 터치스크린 옆면의 작은 구멍 안 버튼을 누르자 Android 부팅 로고가 표시됨
    • 오래된 Android 태블릿이었음
    • Google Talk, Flash 등 오래된 앱이 설치돼 있었음
    • Android 5로 보였지만 정확한 버전은 확실하지 않았음
  • “NetThings” 앱을 실행하면 WiFi 네트워크 선택 화면이 나오지만, 브로셔의 네트워크는 처음에는 목록에 나타나지 않았음

빠져 있던 퓨즈와 되살아난 모니터

  • 계량기함에서 다른 세대의 에너지 매니저는 켜져 있었지만, 해당 세대 장치만 전원이 꺼져 있었음
  • 원인은 퓨즈 박스 안의 퓨즈 누락이었음
    • 퓨즈가 없어 전기 연결이 끊김
    • 에너지 매니저에 전원이 공급되지 않음
    • WiFi 핫스팟도 나타나지 않음
  • 같은 계량기함의 다른 에너지 매니저 퓨즈를 확인해 필요한 규격이 3A 퓨즈임을 확인함
  • Amazon에서 3A 퓨즈를 주문해 다음 날 설치했고, 이후 에너지 매니저의 녹색 LED가 깜박이며 WiFi 네트워크가 나타남
  • 작업은 주전원 근처에서 이뤄져 위험했고, 이후 하루 동안 퓨즈 온도를 여러 번 확인했으며 이런 실험을 다른 사람에게 권하지 않음

실망스러운 웹 UI와 고정된 요금 값

  • Android 태블릿에서 WiFi를 선택하자 자원 종류를 고르는 메뉴가 표시됨
  • 실제로 동작하는 항목은 에너지 매니저가 연결된 Mains Electricity뿐이었음
  • 전력 사용량 화면은 오른쪽 색상 표시기와 왼쪽 숫자 5개를 보여줬지만, UI의 의미가 명확하지 않았음
    • 녹색이 낮은 사용량인지 정상 사용량인지 알 수 없음
    • 색상 표시기의 세로 위치가 무엇과 비교되는지 알 수 없음
    • 최대 위치가 과거 최대 사용량과 관련 있는지도 알 수 없음
  • 왼쪽에 표시되는 숫자 5개 중 실제로 맞는 값은 kW 소비량 하나뿐이었음
  • 전기요금과 kW당 CO2 추정치는 설정할 수 없음
    • 브로셔에는 최초 설치 때 설정 가능하다고 되어 있음
    • 시스템을 다시 설정 가능한 상태로 되돌리는 방법은 안내돼 있지 않음
  • 브로셔에는 데이터 시간 보정을 위해 PC에서 접속하라는 내용도 있었고, Android 태블릿의 시계는 2015년 설치 이후 약 15분 틀어져 있었음

웹뷰, Socket.IO, Node.js 서버

  • 에너지 매니저의 데이터를 직접 읽을 수 있다면 kW 사용량에 올바른 요율을 곱해 Grafana 등에 표시할 수 있음
  • 브로셔에는 PC에서 에너지 사용량을 확인하는 사용 사례가 있었고, 여기에 IP와 포트가 적혀 있었음
  • 브라우저로 접속하자 Android 태블릿과 같은 화면이 표시돼, 태블릿 UI가 웹뷰임을 확인함
  • 웹 인스펙터에서 API 호출을 살펴보니 Socket.IO가 사용되고 있었음
  • 클라이언트는 서버에서 숫자 5개를 받는 정도였지만, 코드에는 RequireJS 모듈, Handlebars, Backbone.js, Underscore.js 등이 포함돼 있었음

열린 포트와 tcf-agent

  • 장치 IP는 172.16.0.254였고, ssh root@172.16.0.254는 처음에 “Connection refused”로 실패함
  • 전체 포트 스캔 결과 다음 서비스가 열려 있었음
    • 53/tcp: dnsmasq 2.63rc6
    • 80/tcp: Node.js 기반 HTTP
    • 1534/tcp: micromuse-lm?
    • 3000/tcp: Node.js 기반 HTTP
    • 41142/tcp: OpenSSH 6.2
  • dnsmasq는 장치가 WiFi 액세스 포인트이기 때문에 DHCP 서버 역할과 맞아떨어짐
  • SSH는 41142 포트에서 열려 있었지만 root 계정은 비밀번호로 보호돼 있었고, admin/admin, root/root 같은 단순 조합은 통하지 않았음
  • 1534 포트의 정체를 찾다가 Xilinx 포럼 글을 통해 tcf-agent 키워드를 확인함

TCF로 얻은 root 파일시스템 접근

  • TCF는 Target Communications Framework의 약자로, 대상 시스템에서 파일시스템 읽기, 새 프로세스 시작, 프로세스에 시그널 보내기 등을 지원하는 텍스트 프로토콜임
  • tcf-agent는 이 프로토콜을 구현하는 서버이며, 이 장치에서는 root 사용자로 실행되고 있었음
  • TCF는 Eclipse 생태계와 밀접하게 연결돼 있었고, Getting Started 문서는 Eclipse 플러그인을 주요 사용 방법으로 안내함
  • 새 Eclipse 버전에서 플러그인을 설치하려 했지만 의존성 충돌로 제대로 설치하기 어려웠음
  • 대신 TCF 프로젝트의 Python SDK를 찾아 사용함
  • TCF의 FileSystem, Processes 서비스로 ls, cat, ps 같은 명령 대체 도구를 만들 수 있었고, 결과물은 tcf-tools에 정리됨

SSH 접근과 장치 내부 사양

  • 처음에는 /etc/passwd/etc/shadow를 TCF로 가져와 John the Ripper로 root 비밀번호를 깨려 했음
  • 약 7시간 실행해도 매칭을 찾지 못했고, John은 무차별 대입 완료 예상 시점을 2035년으로 표시함
  • 이후 /etc/shadow를 수정해 root 비밀번호를 비우고 전원을 다시 넣었지만 SSH 로그인은 여전히 거부됨
  • 원인은 sshd_configPermitRootLogin no 설정이었음
    • 이 줄을 PermitRootLogin yes로 바꾸자 root SSH 로그인이 가능해짐
  • 장치는 Linux 3.10.28 armv5tejl을 실행 중이었음
  • CPU는 ARM926EJ-S rev 5로, ARM9 계열에 해당함
  • /proc/cpuinfo의 기능 목록에 있는 java는 Java 바이트코드 실행을 위한 ARM 확장인 Jazelle을 가리킴
  • 메모리는 MemTotal: 118172 kB로 표시됐고, 장치에서는 Node.js 앱이 실행되고 있었음

애플리케이션 구조와 데이터 저장

  • 서버 애플리케이션은 /srv/server 아래에 있었고, Gruntfile.js, app.js, bower.json, package.json, node_modules, routes, views, public 같은 구조를 가짐
  • 앱은 크게 두 부분으로 나뉨
    • 전기 계량기에서 사용량 데이터를 읽는 Pulse app
    • CSV 데이터를 읽어 웹 UI로 표시하는 Node.js 앱
  • Pulse app 관련 파일은 bin 폴더에 있었음
    • pulse-app
    • pulse.ko
    • ct-read-daemon
    • 월별·일별·시간별·주별·연도별 디렉터리
  • pulse.ko.ko 확장자는 보통 Kernel Object를 뜻하며, 커널 모듈일 가능성이 있음
  • Pulse app은 GPIO 핀에서 데이터를 읽고 결과를 CSV 파일로 저장함
  • CSV 파일은 월, 일, 시간 단위 디렉터리로 나뉘어 있었고, 웹 UI의 과거 데이터 표시도 월별·일별·시간별만 지원함
  • Node.js 앱은 Node.js 0.10.26, Express.js 4.13.3, Socket.io 1.3.6을 사용함
  • 의존성에는 mqtt 패키지가 있었고, 소스에는 브로셔에서 약속한 클라우드 통합으로 보이는 미완성 코드와 하드코딩된 브로커 IP가 있었음
    • 해당 IP들은 더 이상 동작하지 않았음
    • 장치 자체에는 인터넷 접근도 없었음

후속 발견

  • 장치를 만든 NETTHINGS 회사는 이미 해산된 상태였음
  • Hacker News 사용자 M6WIQ는 NetThings의 엔지니어링 결정 결과를 다룬 다른 글을 알려줌
  • 그 글의 작성자는 Mastodon에서 장치가 아직 자신의 NTP 서버 IP를 쓰는지 물었고, 실제 상황은 더 나쁜 쪽으로 확인됨
  • Marc Bevand가 GPU 자원을 제공해 에너지 매니저의 원래 Linux 사용자 비밀번호를 무차별 대입함
    • 해시는 최소 30년 된 알고리듬)을 사용했음
    • rootgecko_user의 비밀번호는 Newt@rd$
    • prod_test 계정의 비밀번호는 NetTh@ng
  • 한 호스팅 회사가 이 글을 러시아어로 번역함

댓글과 토론

Hacker News 의견들
  • 몇 년 전, 사람들이 전기·수도·가스 같은 공공요금 사용량을 더 환경친화적이고 경제적으로 관리하게 하려면 월별 총량 하나보다 훨씬 좋은 데이터가 필요하다는 걸 깨달았음
    최소한 5분 단위 정도로 사용량을 볼 수 있어야 “전기 히터를 몇 시간 켜둔 게 한 달치 조명보다 전기를 더 썼다” 같은 걸 알아챌 수 있음
    남아공 중산층 가정에는 불안정한 전력 공급 때문에 인버터와 태양광 패널이 흔한데, 내 집도 전체 전력 사용 이력을 볼 수 있어서 어디서 효율을 높일 수 있는지 파악하기 쉬움
    다만 여전히 총량 데이터라 원인을 추정해야 함. 예를 들어 샤워 후 한 시간쯤 3kW가 찍히는 건 온수기가 다시 가열되는 것이고, 이때 배터리는 밤새 방전됐고 아침이라 태양광 생산은 낮아 전력망에서 끌어온다는 걸 인버터 기록으로 알 수 있음
    그래서 온수기에 타이머를 달아 오전 10시 이후, 태양이 충분히 올라 태양광으로 충당될 때만 데우게 하면 전기요금을 쉽게 줄일 수 있음. 이제 물 사용량도 이렇게 편하게 모니터링하고 싶음

    • 전적으로 동의하며, 우리 집 Home Assistant 에너지 대시보드가 다른 어떤 조치보다 에너지 소비 절감에 더 크게 기여했다고 봄
      네덜란드라면 “slimme lezer” 같은 걸 전기 계량기의 p1 포트에 꽂으면 Home Assistant에 적절한 센서로 바로 나타남
      에너지 대시보드는 가스·전기 사용량, 태양광 생산량, 전력망/태양광 사용 비율, 있으면 가정용 배터리까지 보여줘서 매우 좋음
      Aqara 에너지 측정 콘센트는 Zigbee라 쉽게 과부하될 수 있고, Shelly는 WiFi지만 꽤 견고했음. 이런 것들과 함께 쓰면 절전 조치의 우선순위를 잘 알 수 있고, Home Assistant 센서에 kWh당 비용과 가스 m³ 비용도 넣을 수 있음
    • 당뇨가 있는 친구가 식단 관리를 꽤 못하고 있었는데, 의사가 몇 주 동안 혈당 모니터를 처방하자 바로 바뀌었음
      팔에 붙이는 큰 밴드 같은 장치로, 얇은 바늘을 피부 아래 넣고 휴대폰 앱과 통신해 혈당 수치 같은 걸 알려줌
      먹던 음식이 어떤 영향을 주는지 알게 되자 즉시 식단을 바꿨고, 모니터를 더 이상 착용하지 않는 지금도 유지 중임. 앱의 UI도 괜찮았지만, 결정적으로 효과가 있었던 건 이력 데이터였음
    • 그 경험은 모니터링과 그에 따른 행동 변화의 한계도 보여줌. 세탁기를 태양광 생산량이 높을 때 맞춰 조금 일찍 또는 늦게 돌리게 만들 수는 있지만, 실제로 옮길 수 있는 소비가 얼마나 되고 에너지 많이 먹는 기기를 얼마나 안 쓰기로 할 수 있을지는 의문임
      요리할 때 전기 사용량이 높다는 걸 알면 샐러드를 더 많이 먹을 것인가? 유럽 전역에서 전기 계량기가 스마트 계량기로 교체되고 있고, 지속적으로 에너지 사용량을 볼 수 있다는 장점이 크게 홍보되지만 실제로 의미 있는 절감으로 이어질지는 아직 판단하기 어려움
      결국 가장 큰 효과는 대형 가전과 냉난방이 자가 생산량에 반응하거나, 시간대별·일별 동적 요금제에서 전기가 쌀 때를 활용할 때 나옴. 직접 설치한 간단한 타이머, 요리 중 난방을 끄는 릴레이, 또는 태양광 초과 생산량에 맞춰 가열 전력을 조정하는 Fronius Ohmpilot [1] 같은 장치가 여기에 해당함
      [1] https://www.fronius.com/en/solar-energy/installers-partners/...
    • 수도 사용량은 계량기 종류에 따라, 1리터마다 한 번씩 도는 작은 반사 휠이 있는 경우가 많음. 금속이거나 약하게 자성을 띠는 경우도 있어서 Arduino에 광학 센서나 홀 효과 센서를 붙이면 실시간 고해상도 데이터 수집까지 꽤 갈 수 있음
      다른 방법으로는 들어오는 수도관에 온도 프로브를 직접 붙이고 주변 온도와 비교해 성공한 적이 있음. 내가 사는 곳은 물이 지하에서 와서 항상 주변 공기보다 훨씬 차갑기 때문에 가능했음
      두 온도 차이를 시간에 따라 적분하면 물 사용량의 대략적인 대용값이 되지만, 의미 있는 데이터를 얻기까지는 훨씬 손이 많이 감
      금속을 감지하는 근접 센서가 가장 단순할 수도 있음. 회전하는 금속 게이지가 달린 수도 계량기라면 https://www.alldatasheet.com/view.jsp?Searchword=LJ12A3-4-Z/... 같은 걸 쓸 수 있음
    • 기기별 전력 집계도 흥미로운 데이터를 줌
      Home Assistant의 에너지 대시보드로 “랙”(UPS+Mac mini+5베이 디스크 장치+기타)이 냉장고나 세탁기와 비교해 실제로 얼마나 쓰는지, 책상 컴퓨팅은 낮지만 화면은 켜져 있을 때 꽤 많이 먹는지, 전기자전거 충전 비용이 얼마인지, 겨울에 온도조절기를 20도 대신 19도로 두면 어떤 차이가 나는지 같은 걸 알 수 있음
      여름에 자주 쓰는 선풍기가 실제로는 온수기만큼 전기를 쓰고 있었다는 식의 놀라운 사실도 보임. 전력 측정은 Shelly Plug Plus S, 3EM, 4PM으로 하고, 온도 측정은 Shelly H&T Plus로 함
  • Linux로 구동되는 가전이라는 기술적 기형에 글쓴이가 놀라는 점이 흥미로움. Node 서버가 WiFi로 웹사이트, API, 웹소켓을 제공하고, 그 사이트는 다른 용도로 재사용할 수 없는 제약 많은 단말의 오래된 WebView 엔진에 표시되는 구조가 이제는 흔한 표준처럼 됨
    숫자 몇 개와 막대그래프를 보여주는 일은 유선 버스로 통신하는 마이크로컨트롤러 두 개로도 충분했을 텐데, 이 시대의 전원장치라면 두 기기가 유휴 상태에서 16W 정도 먹을 수도 있음
    24시간 365일 켜져 있으면 작은 냉장고만큼 전기를 쓰고, 몇 달러짜리 마이크로컨트롤러 몇 개와 비교하면 생애주기평가도 좋지 않을 것임
    최악은 이 복잡한 장치가 설치 후 3년, 어쩌면 그보다 더 빨리 벽돌이 됐을 가능성이 큼

    • Mirai 봇넷이 아직도 활개치는 이유는 Android임
      비즈니스 관점에서는 마이크로컨트롤러 프로그래밍을 할 수 있는 비싼 인력을 쓰고 싶어 하지 않음. 막대그래프를 보여주는 단순 인터페이스라면 프런트엔드 개발자가 훨씬 싸게 먹힘
    • “다른 용도로 재사용할 수 없는 제약 많은 단말”이라고 했지만, 봇넷이나 감시 용도로는 쓸 수 있음
      일부 보드에는 이미 MEMS 마이크와 카메라가 들어 있고, 사진 속 박스에도 카메라 렌즈가 보임. 나라면 장치를 분해해서 내부를 보거나, 적어도 어떤 하드웨어가 설치·감지되는지 진단을 돌려봤을 것임
    • 저 쓸모없는 장치를 계속 켜두느니 퓨즈를 다시 빼는 편이 더 많이 절약될 듯함
    • 완공된 뒤에 어디든 배선을 새로 통과시키는 건 설치 난이도가 매우 큼. 가능할 수도 있지만, 가능하더라도 완전히 비현실적일 수 있음. 예를 들어 저전압 버스와 차폐 안 된 전원선은 나란히 지나갈 때 잘 맞지 않음
    • 16W를 24시간 30일 쓰는 비용은 미국 평균 전기요금 기준 월 2달러 미만이라 사소해 보임
      https://www.wolframalpha.com/input?i=16+watts++24+hours++3...
  • SSID와 비밀번호가 인쇄돼 있었다는 점은 전혀 놀랍지 않음. 이런 장치는 신축에 포함되기보다 기존 주택에 개조 설치되는 경우가 많을 것이고, 기존 벽 안으로 배선을 넣는 건 번거로우니 판매 장벽을 만들고 싶지 않았을 것임
    요즘은 몇 달러면 충분한 WiFi 칩셋을 구할 수 있음
    3A 퓨즈도 그렇게 걱정할 필요는 없어 보임. 3A 퓨즈라면 아파트 전체 주전력이 그걸 통과하는 구조가 아니고, 그렇게 하려 했다면 순식간에 끊어졌을 것임
    그리고 Jazelle라니, Java 바이트코드 하드웨어 지원은 결국 잘 풀리지 않았던 기술이었음

    • Amazon에서 산 퓨즈라면 끊어지지 않을까 봐 걱정할 이유가 충분함. Louis Rossmann이 2A 퓨즈에 8A를 흘리고 꽤 오래, 아마 몇 분 동안 방을 비워둔 영상[0]이 있음
      [0]: https://www.youtube.com/watch?v=B90_SNNbcoU
    • WiFi는 본질적으로 넓은 간격의 갈바닉 절연을 제공함
      꼭 필요한 건 아니지만, 전기적으로 위험한 부분과 사람이 만지는 부분을 비용 효율적으로 분리하고 문제가 생겼을 때 루프를 피하는 방법이 될 수 있음. 무선은 단순히 전선을 없애는 것 이상의 용도가 있음
    • 그 시기를 제대로 볼 만큼 나이가 많지 않았는데, Jazelle이 잘 안 된 이유가 무엇이었는지 궁금함. 지금 돌아보면 Java가 워낙 지배적으로 보여서 이런 기술이 성공하지 못했다는 게 의외임
    • “주전원 가까이 있어서 좀 무서웠다”는 부분에서 웃었음. 퓨즈 교체가 그렇게 무서울 일인가 싶음. 영국에서는 초등학교에서 가르치던 일이었고, 퓨즈는 끊어지거나 안 끊어질 뿐이며 끊어지면 바로 알 수 있음
      적어도 죽은 퓨즈를 영생과 확실한 죽음의 의식용 알루미늄 외피로 곱게 감아 넣은 콘센트를 발견한 건 아니었음. 어릴 때 불에 더 취약하던 시절에 내가 저지른 적이 있을지도 모르는 범죄임
      자기 안전지대 밖에서 불편해하는 사람이 많다는 게 흥미로움. 물론 나는 평생 건드릴 필요 없는 것들에 코를 들이미는 사람임
    • 기존 벽에 배선을 통과시키기 어렵다는 건 맞지만, 덕분에 길 건너편이나 지향성 안테나를 쓰면 도시 반대편에서도 장치를 침해하기 편해짐
      물론 보안이 충분하고 정기 보안 업데이트를 계속 받는다면 문제가 아니며, 글쓴이가 발견한 장치는 그런 조건을 충족하지 못한 아주 드문 예외였다고 추정할 수밖에 없음
  • 회사 이름 Netthings가 익숙했는데, 이 회사 장치에 하드코딩된 NTP 서버가 방화벽으로 막혀 시간 동기화를 잃었다는 글을 예전에 읽은 적이 있었음
    글: https://strugglers.net/~andy/blog/2018/12/24/the-internet-of...
    2018년에 청산 절차에 들어간 것으로 보이니, 이 장치 지원을 받기는 어려울 것임

    • 매뉴얼의 “DATE & TIME ARE ALWAYS CORRECT AND NEVER NEED TO BE ADJUSTED” 문구가 그래서 더 훌륭해짐
    • 이 링크가 정말 놀라워서 글 끝에 추가했음
  • “DATE & TIME ARE ALWAYS CORRECT AND NEVER NEED TO BE ADJUSTED”는 Philip K. Dick 소설에서 나온 문장처럼 읽힘

    • 기술문서 작성자가 “NTP 서버에 핑하니까 걱정하지 말라”고 말한 방식이었을지도 모름 https://news.ycombinator.com/item?id=39065780
      분명히 잘 풀리지는 않았음
    • 아마 영국 라디오 타워 연동 같은 시각 보정 기능이 있었을 거라 추측했지만, 기사에 따르면 이 장치는 2015년 제품이라 아닐 가능성이 큼
  • “IoT의 C는 cost-effective인가 보다”라는 농담은 짧고 재치 있지만, 실제로 WiFi 지원 SoC가 얼마나 싸고 비용 효율적인지 알면 놀랄 수 있음
    많은 경우 WiFi는 사실상 공짜로 따라오고, 이런 SoC 대부분은 기본으로 Ethernet 컨트롤러가 없어서 사용 사례에 맞기만 하면 WiFi가 더 비용 효율적임
    다른 물리 프로토콜이나 연결 방식도 물론 가능하지만, 이런 개조 설치형 클라이언트에서는 WiFi나 일반적인 무선 프로토콜이 최선임

    • 순수하게 자재 관점에서 보면 esp8266 같은 저가 WiFi 지원 마이크로컨트롤러 2개는 제조사 비용으로 합쳐 4~5달러 정도일 것임
      3m 케이블, 커넥터, 케이블 연결 처리용 저가 칩과 비슷한 수준이고, 케이블 설치 인건비는 그보다 훨씬 비쌈. 그래서 WiFi로 연결하는 게 낭비라고 보는 이유를 잘 모르겠음
    • ESP32는 이제 거의 보편적인 선택지임. 어느 정도 물량으로 주문하면 1달러 미만에 살 수 있고, WiFi와 Bluetooth가 바로 들어 있음. 지금은 WiFi를 안 쓰는 쪽이 더 비싸짐
  • 원글 작성자에게 John The Ripper로 무차별 대입에 실패했던 /etc/shadow 파일을 보내 달라고 했고, 구식 UNIX crypt() 해시라서 hashcat과 12대의 RTX 4090으로 약 7시간 만에 루트 비밀번호를 깰 수 있었음
    루트 비밀번호는 Newt@rd$
    이 장치는 인증 없이도 TCF를 통해 루트 접근이 가능하니 특별히 유용하진 않지만, 이 비밀번호가 다른 곳에서도 재사용됐을 수는 있음

  • 도메인이 시간의 모래에 묻힐 경우를 대비해, 글 자체를 그 장치에서 호스팅하면 좋겠음

  • 3A는 720W임. 저 작은 박스가 그만큼 열을 낸다면 벽장 전체가 말 그대로 오븐이 될 것임
    애초에 에너지 계량기가 그만큼 전력을 쓰면 목적을 거스르는 일이고, 성냥을 테스트하는 것과 비슷함. 많아야 10W일 것이며, 돌입 전류도 그렇게 높진 않을 듯함
    1A 퓨즈면 충분할 것 같고, 설치도 꽤 깔끔해 보여서 주전원 근처였다는 점도 그렇게 무서울 정도는 아님

    • 3A 퓨즈는 이 장치에 최적인 값이라서가 아니라 영국 배선 체계 때문에 쓰인 것임
      영국의 모든 가전은 건물 배선에 연결되는 지점에 퓨즈가 있고, 보통 플러그 안에 있지만 이 장치처럼 고정 퓨즈 홀더에 있을 수도 있음
      값이 너무 다양하면 사용자에게 혼란스럽고 번거롭다는 판단이 있어, 이 퓨즈들은 같은 크기에 표준값 13A, 5A, 3A 중 하나로 제한됨. 다른 곳에서 말했듯 이 퓨즈는 영국 슈퍼마켓과 편의점에서도 살 수 있음
      3A가 기기에 비해 너무 높다면 설계자는 3A 정격 플렉스 케이블을 써서 플러그 쪽 퓨즈가 보호하게 하고, 장치 쪽에 더 낮은 전류 보호를 추가해야 함
      영국식 시스템은 도입 당시에는 표준 퓨즈값 같은 미묘한 세부가 잘 맞았던 영리한 구조지만, 저전류 기기가 많은 현대 주택에는 다소 과설계되어 있고 최적화돼 있지 않음
    • 퓨즈의 시간 정격과 전원공급장치의 돌입 전류에 따라 다름. 돌입 전류가 10A를 넘는 경우도 있어서, 일부 1A 퓨즈는 장치를 켤 때 가끔 끊어질 수 있음
  • 집에서 이런 실시간 사용량 데이터를 보고 싶다면 IoTaWatt를 강력히 추천함: https://iotawatt.com
    집의 차단기 패널에 설치하는 완전 로컬 에너지 모니터이고, 장치에서 실행되는 로컬 웹 서버의 대시보드를 보거나 API로 데이터를 읽을 수 있음
    센서 개수를 직접 고를 수 있고, 집 전체뿐 아니라 개별 회로도 모니터링 가능함
    예를 들어 세탁기, 식기세척기, 전자레인지 같은 가전이 시작·정지할 때 추적하고 자동화를 트리거함
    다만 직접 설치하려면 조사와 기본적인 전기 지식, 고전압 주전원 연결 작업에 대한 부담감이 필요함. 그래도 접근 가능하고 설정은 쉬웠음
    생김새는 이렇음: https://i.ibb.co/qBVmBD1/IMG-1595.jpg