I screwed up.

I finally did it, I figured out the commands to do a custom firmware, and I tried to flash it...now the camera is UNRESPONSIVE. It boots, but no network, the LED is on, can't talk to it, nada. I'm working on my backout plan now :) Hey, that's the price of hacking. Nevertheless, I've learned a TON which is worth sharing.

Below is the set of commands I used to generate my custom firmware. The original firmware is a tar.gz, which contains conprog.bin and rootfs.bin.gz, then rootfs.bin.gz unpacks into rootfs.bin which can be mounted with:

I then copied all the contents of that to ~/Projects/Blink/JoeFW.0.01/rootfs where I made some modifications (I added <p>test</p> to blinkhome.html). I then ran the following commands to repack the firmware to be uploaded:

So, I went to blinkhome.html, clicked firmware upgrade, then uploaded my new firmware...it uploaded successfully and said it flashed, but then it never came back on.

Now, this is probably my fault...I actually screwed up my tar command in a rev 1.0 and added full path to my rootfs...so it was /home/surfrock66/Projects/Blink/rootfs/~ and I believe the flash just copied the whole thing as is, so I may have filled up the storage on there with a full 2nd copy of the firmware. FAIL.

That being said, there's still more work to do. I began analyzing the rest of the firmware, and specifically the executables in there.

I wanted to start analyzing the firmware update binaries. Assume the root of the rootfs, in /mlsrb_src/ there is fwupgrade and otatest. I wanted to see if I could figure out how the upgrade works to see if there's anything I missed, and see how the auto-online-upgrade works to see if I can't download the actual firmwares from motorola. I started with this command, which produced the following output:

I'm planning on installing the ELDK to figure out some of the stuff in there, but before that, I started dumping strings from the binaries to see what I could find. I'm not outputting all of it here, but some of it will be curious to you:

Some Interesting Snippets, first from fwupdate:

HMM. An MD5 check? then my firmware shouldn't have flashed, right? So how did I break it?

Now, onto otatest, which is FASCINATING:

VERY interesting stuff. That ota.monitoreverywhere.com/ota/cam_patch site has a password wall...but look below, on a hunch I tried msc2000 as the username and patch2012 as the password, and it WORKED..but there's no files hosted. I assume you have to pass some sort of info over POST/GET, I bet I'll find out more when I get to decompiling. bms.monitoreverywhere.com/BMS goes to the client portal, with an outdated SSL cert I might add, which is a little bit of a cooler interface. I tried the other URL's in there, they go nowhere I can find, and I tried a few different ports.

Lastly, I looked at online_upgrade...nothing particularly interesting there. I also did see a file in /mlsrb_src called "mjpg_streamer_iball" (IT'S GPL MOTOROLA YOU HAVE TO RELEASE THE SOURCE >:[ ) and I string'd that, which turned up some new commands and confirmed some others:

• GET /?action=snapshot
• GET /?action=log
• GET /?action=device_status
• GET /?action=mini_device_status
• GET /?action=stream
• GET /?action=appletvastream
• GET /?action=appletvstream
• GET /?action=appletastream
• GET /?action=command

I THINK I also found the full list of commands that can be received in the device. It's a big list, but we need to dump it...since these are just strings, they could mean nothing, but I'm trying to capture an ordered list that encompasses commands I already found:

• leaving
• contrast_plus
• contrast_minus
• brightness_plus
• brightness_minus
• value_contract
• value_brightness
• set_contract
• set_brightness
• VGA640_480
• QVGA320_240
• QQVGA160_120
• setup_wireless_save
• value_resolution
• get_storage_folder
• set_storage_folder
• move_forward
• move_backward
• move_left
• move_right
• move_forward_cont
• move_backward_cont
• move_left_cont
• move_right_cont
• fb_stop
• lr_stop
• setup_led0
• setup_led1
• value_setupled
• audio_out1
• audio_out0
• value_wifi
• value_battery
• restart_system
• restart_app
• melody1
• melody2
• melody3
• melody4
• melody5
• melodystop
• value_melody
• value_temperature
• reset_factory
• switch_to_uap
• uapconfig_read
• uapconfig_save
• vox_get_threshold
• vox_set_threshold
• vox_enable
• vox_disable
• vox_get_status
• get_version
• get_default_version
• flipup
• save_camera_name
• get_spk_volume
• check_cam_ready
• set_master_key
• set_random_number
• set_random_number2
• get_session_key
• check_upnp
• reset_upnp
• set_upnp_port
• get_upnp_port
• set_register
• get_register
• get_log
• set_log_level
• pcmlog_enable
• pcmlog_disable
• set_audio_finetune
• get_audio_finetune
• save_http_usr_passwd
• set_sensor_register
• get_sensor_register
• get_sessionkey
• enable_telnet
• set_delay_output
• get_hw_version
• take_snapshot
• get_routers_list
• check_fw_upgrade
• request_fw_upgrade
• get_mac_address
• get_mac_in_flash
• set_mac_in_flash
• set_temp_alert
• set_int_internet_connected
• get_debug_val1
• set_debug_val1
• set_temp_offset
• get_temp_offset
• set_remote_ip
• get_codecs_support

LASTLY, I got an email from a dude working on this as well...he said he has a BlinkHD, and his RTSP stream is asking for a username and password...I found this in the mjpg_streamer_iball strings:

Happy Hacking!

Related Posts:

• Improving the Motorola Blink Baby Monitor/Camera
• Improving the Motorola Blink Baby Monitor/Camera (Part 2)
• Improving the Motorola Blink Baby Monitor/Camera (Part 3)
• Improving the Motorola Blink Baby Monitor/Camera (Part 5)

This entry was posted on Sunday, November 2nd, 2014 at 6:39 pm and is filed under Geek, Projects.
You can leave a response, or trackback from your own site.