Support for Xiaomis new Arlo-clone CMSXJ11A?

Thanks a lot, system seems to be up and running. Used BREED (which I had installed as an upgrade to the crippled U-BOOT with more commands) to replace the bootloader and U-BOOT Option 2 to load and flash from TFTP

Need to do some thorough examination tomorrow but it looks good: connecting directly by LAN with telnet possible, CAM connect and live view work etc.

Will try to use my local MQTT installation to track the requests, maybe we do not even have to modify the squashfs when connection to remote MQTT server is possible in parallel by an additional mqttclient (or using a local instance as a forwarder/redirector).

yours is still connected to the cloud?

i saw evil binary /usr/bin/test_hub which is probably run somehow via p2p exec after cloud connection. it does 3 things:

  • change password for chuangmi-hub-XXXX to random
  • set model via “uci set system.product.model=release”, later used by by /etc/init.d/test-hub to decide if telnetd should be running (only when model = debug)
  • close uart via /sbin/close_uart.sh (#::askconsole:/bin/ash --login)

ppl have already telnetd disabled after cloud connection. now i think what’s the best way to avoid it.

Yes, I’m still connected:

[20200615 02:08:26] [D] method_local_broadcast_msg(), {“method”: “local.status”, “params”: “cloud_connected”}

I managed to capture the motion events and upload requests of the files via MQTT which allows to have the status etc. available on an MQTT Server.

Motion detection:
{“id”:5174349,“method”:“event.motion1”,“params”:[“2020/06/17/987654321/5309307225_055003386.mp4”,“xxxxxxxx”,“2020/06/17/1903657091/5309307225_055002985.jpeg”,“xxxxxxxx”,"",“1”]}

The status can actively be requested via MQTT message:

{“from”:“4”,“id”:22,“method”:“get_camera_prop”,“params”:[“CAM-ID”,1]}

Response:
{“id”:22,“result”:[{“mac”:“AABBCCDDEEFFGG”,“name”:“CAM1”,“wifi”:1,“battery”:40,“battery_status”:1,“pir”:0,“version”:“10030”,“hardver”:“110100”,“power”:0,“night”:0,“event”:“motion”}]}

For the JPG and MP4 files: I added a second http instance which allows direct access to files stored on the SDCARD.

I still need to figure out the relationship between the events and the filenames as the stored files are following an other convention as the uploaded files and I need to find a way to match both and I need to identify the different cameras

The changes so far are simple:

1.) I configured mosquitto to act as a MQTT bridge and forward the messages to my local MQTT server
2.) I added a second uhttpd instance on port 8881 for accessing the media files
3.) I enabled additional miio_client logging to sdcard - the binary is responsible for transforming the camera requests to MQTT

As for test_hub: I could not find any application which calls this binary. Although test-hub.sh etc. is checking for relesase/debug, it seems that it’s never called which is diametral to what you reported about user lockouts. As a result, I still have telnet access.

To workaround a possible lockout, I’m going to enable cgi-bin for the new media instance of uhttpd, allowing to reactivate telnetd whenever necessary :wink:

from my understanding they can run any binary using p2p connection sending binary path (for example /usr/bin/test_hub). few ppl i checked with can connect to camera network, ping it, even access uhttpd server (where they host camera ota), but telnetd isn’t running.

can you share custom bootloader? with breed you can always restore if something goes south, right?

In this case the only useful solution would be to rename the binary to avoid execution. Nevertheless I will try to test the cgi-bin solution for reactivation by resetting the model code to debug.

I do not have a special bootloader any longer. I used my installed breed bootloader to install the stock bootloader you provided.

U-Boot 1.1.3 (Jul 23 2018 - 21:02:41)


Board: Moobox Hodor Hub DRAM:  64 MB

relocate_code Pointer at: 83f68000

******************************

Software System Reset Occurred

******************************

flash manufacture id: ef, device id 40 18

find flash: W25Q128BV

============================================ 

Hodor Hub UBoot Version: 1.0.1.0

-------------------------------------------- 

ASIC 7628_MP (Port5<->None)

DRAM component: 512 Mbits DDR, width 16

DRAM bus: 16 bit

Total memory: 64 MBytes

Flash component: SPI Flash

Date:Jul 23 2018  Time:21:02:41

============================================ 

icache: sets:512, ways:4, linesz:32 ,total:65536

dcache: sets:256, ways:4, linesz:32 ,total:32768 


 ##### The CPU freq = 575 MHZ #### 

 estimate memory size =64 Mbytes

RESET MT7628 PHY!!!!!!

Please choose the operation: 

   1: Load system code to SDRAM via TFTP. 

   2: Load system code then write to Flash via TFTP. 

   3: Boot system code via Flash (default).

   4: Entr boot command line interface.

   7: Load Boot Loader code then write to Flash via Serial. 

   9: Load Boot Loader code then write to Flash via TFTP.

Then I used UBoot option 2 to flash the squashfs

I tested a full UBoot version and BREED because of the missing write/export commands in the moobox version but it’s no longer necessary. On the other hand, BREED allows bootloader/firmware updates via web interface

i thought about changing the files via overlay. there is also 2nd binary they may run /usr/bin/command_hub which is responsible for write and verify p2p/cloud credentials (it can reset jffs2 data). in long term would be good if we can flash our own sqashfs and it should not be hard to test if you can write it using bootloader.

For the moment, I created 3 cgi shell scripts: killtelnet (for testing), starttelnetd and processlist for getting the processlist. Therefore I can reactivate the telnetd via web interface in case it is disabled. Didn’t check the overlay approach so far.

BTW; I reflashed breed bootloader and neither leds work nor is the hub recognized in the app. Simply replacing the bootloader by the stock version made it work again, therefore at least breed is not an option or there are too many changes although it’s a MT7628 but the breed bootloader might be not matching exactly. Therefore I’m refraining from doing further test in this direction. And I did this only to get the root access at that time :wink:

There is an interesting thing I came across: at the very first tests with the original bootloader I did not get a shell in the terminal but a sandbox infinite loop, therefore no access to the filesystem. Meanwhile it always boots into a shell when using the serial terminal connection. Not clear what caused this change…

There is also the mtd tool available which I used to save all mtds. While this can be used to write the mtds too, I doubt this will work from within the running system :slight_smile: But there is a sysupgrade script in /sbin I’m going to test which seems to support an in-place upgrade

they do update via sysupgrade. strip 0x80 header from ota (after checking md5) and write kernel+rootfs (till HODOR3 header which starts camera ota file) to /tmp/hub_upgrade.bin, then simply start sysupgrade /tmp/hub_upgrade.bin. we just need to figure out right params for squashfs repack (some can be found with unsquashfs -s). i saw similar padding/mark (DE AD C0 DE) in openwrt for some routers like archer c7.

Have seen this too and most of the files I have, seem to include also metada but I consider them optionalsquashfs

i think it depends on device, but this cam does not use any meta. just kernel+rootfs+padding.

Hi,
Very nice investigation here, thank for sharing this.
@ajsimon Could you share an How-to on github with your cgi scripts ?

Is there any follow up on this ? I cannot login via telnet/ssh, even if the gateway is not yet configured on Xiaomi home. The only thing that works is access to the gateway via serial-to-usb, pressing ‘f’ at boot time to land in the root shell. Unfortunately in this failsafe mode nothing is yet configured, no network interface, etc.

However, I managed to dump the partitions using an sd card. It seems that the only way to be able to access the box in normal operation mode is to modify the rootfs partition (squashfs), which so far seems quite dangerous to me, as parameters are not available.

Could maybe @rezmus or @ajsimon or anyone else share some light ?

was your cam brand new? what is the production date? are you able to connect to chuangmi-gateway-ipc011_XXXX, but telnet service is not running? check /etc/config/system from overlay if there is

option model 'debug'

@rezmus thanks for reply !

Cam and gateway are brand new. Ninitially I could connect to the chuangmi-gateway-ipc011_XXXX ap (no password required) but telnet/ssh services not running. Also not on other ports (checked with nmap).

As I said I have a dump and in the rootfs dump (mtd5) I can see /overlay entry. I think overlay is mtd6 (jffs2) but I’m unable to mount or extract files; not to talk about repacking… Any ideas ?

Again thanks for help !

i was able to mount mine with

sudo modprobe mtdblock
sudo modprobe mtdram total_size=960
sudo dd if=ipc011/mtd6.bin of=/dev/mtdblock0 bs=1
mkdir mount
sudo mount -t jffs2 /dev/mtdblock0 mount

I assume you mean the rootfs_data partition, right ? Let me test and report that.

Edit: I’ve tried already this with the jffs2 of mtd6 (rootfs_data). I can see some files in /etc and /mnt, but I cannot open them. Dmesg gives me lots of these:

[71451.849933] jffs2: compression type 0x08 not available
[71451.849934] jffs2: Error: jffs2_decompress returned -5

Checking jffs2 for standard compression (jffs2.h) reveals that compression method 8 is undefined… What compression is yours ? Maybe I could force this somehow ?

Thanks again !

Ok, tried using binwalk -Me rootfs_data.bin. This brought me to jefferson (https://github.com/sviehb/jefferson), which finally extracts the jffs2 partition, but without any filesystem structure…

Let’s see what the files look like :). I’ll get back…

i never checked the content and had same issue :wink: but i was able to unpack with jefferson and can access overlay files. make sure to install python-lzma because it looks like lzma is used here.

Yep, I used jefferson and got the files. But there are many more files… Interesting findings so far:

fs_107/etc/config/system: option model debug
fs_9/.system.uci-YE9eL1: option model ‘release’

Also, I’ve got the password of chuangmi-hub-E7D1 and could sign in the wifi network (see fs_10/.wireless.uci-jCBQck)… But, no ssh/telnet available ;). What now ??? Are there other hidden wifi aps ?

with model debug telnet service should start. try to dig how to make lzma jffs2 properly mounted so you can change it (maybe openwrt router).

you should also check rootfs /etc/init.d/test-hub if there is code to run telnetd

    dev_model=$(uci get system.product.model)
    echo dev_model=$dev_model
    if [ $dev_model == "debug" ]; then
        echo "run telnetd"
        telnetd
    fi