![\"Setup](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/rubber-band-setup.png\")
Dear Fellowlship, just as we announced in our previous post, our beloved God Debugger has seen fit to cast his divine light -laden with opcodes- upon his humble servant, and we have a new homily here in our temple. Please, take a seat and listen to the story of how one of our owls, along with his brother-in-law, moved on to dissect the next component of the Eufy ecosystem: the Eufy HomeBase 2.
\nWe focused our analysis in Eufy Homebase2 instead of Homebase3 because, as we explained in From your doorbell to your home network it’s the version that I found deployed in my city, and also was the easiest to buy. The firmware version we analyze here is 3.4.2.2h (2026-06-05 18:45:48)
\nThis is the first time I touched something related to “hardware”. I always did vuln hunting on firmwares that I could download from internet, so please forgive the sins I commited
\nIMPORTANT!!! You must read first the previous article before you continue reading this one.
\nJust as with the previous article, we will be covering a variety of topics here; consequently, some members of this fellowlship may have no interest in certain sections and might wish to skip straight to whatever appeals to them most. That is why we present this blessed offering: a table of contents.
\nIn the previous chapter of this saga, I mentioned that we were only able to extract the doorbell’s firmware because the Homebase’s flash memory was soldered directly to the board and did not expose any pins to which we could attach test hooks to dump the firmware. Initially we did not want to desolder it (although in the end we had to as I will explain later) so I had to wait to acquire additional hardware. Craig S. Blackie pointed me to spring clips that would suit the size needed for the Winbond 25Q256JWEQ (WSON8 8.6mm). Once the clip arrived I created the most makeshift setup imaginable, using rubber bands to secure the clip while I proceeded to take readings using the Raspberry Pi’s SPI0 interface, just as we did with the doorbell.
\nSetup using rubber bands to read the firmware.
\nI performed three reads and the three had different checksums, which usually is a indicator of something being wrong. After inspecting the dumps, I quickly realized they were garbage and completely useless. Unlike with the doorbell, in this case, the power supplied for the read operation also activated other components on the board that interacted with the memory; therefore, to extract the firmware, we had to desolder the chip and read it off-board.
\nMy brother-in-law (Óscar Lestón) was the brave soul that desoldered the flash memory (I was too scared to even try it):
\n![\"Desoldering\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/desolding.jpg\")
Desoldering
\nAlthough the memory module looked terrible once removed, it was barely damaged…
\n![\"Chip\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/chip.jpg\")
Extracted flash memory
\nAnd finally we replicated the same setup using the Raspberry Pi SPI 0 to dump the firmware. This time the three dumps had the same checksum and contained “interesting data”. The only problem was… a block of 64kbs was erased / could not be read, highly probable because we damaged it when extracting the chip.
\n![\"Using](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/reading.jpg\")
Using the Raspberry Pi to read the chip off-board
\nMost of the firmware could be extracted using Binwalk.
\n /home/psyconauta/research/Eufy/homebase2-firmware/chipoff/STUFF/extractions/homestation2_firmware00.bin\n----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\nDECIMAL HEXADECIMAL DESCRIPTION\n----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n83328 0x14580 U-Boot version string: 1.1.3 (Jun 14 2023 - 16:18:56)\n3022226 0x2E1D92 XZ compressed data, total size: 11514432 bytes\n14536660 0xDDCFD4 XZ compressed data, total size: 2200 bytes\n14538862 0xDDD86E XZ compressed data, total size: 2084 bytes\n14540948 0xDDE094 XZ compressed data, total size: 1868 bytes\n14542818 0xDDE7E2 XZ compressed data, total size: 168 bytes\n14542988 0xDDE88C XZ compressed data, total size: 4192 bytes\n14547182 0xDDF8EE XZ compressed data, total size: 2844 bytes\n14550028 0xDE040C XZ compressed data, total size: 244 bytes\n14550282 0xDE050A XZ compressed data, total size: 1452 bytes\n15138816 0xE70000 uImage firmware image, header size: 64 bytes, data size: 3429849 bytes, compression: lzma, CPU: MIPS32, OS: Linux, image type: OS Kernel Image, load address: 0x80000000, entry\n point: 0x802E04F0, creation time: 2023-06-14 12:56:37, image name: "Linux Kernel Image"\n21233664 0x1440000 JFFS2 filesystem, little endian, nodes: 3426, total size: 12255244 bytesSome parts were recovered, others no. Because there was a lot of XS streams, we choose the stupid (or maybe not so stupid) idea of using directly 7z to extract all in a big blob (and hopefully search by needles there to carve files).
➜ extractions mkdir -p 7z_mandanga\n➜ extractions 7z e -y -o7z_mandanga homestation2_firmware00.bin\n\n7-Zip 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20\n 64-bit locale=es_ES.UTF-8 Threads:16 OPEN_MAX:1024\n\nScanning the drive for archives:\n1 file, 33554432 bytes (32 MiB)\n\nExtracting archive: homestation2_firmware00.bin\n\nERRORS:\nThere are data after the end of archive\n\n--\nPath = homestation2_firmware00.bin\nType = xz\nERRORS:\nThere are data after the end of archive\nOffset = 3022226\nPhysical Size = 11514432\nTail Size = 19017774\nMethod = LZMA2:17\nStreams = 358\nBlocks = 358\nCharacteristics = BlockPackSize BlockUnpackSize\n\nERROR: There are some data after the end of the payload data : homestation2_firmware00\n\nSub items Errors: 1\n\nArchives with Errors: 1\n\nOpen Errors: 1\n\nSub items Errors: 1\n➜ extractions ls -hal 7z_mandanga\ntotal 42M\ndrwxrwxr-x 2 psyconauta psyconauta 4,0K sep 19 19:41 .\ndrwxrwxr-x 4 psyconauta psyconauta 4,0K sep 19 19:34 ..\n-rw-rw-r-- 1 psyconauta psyconauta 42M sep 19 18:35 homestation2_firmware00One of the key questions we wanted to investigate via the firmware was the new algorithm for generating credentials for the OCEAN_XXXXXX management Wi-Fi, as we observed that it differed completely from what was expected based on the 2024 paper. Specially, we were interesting in know if the algorithm was weak as previously or no.
\nAfter writing the previous article, I realized I had failed my brother-in-law as a mentor. I had shown him how to use Ghidra and pseudo-C instead of leading him down the path of light and reason. I atoned for my sin and drew radare2.
\nFirst we checked where the Wifi network ESSID and password could be found in the firmware. A simple grep was enough to identify NVRAM variables containing both wifi names and credentials (the ad-hoc wifi used to enroll the doorbell and the mangement wifi):
➜ extractions strings homestation2_firmware00.bin_83358_unknown.raw | grep F1VSXfNQL_ZCd3k -A5 -B5\nAuthMode=WPAPSKWPA2PSK;WPAPSKWPA2PSK\nEncrypType=AES;AES\nRekeyInterval=3600\nRekeyMethod=TIME\nPMKCachePeriod=10\nWPAPSK1=F1VSXfNQL_ZCd3k\nWPAPSK2=913ceac3\nDefaultKeyID=2;2\nKey1Type=0\nKey1Str1=\nKey2Type=0\n➜ extractions strings homestation2_firmware00.bin_83358_unknown.raw | grep OCEAN_E9A5FC -A5 -B5\nDDNSPassword=\nCountryRegion=0\nCountryRegionABand=7\nCountryCode=ES\nBssidNum=2\nSSID1=OCEAN_E9A5FC\nSSID2=4350c372\nWirelessMode=9\nTxRate=0\nChannel=0\nBasicRate=15Then we tried a more broad search to try to identify binaries and/or scripts related to the wifi setup:
\n➜ 7z_mandanga strings homestation2_firmware00 | rg 'OCEAN_'\n%s,<%d>file not exist.return OCEAN_TEST_TF_CARD_NOT_FOUND.\nOCEAN_MAGIC\nout of memory of OCEAN_TEST_DATA\nOCEAN_TF_CARD_FORMAT_SUCCESSED\nOCEAN_TF_CARD_FORMAT_FAIL_MOUNT\nOCEAN_TF_CARD_FORMAT_FAIL\nOCEAN_TF_CARD_FORMAT_IN_USE\n ssid_prefix="OCEAN_"\n ssid_prefix="OCEAN_"\nCONFIG_LEDS_OCEAN_PWM=y\nOCEAN_RUN=/mnt/ocean.sh\nif [ -f $OCEAN_RUN ];then\n chmod +x $OCEAN_RUN\n sh $OCEAN_RUN &Unraveling a bit more this thread we found an interesting line that matches what we already knew: the ESSID is the concatenation of “OCEAN_” and MAC address:
\n➜ 7z_mandanga strings homestation2_firmware00 | rg 'ssid_prefix'\n ssid_prefix="ocean_factory_"\n ssid_prefix="OCEAN_"\n WIFI_SSID=$ssid_prefix$SSID_MAC\n ssid_prefix="`nvram_get ssid_pre`"\n if [ "$ssid_prefix" = "" ];then\n ssid_prefix="OCEAN_"\n WIFI_SSID=$ssid_prefix$SSID_MACLet’s zoom out to get the full script:
\n➜ 7z_mandanga strings homestation2_firmware00 | rg 'ssid_prefix' -B30 -A40\n.sdata\n.sbss\n.bss\n.pdr\n.gnu.attributes\n.mdebug.abi32\n#!/bin/sh\nwork_mode="`cat /var/run/testmode`"\ndef_mode="`nvram_get 2860 work_mode`"\nSSID_MAC=""\nnvram_ssid="`nvram_get 2860 SSID1`"\nbssid_num=`nvram_get 2860 BssidNum`\neth_state=`apcliDaemon get_eth_state`\nrepeater_enable=`nvram_get 2860 RepeaterEnable`\nwifi_11bgn_enabled=`nvram_get 2860 wifi_11bgn_enabled`\nWireless_Mode=9\nif [ "$eth_state" = "0" -a "$repeater_enable" = "1" -a "$wifi_11bgn_enabled" = "1" ]; then\n Wireless_Mode=9\nget_wifi_mac()\n SSID_MAC="`ifconfig ra0 | grep HWaddr | awk '{print $5}' | awk -F ':' '{print $4$5$6}'`"\n #SSID_MAC="`ifconfig ra0 | grep HWaddr | awk '{print $5}' | awk -F ':' '{print $5$6}'`"\n while [ "$SSID_MAC" = "" ]\n sleep 1\n SSID_MAC="`ifconfig ra0 | grep HWaddr | awk '{print $5}' | awk -F ':' '{print $4$5$6}'`"\n #SSID_MAC="`ifconfig ra0 | grep HWaddr | awk '{print $5}' | awk -F ':' '{print $5$6}'`"\n done\n echo "get mac in ssid is:$SSID_MAC"\nif [ "$bssid_num" = "2" ];then\n ifconfig ra1 down>/dev/null 2>&1\nif [ "$work_mode" = "1" ];then\n ssid_prefix="ocean_factory_"\n if [ "$def_mode" = "factory_mode" ];then\n ssid_prefix="OCEAN_"\n get_wifi_mac\n WIFI_SSID=$ssid_prefix$SSID_MAC\n echo "set wifi SSID:$WIFI_SSID"\n iwpriv ra0 set SSID="$WIFI_SSID"\n if [ "$def_mode" = "factory_mode" ];then\n # only WIFI_SSID is not equ nvram_ssid, update nvram.\n if [ "$nvram_ssid" != $WIFI_SSID ];then\n nvram_set SSID1 $WIFI_SSID\n fi\nelse\n ssid_prefix="`nvram_get ssid_pre`"\n if [ "$ssid_prefix" = "" ];then\n ssid_prefix="OCEAN_"\n get_wifi_mac\n WIFI_SSID=$ssid_prefix$SSID_MAC\n echo "set wifi SSID:$WIFI_SSID"\n # only WIFI_SSID is not equ nvram_ssid, update nvram.\n if [ "$nvram_ssid" != $WIFI_SSID ];then\n nvram_set SSID1 $WIFI_SSID\n iwpriv ra0 set SSID="$WIFI_SSID"\n if [ "$nvram_ssid" = "MT7628_AP" ];then\n sleep 3\n #reboot\n /sbin/umount_and_reboot.sh\n fi\n iwpriv ra0 set HtBw=0\n iwpriv ra0 set WirelessMode=$Wireless_Mode\n iwpriv ra0 set HtGi=0\n iwpriv ra0 set SCSEnable=1\n if [ "$bssid_num" = "2" ];then\n # ssid and pwd set in RT2860_default_vlan\n #iwpriv ra1 set SSID="AKDevbind"\n #iwpriv ra1 set WPAPSK="Anker39#*"\n #iwpriv ra1 set SSID="XMCONFIG"\n #iwpriv ra1 set WPAPSK="12345678"\n iwpriv ra1 set HtBw=0\n iwpriv ra1 set WirelessMode=$Wireless_Mode\n iwpriv ra1 set HtGi=0\n iwpriv ra1 set SCSEnable=1\n iwpriv ra1 set WmmCapable=1\n iwpriv ra1 set ed_chk=0\nwpapsk="`nvram_get WPAPSK1`"\nif [ "$wpapsk" != "" ];then\n #echo "iwpriv ra0 set WPAPSK=$wpapsk"\n iwpriv ra0 set WPAPSK=$wpapsk\n# set wmm\niwpriv ra0 set WmmCapable=1\n# change wan mode,\nwifi\napcli\niwpriv\nhome_security\nif [ "$eth_state" = "0" -a "$repeater_enable" = "1" ]; then\n switch_wan_interface.sh eth2.2 apcli0 0\n#!/bin/shSo, from one side we found how the ESSID is created and from the other side we found that the password is read from a NVRAM variable (wpapsk="nvram_get WPAPSK1"). Let’s do a quick search with that name:
➜ 7z_mandanga strings homestation2_firmware00 | rg -i 'WPAPSK1' -A5 -B5\nwifi channel:%d.\nfail to get freq.\n/dev/gpio\nError while opening /dev/gpio\nSSID1\nWPAPSK1\nSSID2\nra1 SSID=%s\nWPAPSK2\nra1 WIFI_PWD=%s\n/sbin/chpasswd.sh eufycamera %s\n--\n(...)Just in the first hit there is something that looks like a compiled binary (that %d is suspicious). I built this crappy script to extract the elf that search for the string, then search backwards to find the magic header and assume the following file in the blob is also an ELF:
#!/usr/bin/env python3\n\n with open("homestation2_firmware00", "rb") as file:\n data = file.read()\n\n needle = data.find(b"WPAPSK1")\n magic = data.rfind(b"\\x7fELF", 0, needle)\n end = data.find(b"\\x7fELF", needle)\n binary = open("elf_wifi_01", "wb")\n binary.write(data[magic:end])\n binary.close()And it worked flawelessly:
\n➜ 7z_mandanga python3 carve_wifi.py\n➜ 7z_mandanga file elf_wifi_01\nelf_wifi_01: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, strippedDoing a quick check on the symbols we find a lot of interesting stuff related to wifi, specially that juicy set_wifi_pwd.
➜ 7z_mandanga r2 elf_wifi_01\nWARN: Relocs has not been applied. Please use `-e bin.relocs.apply=true` or `-e bin.cache=true` next time\n -- Use 'zoom.byte=printable' in zoom mode ('z' in Visual mode) to find strings\n[0x0045d130]> aaa\nINFO: Analyze all flags starting with sym. and entry0 (aa)\nINFO: Analyze imports (af@@@i)\nINFO: Analyze entrypoint (af@ entry0)\nINFO: Analyze symbols (af@@@s)\nINFO: Running plugin pre-analysis hooks\nINFO: Analyze all functions arguments/locals (afva@@F)\nINFO: Analyze function calls (aac)\nINFO: Analyze len bytes of instructions for references (aar)\nINFO: Finding and parsing C++ vtables (avrr)\nINFO: Analyzing methods (af @@ method.*)\nINFO: Emulate functions to find computed references (aaef)\nINFO: Recovering local variables (afva@@@F)\nINFO: Type matching analysis for all functions (aaft)\nINFO: Propagate noreturn information (aanr)\nINFO: Use -AA or aaaa to perform additional experimental analysis\nINFO: Finding xrefs in noncode sections (e anal.in=io.maps.x; aav)\n[0x0045d130]> afl~wifi\n0x006f8908 1 288 sym.eufy_setDoorbellMechanicalChimeSwitch_wifi\n0x005a972c 14 1124 sym.zx_update_dev_wifi_info_by_addr\n0x0054ad3c 10 316 sym.check_hub_wifi_power\n0x00558fd8 18 1800 sym.quick_bind_wifi_mgmt_rcv_handler\n0x0052cfac 19 1272 sym.zx_update_hub_wifi_channel\n0x005e5414 93 7544 sym.netlink_wifi_connect\n0x0093f1c0 6 528 sym.aws_wifi_get_mac\n0x0053aff8 1 80 sym.zx_get_wifi_mac\n0x004cda10 13 728 sym.zx_check_wifi_version\n0x005489a0 1 16 sym.wifi_reduceTxPower\n0x005a47a0 23 892 sym.zx_alloc_wifi_addr\n0x00532224 4 324 sym.set_camera_wifi_rssi\n0x0049c7d4 11 448 sym.wifi_check_all_devs_online\n0x0049c61c 10 440 sym.wifi_get_dev_rssi\n0x0049c994 20 1768 sym.wifi_get_devs_rssi_list_in_json\n0x0059e8f8 3 204 sym.restart_wifi\n0x0053bb04 1 144 sym.set_pair_wifi_info\n0x0053b048 8 660 sym.get_wifi_info\n0x006fb684 399 18808 sym.zx_wifi_send_command\n0x00603514 6 484 sym.make_wifi_notify_json\n0x0054ab0c 9 560 sym.convert_wifi_countrycode\n0x0059df7c 1 104 sym.wifi_info_signal_init\n0x0053b510 33 1524 sym.set_wifi_pwd\n0x00558894 5 292 sym.zx_quick_bind_timer_stop_send_wifi_info\n0x006f8094 8 304 sym.eufy_set_wifi_countrycode\n0x0054ae78 7 464 sym.set_wifi_power_flag\n0x004da374 54 3076 sym.zx_handle_wifi_ready\n0x006f6348 8 828 sym.wifi_log_server_init\n0x006f8a28 1 288 sym.eufy_setDoorbellElectronicRingtoneTime_wifi\n0x0094a1f4 4 168 sym.anker_mgmt_register_get_wifi_channel_cb\n0x00532368 10 396 sym.check_camera_wifi_rssi_ok\n0x005580a0 28 2036 sym.zx_quick_bind_timer_send_wifi_info\n0x0094a29c 4 168 sym.anker_mgmt_register_get_wifi_mac_cb\n0x0053b2dc 6 564 sym.get_wifi_ra1_info\n0x006f6684 8 828 sym.wifi_log_server_t40_init\n0x0056dc34 15 1008 sym.repeater_update_all_dev_wifi_channel\n0x0049d07c 13 636 sym.wifi_devs_rssi_test_mode_exit\n0x004daf78 1 160 sym.handle_wifi_ready_thread\n0x008c5ac4 7 356 sym.zx_homekit_get_wifi_ready\n0x0049d2f8 9 288 sym.wifi_setManualChannel\n0x004cd584 11 668 sym.eufysdk_common_msg_wifi_callbackJumping into that function we can see that first it builds a password based on a MD5 hash that is used locally for the user eufycamera and it’s not related to the wifi. The wifi-stuff starts at 0x0053b690 where it checks one parameter from base_param (I guess the type of device or model) against 0x0C. This part is key because if the value is different to 0x0C, then it uses the MAC Address (right block) meanwhile if it matches then it would use what returns z8GetSN() (left block). We are in the z8GetSN() case.
![\"Radare2\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/radare01.png\")
Different flow based on device model.
\nThe z8GetSN() function communicates through i2c and sends command 0xC1 (the i2c part is inside z8SendData()) and read 0x11 bytes from the response.
![\"Radare2\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/radare02.png\")
I2C communication to extract a serial number (it's not the device SN)
\nThen bytes are translated into 32 byte string and fed to a function called mac_func() which also receives the Homebase Serial Number (T8010...):
![\"Radare2\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/radare03.png\")
The SN from the I2C communication and the device Serial Number (obj.g_hub_sn) used as parameters for mac_func()
\nThis mac_func calls a helper to perform HMAC SHA256 with the previous mentioned data, being the “message” the value returned by z8GetSN and the “key” the Serial Number:
![\"Radare2\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/radare04.png\")
HMAC SHA256
\nThe result is used by a function that would encode the information into text.
\n![\"Radare2\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/radare05.png\")
Encoding memory contents
\nThe zx_Memory_Encode function calls urlsafe_b64_encode which converts the value into base64 using the following alphabet:
[0x006f0490]> px 65 @ 0xa5cb40\n- offset - 4041 4243 4445 4647 4849 4A4B 4C4D 4E4F 0123456789ABCDEF\n0x00a5cb40 4142 4344 4546 4748 494a 4b4c 4d4e 4f50 ABCDEFGHIJKLMNOP\n0x00a5cb50 5152 5354 5556 5758 595a 6162 6364 6566 QRSTUVWXYZabcdef\n0x00a5cb60 6768 696a 6b6c 6d6e 6f70 7172 7374 7576 ghijklmnopqrstuv\n0x00a5cb70 7778 797a 3031 3233 3435 3637 3839 2d5f wxyz0123456789-_\n0x00a5cb80 00 .Finally, the password is updated in NVRAM and changed executing the external command iwpriv ra0 set WPAPSK=%s:
![\"Radare2\"](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/radare06.png\")
Updating NVRAM value
\nSo, the only unkown data to replicate the password is the value returned by z8GetSN. The other compontent, the device serial number, is “predictable” because it follows a known template based on the type of device.
In the previous article, we mentioned that UART access was blocked. Specifically, connecting via UART yielded a prompt asking the user to press the “Enter” key. However, doing so caused the process to terminate and the same program to relaunch, once again requesting the key press; this created an infinite loop that prevented access to an actual shell. Logs can be seen below:
\nstarting pid 5617, tty '/dev/ttyS1': '/sbin/login.sh'\n\nprocess '/sbin/login.sh' (pid 5617) exited. Scheduling for restart.\n\nPlease press Enter to activate this console.\nsetrlimit(RLIMIT_CORE, &limit);\n\nstarting pid 6526, tty '/dev/ttyS1': '/sbin/login.sh'\n\nprocess '/sbin/login.sh' (pid 6526) exited. Scheduling for restart.\n\nPlease press Enter to activate this console.\nsetrlimit(RLIMIT_CORE, &limit);\n\nstarting pid 6608, tty '/dev/ttyS1': '/sbin/login.sh'\n\nprocess '/sbin/login.sh' (pid 6608) exited. Scheduling for restart.On the other hand, trying to interrupt U-Boot witch a escape sequence did not work.
\nAfter acquiring the firmware and resolving questions about how the Wi-Fi password algorithm worked, the next objective was to understand the mechanism behind the UART access lockout and find a way to bypass it, as we intended to use the device itself to debug key services and search for vulnerabilities.
\nIn the logs the serial port is /dev/ttyS1, so let’s search references to it:
\n➜ extractions grep -r ttyS1\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin: coincidencia en fichero binario\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin_3143840_aes_forward_table.raw: coincidencia en fichero binario\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin_3679760_unknown.raw: coincidencia en fichero binario\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin_3135648_aes_reverse_table.raw: coincidencia en fichero binario\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin.extracted/3F16A4/decompressed.bin: coincidencia en fichero binario\nhomestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin.extracted/3F16A4/decompressed.bin.extracted/0/etc_ro/inittab:ttyS1::askfirst:/sbin/login.sh\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin.extracted/3F16A4/decompressed.bin.extracted/0/bin/recover_0_elf.raw: coincidencia en fichero binario\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin.extracted/3F16A4/decompressed.bin.extracted/0/bin/recover: coincidencia en fichero binario\nhomestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin.extracted/3F16A4/decompressed.bin.extracted/0/sbin/makedevlinks.sh:mknod /dev/ttyS1 c 4 65\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin.extracted/3F16A4/decompressed.bin_0_cpio.raw: coincidencia en fichero binario\ngrep: homestation2_firmware00.bin.extracted/E70000/Linux_Kernel_Image.bin.extracted/0/decompressed.bin_3147936_aes_rcon.raw: coincidencia en fichero binario\ngrep: 7z_mandanga/homestation2_firmware00: coincidencia en fichero binarioThe key is in the inittab file, where we can see the it triggers the execution of /sbin/login.sh script once the user press “Enter” (the BusyBox askfirst action shows the prompt with sentence “Please press Enter to activate this console”). The script is simple as:
\n#!/bin/sh\n\nDEBUG_LOG="`nvram_get debug_log`"\nif [ "$DEBUG_LOG" = "1" -o -f "/mnt/enable_console" ];then\n echo "enter debug mode" > /dev/console\n /bin/login\nfiThe script checks if debug mode is enabled by checking the NVRAM variable debug_log and based on that allows the access to the shell (well, to login in the shell) or exits, entering in the loop.
We did not find a straight way to enable that variable and bypass the lockdown. There are various ways on changing the boot mode to enable “debug”, but all of them are far away from our hands because:
\nIt occurs to me at this point that if we can not bypass the check for whether it is booting in production or debug mode, why not completely obliterate the check and jump straight to a shell?
\nThe firmware did not contain anything encrypted, so should be straight forward to modify it to allow us direct access through the serial port. The problem was… Do you remember when I mentioned that it was “barely damaged”?. Well, we fucked 64kbs at 0x500000 which is the load address for the image.
At first, I thought our clumsy hands had ruined the project and that the idea of using the actual device for dynamic analysis with a debugger was slipping away (we would still have the option of trying to emulate some binaries, but having access to the original hardware is always infinitely easier). Fortunately, after analyzing the firmware layout a bit more, we discovered a much smaller “recovery image” that was still intact at 0xe70000. So, because the “normal” image was fucked, the bootloader would have to load this recovery image that we can manipulate to remove the UART lockdown.
The “recovery image” is a U-Boot image with a 64-byte header:
\n| Header offset | Length | Field | Original recovery value |
|---|---|---|---|
0x00 | 4 | Magic | 0x27051956 |
0x04 | 4 | Header CRC32 | 0xe764e161 |
0x08 | 4 | Timestamp | Preserved by the builder |
0x0c | 4 | Compressed payload length | 0x3455d9 = 3,429,849 |
0x10 | 4 | RAM load address | 0x80000000 |
0x14 | 4 | Entry address | 0x802e04f0 |
0x18 | 4 | Payload CRC32 | 0x19b650c3 |
0x1c | 4 | OS, architecture, type, compression | 05 05 02 03 |
0x20 | 32 | Image-name area | Preserved, including vendor-used bytes |
The actual filesystem is inside a matrioska of different compression layers that can be visualized in the following diagram:
\n![\"Matrioska](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/fs.png\")
Matrioska!
\nOnce the filesystem was unpacked, I made the minimal changes to allow us to jump directly to the shell with root privileges. To avoid headaches, I padded the modifications to match the same size it had the original code (code is from python script I used to perform the modifications and re-pack/fix CRCs):
\nold_condition = b'if [ "$DEBUG_LOG" = "1" ];then'\nnew_condition = b'if [ 1 = 1 ];then' + b' ' * 13\n\nold_login = b'\\t/bin/login\\n'\nnew_login = b'\\t/bin/sh \\n'After doing some local test to verify that the modified recovery image was correctly modified and it would unpack/load correctly we proceeded to overwrite it in the flash chip. In order to disable the Write Protection that appears in the documentation this connection diagram was followed:
\n![\"Diagram](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/diagram.jpg\")
Diagram to disable Write Protection
\nWriting the new recovery image:
\n![\"Writting](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/writting.png\")
Overwriting the recovery image with our backdoored version
\nThen we performed three reads to verify the process was done correctly. After that, the chip was solded again into the device board:
\n![\"Soldering](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/resolder.jpg\")
Soldering again the chip
\nOnce the chip was soldered I connected again my laptop to the device using a USB-TTL. First it tried to load the normal image, but it failed and then it jumped to backdoored recovery image and after loading it… we got a shell!!
\n![\"UART](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/uart-shell.png\")
Finally access to an admin shell!!
\nWe finally have a shell; the only problem is that the recovery image is very limited and the file system is not mounted, so the binaries and libraries needed to properly debug the system are missing. Furthermore, the kernel lacks certain modules-such as those responsible for handling WiFi interfaces or the I2C interface used to generate the WiFi key.
\nThe set of commands available in the default image is quite limited, but at least there are tools like wget, which allows us to transfer files from the laptop to the device. I prepared a crappy setup using an old TP-Link router that I got from Telefónica in 2015.
![\"Network](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/network.jpg\")
Not glamorous setup
\nI compiled a new BusyBox with loads of extra commands that were not present in the original one. Using this new BusyBox I started to try to create a “staged” filesystem and bind all the paths to this “staged” filesystem. I had to execute services needed to run before the big ELF in charge of main services (homeapp_security, the same binary that contained the WiFi logic), also because of memory limitations I had to modify some kernel parameters like overcommit_ratio. It was a three hours process of hit and miss until I could run the main binary and be able to interact with it.
Because this was a process that I would need to repeat each time I wanted to use the device (because the filesystem in the recovery image is not persistent, so after each boot I have to restore all) I shared the logs of picocom to Codex and asked it to prepare a all-in-one script that would repeat the same steps I did (and discard the stuff that didn’t work). To be honest, the following morning after that night of playing with the Homebase I barely remembered what I did, so having the logs was marvelous to rebuild and automatize the process. Keep logs of everything always, they will save your ass at some point.
The diagram of actions until the homeapp_security runs is the following:
![\"Diagram](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/recovery-image.png\")
Flow diagram from the patched firmware to getting the binary running
\nThe two most important scripts to rebuild the filesystem are shown below:
\n#!/bin/sh\n# Recovery UART bootstrap. Run with sh; do not source into the login shell.\n# Usage: sh homeapp-restore-v5.sh [http://PC:8000] [--start]\nPATH=/bin:/sbin:/usr/bin:/usr/sbin\nexport PATH\nunset LD_PRELOAD LD_LIBRARY_PATH\nBASE=/media/homeapp-debug\nROOT=$BASE/rootfs\nSERVER=http://192.168.90.112:8000\nSTART=no\nfail() { echo "homeapp-restore: $*" >&2; exit 1; }\nfor argument in "$@"; do\n case "$argument" in\n http://*) SERVER=${argument%/} ;;\n --start) START=yes ;;\n *) fail 'usage: sh homeapp-restore-v5.sh [http://PC:8000] [--start]' ;;\n esac\ndone\ncase "$SERVER" in *' '*|*'?'*|*'#'*) fail 'use a plain HTTP base URL without spaces/query/fragment' ;; esac\n[ "`awk '/^Uid:/ {print $3}' /proc/self/status`" = 0 ] || fail 'root effective UID required'\n[ -r /proc/self/mountinfo ] || fail '/proc/self/mountinfo is required'\n[ -c /dev/gpio ] && [ -c /dev/apsoc_nvram ] || fail 'expected recovery device nodes missing'\n\nmounted() { awk -v p="$1" '$2==p {n++} END {exit n==0}' /proc/mounts; }\ncheck_tmpfs() {\n awk -v p="$1" -v size="$2" '$2==p {\n n++; if ($3=="tmpfs") {\n count=split($4,a,","); for(i=1;i<=count;i++) if(a[i]=="size=" size "k") ok=1\n }\n } END {exit !(n==1 && ok)}' /proc/mounts\n}\nempty_dir() {\n [ ! -e "$1" ] && return 0\n [ -d "$1" ] && [ ! -L "$1" ] || return 1\n [ -z "`ls -A "$1"`" ]\n}\nasset_md5() {\n # BEGIN GENERATED ASSET HASHES\n case "$1" in\n busybox-extra) echo b587f623ef28b84e277fbd1b2b0b2348 ;;\n homeapp-enter) echo 8fde5ed1e3e65d07a7b9ebe672b25a5c ;;\n homeapp-mount-runtime.sh) echo 19e73a1584137c0d2150d6968cccb4c5 ;;\n homeapp-start-bounded-v4.sh) echo 19b70b8ac6751f8e161e490460ff8f3e ;;\n homeapp-control-v5.sh) echo 2fc7613db0f02a0d16c1417bb0282264 ;;\n homeapp_rootfs.tar.gz) echo bf6acaecf3301532bda2c1f6c41a3b2c ;;\n *) return 1 ;;\n esac\n # END GENERATED ASSET HASHES\n}\nverify() {\n expected=`asset_md5 "$1"` || fail "unknown asset: $1"\n actual=`md5sum "$2" | awk '{print $1}'`\n [ "$actual" = "$expected" ] || fail "checksum mismatch: $2; stop and check the PC bundle"\n}\nfetch() {\n asset=$1\n echo "homeapp-restore: downloading $asset"\n wget -O "$BASE/$asset.part" "$SERVER/$asset" || fail "download failed: $asset; partial setup preserved"\n verify "$asset" "$BASE/$asset.part"\n mv "$BASE/$asset.part" "$BASE/$asset" || fail "cannot finish $asset"\n}\nstamp() { awk '{sub(/^.*\\) /, ""); print $20}' "/proc/$1/stat" 2>/dev/null; }\nis_supervisor() {\n [ -r "/proc/$1/cmdline" ] || return 1\n tr '\\000' '\\n' < "/proc/$1/cmdline" | awk '\n NR==1 {shell=($0=="sh" || $0=="/bin/sh" || $0=="/sbin/run_mini_system.sh")}\n $0=="/sbin/run_mini_system.sh" {script=1}\n END {exit !(shell && script)}'\n}\nrecover_pids() {\n for procdir in /proc/[0-9]*; do\n [ -e "$procdir/exe" ] || continue\n if [ "$procdir/exe" -ef /bin/recover ] || [ "$procdir/exe" -ef /sbin/recover ]; then\n echo "${procdir#/proc/}"\n fi\n done\n}\nsignal_recover() {\n for recover_pid in `recover_pids`; do\n if [ "/proc/$recover_pid/exe" -ef /bin/recover ] || [ "/proc/$recover_pid/exe" -ef /sbin/recover ]; then\n kill "-$1" "$recover_pid" 2>/dev/null || :\n fi\n done\n}\ncoordinate_recovery() {\n # Exact argv matching avoids accidentally signalling grep or the UART shell.\n for procdir in /proc/[0-9]*; do\n supervisor_pid=${procdir#/proc/}\n if is_supervisor "$supervisor_pid"; then\n supervisor_stamp=`stamp "$supervisor_pid"`\n [ -n "$supervisor_stamp" ] || continue\n kill -STOP "$supervisor_pid" || fail "cannot pause recovery supervisor $supervisor_pid"\n echo "$supervisor_pid $supervisor_stamp" > "$BASE/recovery-supervisor-$supervisor_pid"\n echo "homeapp-restore: paused recovery supervisor $supervisor_pid"\n fi\n done\n signal_recover TERM\n sleep 2\n signal_recover KILL\n sleep 1\n [ -z "`recover_pids`" ] || fail 'recovery tasks survived stop'\n pidof recover >/dev/null 2>&1 && fail 'unrecognized recover process remains; inspect ps'\n return 0\n}\ninstall_commands() {\n for asset in homeapp-mount-runtime.sh homeapp-start-bounded-v4.sh homeapp-control-v5.sh; do\n verify "$asset" "$BASE/$asset"\n done\n # Rename new files into place: never truncate a script a running shell\n # may still be reading during a repeated preparation command.\n for asset in homeapp-mount-runtime.sh homeapp-start-bounded-v4.sh homeapp-control-v5.sh; do\n destination=/tmp/$asset\n [ "$asset" != homeapp-control-v5.sh ] || destination=/tmp/homeapp\n cp "$BASE/$asset" "$destination.part.$$" || fail "cannot copy $asset"\n chmod 755 "$destination.part.$$" || fail "cannot mark $asset executable"\n mv "$destination.part.$$" "$destination" || fail "cannot install $asset"\n done\n}\n\necho 'homeapp-restore revision: v5; original firmware applications, RAM staging'\nif [ -f "$BASE/restore-v5.ready" ]; then\n # Reusing this recipe's completed setup is safe; never extract over binds.\n check_tmpfs "$BASE" 65536 || fail 'staging mount changed or is stacked'\n check_tmpfs /media/mmcblk0p1 8192 || fail 'database mount changed or is stacked'\n verify homeapp-enter "$BASE/homeapp-enter"\n verify busybox-extra "$BASE/busybox-extra"\n install_commands\n sh /tmp/homeapp-mount-runtime.sh --resume || fail 'runtime mount verification failed'\n coordinate_recovery\n echo 'homeapp-restore: verified and reused completed setup; no archive download/extraction'\nelse\n # Fail closed on partial/manual setups; no rm -rf, unmount or overlay of data.\n mounted "$BASE" && fail 'unrecognized/partial staging mount; inspect it or reboot before retrying'\n empty_dir "$BASE" || fail 'staging directory is not empty; preserve it and inspect or reboot'\n mounted /media/mmcblk0p1 && fail 'database/storage path already mounted; will not cover it'\n empty_dir /media/mmcblk0p1 || fail 'database/storage directory is not empty; will not cover it'\n free_kb=`awk '/^MemFree:/ {print $2}' /proc/meminfo`\n [ "${free_kb:-0}" -ge 81920 ] || fail 'less than 80 MiB free; reboot to a fresh recovery shell or inspect memory'\n # Refuse existing normal services before staging/coordination.\n for service in home_security mdnsd mips_collector pushMuxer systemServer embdb_eufy; do\n pidof "$service" >/dev/null 2>&1 && fail "$service already running; use a fresh recovery boot"\n done\n original_mode=`cat /proc/sys/vm/overcommit_memory`\n original_ratio=`cat /proc/sys/vm/overcommit_ratio`\n if [ "$original_mode" = 2 ] && [ "$original_ratio" -lt 75 ]; then\n echo 75 > /proc/sys/vm/overcommit_ratio || fail 'cannot raise runtime commit ratio'\n echo "homeapp-restore: strict overcommit ratio $original_ratio -> 75 (this boot only)"\n fi\n if [ "$original_mode" = 2 ]; then\n headroom=`awk '/^CommitLimit:/ {limit=$2} /^Committed_AS:/ {used=$2} END {print limit-used}' /proc/meminfo`\n [ "$headroom" -ge 65536 ] || fail 'less than 64 MiB commitment headroom; no extraction attempted'\n fi\n mkdir -p "$BASE" || fail 'cannot create staging directory'\n mount -t tmpfs -o size=64m tmpfs "$BASE" || fail 'cannot mount staging tmpfs'\n check_tmpfs "$BASE" 65536 || fail 'unexpected staging filesystem size'\n echo "$original_mode $original_ratio" > "$BASE/original-overcommit"\n echo "$SERVER" > "$BASE/download-server"\n for asset in busybox-extra homeapp-enter homeapp-mount-runtime.sh homeapp-start-bounded-v4.sh homeapp-control-v5.sh; do\n fetch "$asset"\n done\n chmod 755 "$BASE/busybox-extra" "$BASE/homeapp-enter" || fail 'chmod failed'\n "$BASE/homeapp-enter" --check || fail 'native helper does not run'\n fetch homeapp_rootfs.tar.gz\n (cd "$BASE" && ./busybox-extra tar -xzf homeapp_rootfs.tar.gz) || fail 'extraction failed; preserve diagnostics, then reboot before retrying'\n # Only the verified temporary archive is removed, before any runtime binds.\n rm "$BASE/homeapp_rootfs.tar.gz" || fail 'cannot remove staged archive'\n "$BASE/homeapp-enter" "$ROOT" /bin/sh -c ':' || fail 'normal loader/BusyBox does not execute'\n mkdir -p /media/mmcblk0p1 || fail 'cannot create database path'\n mount -t tmpfs -o size=8m tmpfs /media/mmcblk0p1 || fail 'cannot mount temporary database'\n check_tmpfs /media/mmcblk0p1 8192 || fail 'unexpected database filesystem size'\n mkdir -p /media/mmcblk0p1/.sqlite || fail 'cannot create database directory'\n install_commands\n sh /tmp/homeapp-mount-runtime.sh --apply || fail 'runtime mount setup failed; earlier mounts preserved'\n coordinate_recovery\n echo v5 > "$BASE/restore-v5.ready" || fail 'cannot record successful setup'\nfi\necho 'homeapp-restore: READY. /tmp/homeapp start|status|logs|stop|shell'\necho 'Wi-Fi/I2C drivers and persistent flash configuration are not restored by userspace staging.'\ndf -k "$BASE" /media/mmcblk0p1\nif [ "$START" = yes ]; then\n /tmp/homeapp start || fail 'setup completed, but application startup failed; inspect /tmp/homeapp status'\nfi\n\n#!/bin/sh\n# Run with `sh`, never source into the interactive UART shell.\n# Does not start services, mount flash, or change memory policy.\nPATH=/bin:/sbin:/usr/bin:/usr/sbin\nexport PATH\nBASE=/media/homeapp-debug\nROOT=/media/homeapp-debug/rootfs\nfail() { echo "homeapp-mount: $*" >&2; exit 1; }\nmounted() { awk -v p="$1" '$2 == p {found=1} END {exit !found}' /proc/mounts; }\nsame_mount_root() {\n # Compare device ID and filesystem-root path, not just the filesystem type.\n awk -v s="$1" -v d="$2" '\n $5 == s {source=$3 " " $4}\n $5 == d {target=$3 " " $4; count++}\n END {exit !(count == 1 && source != "" && source == target)}\n ' /proc/self/mountinfo\n}\n\ncase "${1-}" in\n --inspect)\n echo '--- Mounts ---'\n cat /proc/mounts\n echo '--- Memory ---'\n cat /proc/meminfo\n echo '--- Overcommit mode / ratio ---'\n cat /proc/sys/vm/overcommit_memory /proc/sys/vm/overcommit_ratio\n echo '--- Staged executables ---'\n ls -l "$BASE/homeapp-enter" "$ROOT/bin/busybox" "$ROOT/bin/home_security"\n echo '--- Processes ---'\n ps\n exit 0\n ;;\n --apply|--resume) mode=$1 ;;\n *) fail 'usage: sh homeapp-mount-runtime.sh --inspect|--apply|--resume' ;;\nesac\n\nmounted "$BASE" || fail 'staging filesystem is not mounted'\n[ -x "$BASE/homeapp-enter" ] || fail 'native helper missing'\n[ -x "$ROOT/bin/home_security" ] || fail 'application missing'\nmounted /media/mmcblk0p1 || fail 'prepare temporary database mount first'\n[ -d /media/mmcblk0p1/.sqlite ] || fail 'database directory missing'\n\n# Resume only matching binds, with one mount at each staged destination.\n# Leave staged /mnt (including its original zx_log.conf) in place. Recovery's\n# /mnt bind failed in the first attempt; persistent state is a separate step.\nfor path in dev proc sys etc var tmp media dev/pts media/mmcblk0p1; do\n if mounted "$ROOT/$path"; then\n [ "$mode" = --resume ] || fail "$ROOT/$path already mounted; inspect partial setup first"\n same_mount_root "/$path" "$ROOT/$path" || fail "existing bind does not match /$path, or is stacked: $ROOT/$path"\n fi\ndone\n\nbind_path() {\n source_path=$1\n target_path=$2\n if mounted "$target_path"; then\n echo "homeapp-mount: keeping verified bind $target_path"\n return 0\n fi\n mkdir -p "$target_path" || fail "cannot create $target_path"\n echo "homeapp-mount: $source_path -> $target_path"\n mount -o bind "$source_path" "$target_path"\n rc=$?\n [ "$rc" -eq 0 ] || fail "mount exited $rc: $source_path -> $target_path (earlier mounts preserved)"\n mounted "$target_path" || fail "mount returned success but $target_path is absent from /proc/mounts"\n same_mount_root "$source_path" "$target_path" || fail "unexpected mount root at $target_path"\n}\nfor path in dev proc sys etc var tmp media; do\n bind_path "/$path" "$ROOT/$path"\ndone\nbind_path /dev/pts "$ROOT/dev/pts"\nbind_path /media/mmcblk0p1 "$ROOT/media/mmcblk0p1"\necho 'Runtime binds completed; no application services started.'Then running it from the UART shell we can see it prepares everything and also launch the binary:
\n# wget -O /tmp/homeapp-restore-v5.sh http://192.168.90.112:8000/homeapp-restore-\nv5.sh\nConnecting to 192.168.90.112:8000 (192.168.90.112:8000)\nhomeapp-restore-v5.s 100% |*******************************| 9174 --:--:-- ETA\n# sh /tmp/homeapp-restore-v5.sh http://192.168.90.112:8000 --start\nhomeapp-restore revision: v5; original firmware applications, RAM staging\nhomeapp-restore: strict overcommit ratio 50 -> 75 (this boot only)\nhomeapp-restore: downloading busybox-extra\nConnecting to 192.168.90.112:8000 (192.168.90.112:8000)\nbusybox-extra.part 100% |*******************************| 673k --:--:-- ETA\nhomeapp-restore: downloading homeapp-enter\nConnecting to 192.168.90.112:8000 (192.168.90.112:8000)\nhomeapp-enter.part 100% |*******************************| 622k --:--:-- ETA\nhomeapp-restore: downloading homeapp-mount-runtime.sh\nConnecting to 192.168.90.112:8000 (192.168.90.112:8000)\nhomeapp-mount-runtim 100% |*******************************| 3054 --:--:-- ETA\nhomeapp-restore: downloading homeapp-start-bounded-v4.sh\nConnecting to 192.168.90.112:8000 (192.168.90.112:8000)\nhomeapp-start-bounde 100% |*******************************| 4383 --:--:-- ETA\nhomeapp-restore: downloading homeapp-control-v5.sh\nConnecting to 192.168.90.112:8000 (192.168.90.112:8000)\nhomeapp-control-v5.s 100% |*******************************| 6488 --:--:-- ETA\nhomeapp-enter: running; uid=0 euid=0; static MIPS helper\nhomeapp-restore: downloading homeapp_rootfs.tar.gz\nConnecting to 192.168.90.112:8000 (192.168.90.112:8000)\nhomeapp_rootfs.tar.g 100% |*******************************| 14579k 00:00:00 ETA\nhomeapp-mount: /dev -> /media/homeapp-debug/rootfs/dev\nhomeapp-mount: /proc -> /media/homeapp-debug/rootfs/proc\nhomeapp-mount: /sys -> /media/homeapp-debug/rootfs/sys\nhomeapp-mount: /etc -> /media/homeapp-debug/rootfs/etc\nhomeapp-mount: /var -> /media/homeapp-debug/rootfs/var\nhomeapp-mount: /tmp -> /media/homeapp-debug/rootfs/tmp\nhomeapp-mount: /media -> /media/homeapp-debug/rootfs/media\nhomeapp-mount: /dev/pts -> /media/homeapp-debug/rootfs/dev/pts\nhomeapp-mount: /media/mmcblk0p1 -> /media/homeapp-debug/rootfs/media/mmcblk0p1\nRuntime binds completed; no application services started.\nhomeapp-restore: READY. /tmp/homeapp start|status|logs|stop|shell\nWi-Fi/I2C drivers and persistent flash configuration are not restored by userspace staging.\nFilesystem 1k-blocks Used Available Use% Mounted on\ntmpfs 65536 44844 20692 68% /media/homeapp-debug\ntmpfs 8192 0 8192 0% /media/mmcblk0p1\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/dev\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/proc\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/sys\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/etc\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/var\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/tmp\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/media\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/dev/pts\nhomeapp-mount: keeping verified bind /media/homeapp-debug/rootfs/media/mmcblk0p1\nRuntime binds completed; no application services started.\nhomeapp: launcher PID 5880; startup output: /media/mmcblk0p1/homeapp-launch-5565.log\nhomeapp: startup in progress; /tmp/homeapp status and /tmp/homeapp logs\nA running launcher is not proof of application or enrollment readiness.Finally we can see that the services are exposed!
\n# /media/homeapp-debug/busybox-extra netstat -lntup\nActive Internet connections (only servers)\nProto Recv-Q Send-Q Local Address Foreign Address State PID/Program name\ntcp 0 0 0.0.0.0:10400 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:10402 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:32290 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:10404 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:32292 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:32293 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:32295 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:10600 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:32392 0.0.0.0:* LISTEN 6016/home_security\ntcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 5974/pushMuxer\ntcp 0 0 127.0.0.1:5000 0.0.0.0:* LISTEN 5963/mips_collector\ntcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 5974/pushMuxer\ntcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1405/dnsmasq\ntcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 1693/telnetd\nnetstat: /proc/net/tcp6: No such file or directory\nudp 0 0 0.0.0.0:53 0.0.0.0:* 1405/dnsmasq\nudp 0 0 0.0.0.0:32380 0.0.0.0:* 6016/home_security\nudp 0 0 0.0.0.0:46217 0.0.0.0:* 6456/ntpclient\nudp 0 0 0.0.0.0:43466 0.0.0.0:* 1405/dnsmasq\nudp 0 0 0.0.0.0:21200 0.0.0.0:* 6016/home_security\nudp 0 0 0.0.0.0:29947 0.0.0.0:* 6016/home_security\nnetstat: /proc/net/udp6: No such file or directoryThe last thing was compiling a compatible version of GDB and upload it to the device to start playing :)
\n![\"GDB](\"https://adepts.of0x.cc/Eufy-Homestation2-firmware/gdb.png\")
GDB running on the Homebase2
\nOf course far more configurations changes are needed to make the binary work properly (e.g. I had to bridge an eth interface to create a br0 within the range it needs for the peers -long story short: it uses a peer table with MAC addresses to reject or accept communications), but with a debugger everything is far more easy. Just fire the process, check what fails, correct it or just hook it to feed with the values it’s expecting to continue the flow.
With the arrival of LLMs, I’ve lost all enthusiasm for publishing technical content. I’ve been publishing articles online since 2007 sharing things I learned or discovered using dozens of different aliases across various blogs and forums. That is nearly 20 years. And today, I’ve lost all desire to share my experiences.
\nFor one thing, there is the loss of value in writing if no one is going to read it. Nowadays, only a minority of people actually stop to read an article; most ask an AI for a summary or simply skim through without paying attention. There used to be an ecosystem where people spent time checking their RSS feeds (damn, I’m old) and reading articles from their favorite blogs or authors. The first major blow in this regard came from social media, where immediacy and “scoring Twitter points” became the primary driving force behind content creation.
\nThen there is the fact that the vast majority of published articles are generated directly by AI. Even interesting research pieces or vulnerability write-ups are churned out by automated looms, using that lobotomized language that gives me a stroke every time I try to read them. People seem delighted to gobble up such insubstantial crap. I suppose because it follows that first point. I write in “broken English” (yep, even though I’ve been working for a UK company for five years, my English is still terrible), yet I would a million times rather read an article written by a person in “broken English” than the umpteenth repetition of the same structures and stock phrases ChatGPT peppers its texts with.
\nThe final nail in the coffin is the fact that… does it even make sense in 2026 to keep publishing technical content for human readers? In the past, you’d read a lot of material (or even bookmark it for future reference) because it was genuinely useful. Perhaps you were tinkering with a product’s firmware that someone else had already explored; you could find that article and follow the trail they blazed. The same applied to vulnerability analysis: you’d read about others’ work so you could replicate it when you encountered a similar scenario. And I’m not just talking about specific products; I’m talking about methodologies: how someone solved a problem, allowing you to face the same situation years later and apply what you had read back then. With AI, this no longer makes sense; the world is turning into a collection of meat proxies prompting the latest LLM to resolve whatever snag or situation arises.
\nI obviously use AI in my professional work, but not to tackle my “hobby” projects (like the things I post on this blog). I need to clarify that last point: I use it, for instance, when I’m reverse-engineering something and come across a function that performs mathematical operations (like when I used it in the previous article to identify Reed-Solomon), or to automate a task I’ve already performed manually (e.g., in this very article, I used it to build a script based on commands I had executed and that were recorded in the log). I thoroughly enjoy my hobby, and I don’t want automation to rob me of those hours spent banging my head against the wall trying to figure something out, or that moment of pleasure when the penny drops and I have a “eureka” moment.
\nAbout a decade ago I remember reading Matasano’s cryptochallenges and this sentence stuck in my head since then: Breaking repeating-key XOR (“Vigenere”) statistically is obviously an academic exercise, a “Crypto 101” thing. But more people “know how” to break it than can actually break it.
\nI guess now we live in the world where everyone knows how to ask the LLM to hack something instead of actual knowing how to hack something.
\nAs usual, feel free to give us feedback at our twitter @AdeptsOf0xCC (although I lost the password and can’t access to the account anymore :D).
","headings":[{"level":1,"text":"A story of wifi secrets, UART lockdowns and a damaged flash memory chip","id":"a-story-of-wifi-secrets-uart-lockdowns-and-a-damaged-flash-memor"},{"level":1,"text":"Prayers at the foot of the Altar a.k.a. disclaimer","id":"prayers-at-the-foot-of-the-altar-a-k-a-disclaimer"},{"level":1,"text":"Table of contents","id":"table-of-contents"},{"level":1,"text":"0x00 Firmware extraction","id":"0x00-firmware-extraction"},{"level":1,"text":"0x01 Identifying the Wifi credential generation algorithm","id":"0x01-identifying-the-wifi-credential-generation-algorithm"},{"level":1,"text":"0x02 Rubber-hose treatment to the UART lockdown","id":"0x02-rubber-hose-treatment-to-the-uart-lockdown"},{"level":1,"text":"0x03 Filesystem gardening for debugging purposes","id":"0x03-filesystem-gardening-for-debugging-purposes"},{"level":1,"text":"0x04 Final words","id":"0x04-final-words"}]}}