Image 2 Brick

[tobilap]

Just bricked some of my cameras by applying the hacks from Image 2 on the v3 firmware. Works fine until you reboot. Camera bricked, orange light stays on, no network activity, even when removing the card. I suppose i need to open the cameras to get serial access.

Just noticed that there is a B written on the processor xD

[samtap]

Sorry to hear that. I've applied the image on a couple of camera's and it worked for me, but it does all depend on the state of various files before you insert the sd-card with the new image. Did you make any modifications yourself? If the fang_hacks.sh script is already on the device, you cannot apply the hack on the status page but you must click 'Apply updates from sd-card' on the status page to copy the new scripts to the device. It would be interesting to find out exactly what went wrong so I can add some protections.

The device should still automatically mount vfat partitions on sdcard, even if everything went tits up with the scripting, cloud apps don't start etc. So you can use snx_autorun.sh to start a telnetd. If the fang_hacks.sh script still runs at boot, you can also rename the *.tmpl files in the bootstrap folder and they will get copied to the device by fang_hacks.sh. This requires the new version of fang_hacks.sh to be on the device...

If you're able to get in, can you please share the contents of /tmp/hacks.log

[Vennerstrand]

I have just installed 2 cameras with latest firmware using image 2. Working nicely. No other customizations. However, rebooting without sd-card and the unit does not do anything useful. Does not connect to network. Rebooting with sd-card brings it up again.

[samtap]

@Vennerstrand Interesting, I didn't think to test booting without sd-card :P. I'm assuming you didn't disable cloud apps? Since if you did that it's obvious nothing is started.

[tobilap]

I applied it to a one i have been using for about a week( only rtsp modifications) and a completely new one. Ill try a few things to get it up and running again. I made an SD Dump right after I noticed the brick and i'll upload it soon.

[Vennerstrand]

@samtap According to README.md rebooting without sd-card should bring back original behavior. Unsure about that. At first, I left the cloud apps running, but it does not change the no sd-card reboot behavior. It will not connect to cloud once hack has been applied. I have not tested to revert hack though. So, DISABLE_CLOUD 1 or 0 does not seem to have any affect on the no sd-card boot.

[samtap]

@Vennerstrand That statement is only still true if DISABLE_CLOUD=0, I'll update README

[tobilap]

The software must still be running. Even though I do net see any network activity the IR Script is running as i can trigger the IR lights(by covering the cam)

[Vennerstrand]

@samtap Makes sense. I have not manage to have cloud functionality (device showing as online in Mi Home app) once HACKS_ENABLED is set. I will try on a third unit. Maybe its a fw 3 issue? I updated both of mine before applying hack.

[samtap]

@tobilap You'll get that if you use NETWORK_MODE=0 (Cloud) and DISABLE_CLOUD=1. You can't disable cloud and still expect network to be configured by cloud apps. Or perhaps something went wrong with configuring/setting WiFi Client settings? There's also a known issue with AP mode (udhcpd isn't started, fixed on git but not yet in image) but a reboot should bring the previous configuration back online.

@Vennerstrand I haven't had issues with cloud app. You can even change SSID/passphrase of cloud-mode on the webif and the app will take a while (presumably sync the changes) but eventually connects.

[tobilap]

Tried multiple configurations, and of course id did not disable the cloud and use cloud mode at the same time oO. Still no activity. Ill setup a kali and start airodump to check if there is no network activity at all or its just some messed up config.

[samtap]

Ok just checking ;-). In case it still runs the snx_autorun.sh (which it should, kernel hotplug doesn't depend on cloud apps or network connectivity), you can probably get network up by placing the right commands in that script.

• You'll need to mount /dev/mmcblk0p2 if it isn't auto-mounted: mount /dev/mmcblk0p2 /media/mmcblk0p2
• Then run /media/mmcblk0p2/data/etc/scripts/01-network connect YourSSID YourPass
• Then start a telnetd to get in Note the manual wifi connection doesn't stick, it's lost after a reboot.

[samtap]

@Vennerstrand I did some testing with booting without the sdcard but could not find anything unexpected.

• If DISABLE_CLOUD=1, it boots but doesn't start anything so not very useful
• If DISABLE_CLOUD=0, it boots, doesn't detect the sdcard and works more or less as if HACKS_ENABLE=0. Cloud apps are started, brings wlan0 online, starts boa and I can connect normally with the Mi Home app and use the webinterface.

Note that by default the 00-stop-cloud script is enabled. So if you have DISABLE_CLOUD=0 and the sd-card is available, the cloud apps are started normally but terminated by the stop-cloud script on the sdcard. If you want to keep the cloud apps alive you'll need to disable the 00-stop-loud script using the webif (or remove its execute-bit manually). And probably also disable rtsp-server since it doesn't start when cloud apps are running.

[Vennerstrand]

@samtap I will give it another go here. I was expecting it to work as you are describing. Thanks for testing it!

[samtap]

Did find a small bug where cloud wifi settings are still applied even though a custom network mode is configured. Created new issue #18

[GunterTubo]

I confirm that I too was blocked xiaomi after 2 or 3 reboot to the problem of partition. Now it does not start and the LED remains yellow always

[iopaza]

Hi, Mine is Brick too, yellow light always on, no network. I 'll try to modify the in sd card Etc/scriots/ 01-network but not wifi appear in my routeur. is there a solution with making a new image to unbrick?

[samtap]

@iopaza The 01-network script is among the last to run. You are better off changing snx_autorun.sh to debug. You could for example add a bunch of commands to extract information from the device and write it to a logfile on sd-card. Also see my previous comment regarding tmpl files.

It appears to work for most so I have no idea what the issue is. One of you has to figure it out! I can only make a new image if I know what problem to fix.

[iopaza]

@samtap Coul you give me the right command i have to add in snx_autorun.sh, because i'm a newbie in prog/ i understood i use to add "mount /dev/mmcblk0p2" or "mount /dev/mmcblk0p2 /media/mmcblk0p2" if the first does not work, but i'dont know where in the script it'll be write ( i'm using notepad ^^) Then i have to add "run /media/mmcblk0p2/data/etc/scripts/01-network connect YourSSID YourPass" in the script i suppose "YourSSID YourPass" to be replace by my real SSID and Password. Finally i have to extablish a telnet connection with Filezilla or Putty for example to modify directly something but which file ? thanks a lot for your help

[GunterTubo]

does anyone know how unbrick camera ? thanks

[samtap]

@iopaza If you are not comfortable with typing commands in a shell it's probably a better idea to wait until we get to the bottom of this and find a solution.

@tobilap Any progress on the serial console?

I'm in #fanghacks on irc.freenode.net in case anyone needs help or info on how to debug. But since I can't reproduce the issue I have no idea why it's not working for you. Perhaps someone should write down exactly what he did, step by step in great detail, and maybe I can spot an error?

[samtap]

To make some progress on this, anyone able to run this? Save as snx_autorun.sh on the vfat partition, insert sdcard after the device is booted. Listen for the hammer sounds, wait a bit and then put the sdcard in a pc, zip the files and upload them to mega (or better: a pastebin site)

#!/bin/sh
LOGDIR="/media/$MDEV/logs"
mkdir -p "$LOGDIR"

cp /etc/fang_hacks.sh "$LOGDIR"
cp /etc/fang_hacks.cfg "$LOGDIR"
cp /etc/os-release "$LOGDIR"
cp /tmp/hacks.log "$LOGDIR"
cp /var/log/* "$LOGDIR"
ifconfig >> "$LOGDIR/ifconfig.log"
iwconfig >> "$LOGDIR/iwconfig.log"
mount >> "$LOGDIR/mount.log"
ps >> "$LOGDIR/ps.log"
dmesg >> "$LOGDIR/dmesg.log"

[GunterTubo]

the problem is that the camera turns on but is unable to boot ... the status LED remains yellow and is not read sd

[samtap]

Ok I thought someone said it just didn't bring network online...

You can force a firmware flash by keeping the setup button pressed when you apply power. It will look for FIRMWARE_660R.bin. Anyone have the guts to try this? A link to the firmware can be found in the comments here: https://github.com/fritz-smh/yi-hack/issues/118

[GunterTubo]

I would try. where do I find the firmware and instructions?

[Gilgameshismist]

Firmware is available from here: http://111.206.200.99/miio_fw/12c424a07178dceedb4b05130f736757_upd_isa.camera.isc5.bin?GalaxyAccessKeyId=5721718224520&Expires=1492660635000&Signature=1aVB53HQ4pUdZaalxySJfiCb9Ag=

If I can infer the SDK correctly this is the procedure: Just rename it FIRMWARE_660R.bin and put it on (the root of) a clean sd card. Now do the following steps: Unplug your camera, insert SD, push (and hold) reset button, insert power lead, wait a few seconds, release reset button. let the camera do the firmware update. [edit] Tested this method and renaming the bin "FIRMWARE_660R_F.BIN". Did not work! [/edit]

[GunterTubo]

I followed the steps but the camera still does not see the sd device should be reset via serial

[phtp]

I have no idea what I'm doing, but I dumped the ROM from my Camera running version 2.9.0.7 and in there I spotted another file name. Try "FIRMWARE_660R_F.BIN"?

[Gilgameshismist]

Tested several methods updating the firmware using the sd card. Both naming it FIRMWARE_660R.bin and FIRMWARE_660R_F.bin didn't work. Tried from boot (holding the reset button while booting), tried from booted camera. Niether one was effective.

I checked the dumped iCamera binary (which is referencing FIRMWARE_660R.bin) and this is handling the firmware update. but I can't seem to do the right "magical dance" to get it started.

(further info: test device was on firmware 2.8.3.5 the bin was the 3.0.3.56 intercepted by MacManas)

[samtap]

The bootloader looks for a file to flash long before iCamera starts. Though it is possible that it expects a slightly different image and the one downloaded by the app isn't compatible? I haven't tried since my camera is working fine...

U-Boot 2011.09 (Oct 25 2016 - 01:22:49)

DRAM:  64 MiB
MMC:   MMC: 0
SPI FLASH: 16 MB
In:    serial
Out:   serial
Err:   serial

Partition Map for MMC device 0  --   Partition Type: DOS

Partition     Start Sector     Num Sectors     Type
    1                 2048          204800       b
    2               206848        15316992      83
reading FIRMWARE_660R.bin

** Unable to read "FIRMWARE_660R.bin" from mmc 0:1 **
reading FIRMWARE_660R.bin

** Unable to read "FIRMWARE_660R.bin" from mmc 0:2 **
sd_update_fail: no FIRMWARE_660R.bin in the sd

Partition Map for MMC device 0  --   Partition Type: DOS

Partition     Start Sector     Num Sectors     Type
    1                 2048          204800       b
    2               206848        15316992      83
reading FIRMWARE_660R_F.bin

** Unable to read "FIRMWARE_660R_F.bin" from mmc 0:1 **
reading FIRMWARE_660R_F.bin

** Unable to read "FIRMWARE_660R_F.bin" from mmc 0:2 **
sd_update_fail: no FIRMWARE_660R_F.bin in the sd
ERROR: update FIRMWARE_F.bin from sd failed
Hit any key to stop autoboot:  0
roofsr size = 0x6d3070
## Booting kernel from Legacy Image at 00008000 ...
   Image Name:   Linux-2.6.35.12
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3038112 Bytes = 2.9 MiB
   Load Address: 00008000
   Entry Point:  00008040
   Verifying Checksum ... OK
   XIP Kernel Image ... OK
OK

[Gilgameshismist]

My cams are working fine too, but they are all on 2.8 since I don't feel for updating yet. I just gave it a try. Interesting that u-boot is searching for the same files. It could be that the OTA bin is different.

[samtap]

If I don't get any more feedback on these issues I'm going to close it.

[tobilap]

For me the issue has been resolved. Accessing the camera using serial and starting the "china daemon" manually brought the cam back to life.

[GunterTubo]

tobilap can share a guide on how to connect the serial? Thank you

[tobilap]

Yeah sure, I can make a tutorial on how to disassemble without damaging anything and connecting the serial. You just need to remove 2+3 screws to get good access to the serial port on the camera.

[GunterTubo]

Thanks look forward to your tutorial useful for everyone in the future, what program you used to reprogram (term, etc) where to get the hardware for the serial / usb and if you can also put some pictures if you have Thanks again

[samtap]

I don't think serial console is required to fix this. You can run anything from snx_autorun.sh and also replace /etc/fang_hacks.cfg by renaming the template in the bootstrap folder.

[tobilap]

@samtap 1st I agree but 2nd. I don"t agree. This did not help in my case. No matter what I wrote into the config file. It got ignored.

@GunterTubo Quickly recorded a video ( https://www.youtube.com/watch?v=TsuCepL7b5U ). I'll add another video for "how to work with the serial" in a few days.

[phtp]

@GunterTubo check out this post for the serial pins https://github.com/fritz-smh/yi-hack/issues/118#issuecomment-271596240.

[samtap]

When @tobilap said starting the china daemon brought it back to life, I'm guessing it wasn't really 'bricked' at all but just didn't connect to WiFi. With the factory settings, iSC3S manages the wifi interface. If you get rid of iSC3S and the network scripts on the sd-card fail for whatever reason (bug or mis-configuration), you'll be stuck with a camera that you can't connect to.

There're two ways to get rid of iSC3S: using the 00-stop-cloud script or by setting DISABLE_CLOUD=1 in /etc/fang-hacks.cfg. When you rename the fang-hacks-rescue.cfg.tmpl (removing .tmpl from the filename), it will get copied to /etc/fang-hacks.cfg during boot and activated after a reboot and set DISABLE_CLOUD=0. The 00-stop-cloud script exists to stop iSC3S after it establishes a connection. If it fails to do that in time, for whatever reason, it will still get stopped. It worked reliably for me but perhaps some AP's take longer to connect to? You can disable the script from snx_autorun.sh but it's a bit more involved since you have to wait for the ext2 partition to get mounted and then run chmod to remove the execute bit. Either way, booting without sdcard means the stop-cloud script isn't even available to run so that would be an easy workaround for getting back access to the device.

Since I've release the v0.2.0 image I've identified a couple of ways to completely screw everything up. I'll be adding check for these in a next release.

• If you've used the first image (or manually tinkered with the device) it's completely possible and likely that the hack isn't applied correctly. If /etc/fang_hacks.sh already exists (from the first image) you will not be able to apply the hack using the status page, but you must use the update button to copy the v0.2.0 scripts to the device before a reboot.
• If you use the resize feature, you must wait for resize2fs to complete after rebooting (you can monitor it using the process list on the status page). While it is resizing, the data partition isn't mounted but all CGI scripts are still available since they live on the vfat partition that isn't resized. It will appear like nothing is working on the scripts page, so many people are tempted to reboot. A reboot will kill resize2fs before it completes, likely leaving your sdcard in a corrupted state. You must complete a successful resize to remove a file (/etc/.resize_runonce) or it will attempt the resize at every boot increasing probability to screw up the sdcard, if it wasn't already.
• The network page allows you to circumvent iSC3S network configuration. I'm sure it is not very robust, though the only real issue that's been reported is that SSID's with spaces aren't handled correctly. To use WiFi client mode, you must first successfully connect to an SSID before the apply button is activated. The connect button simply runs /media/mmcblk0p2/data/etc/scripts/01-network connect [SSID] [Passphrase] (you can run this from i.e. snx_autorun.sh as well to attempt a manual connection). If you didn't use the network page but directly configured wpa_supplicant.conf and set NETWORK_MODE=1 in /etc/fang_hacks.cfg, the only way to test it is to reboot and if it doesn't work you'll be unable to access the device. The access-point mode also has a bug, where udhcpd can't be started (because it's not in the PATH of boa which executes the cgi scripts). But that should be resolved by a reboot, when the network script is executed at boot it has a different PATH and works fine.
• It's normal for the led to stay yellow if iSC3S doesn't run. I plan to add some code to set the led to different colors etc. while my scripts are running to give some feedback on the state of the device.

[GunterTubo]

@tobilap Thank you very much!

[GunterTubo]

ok restored and now it works

[noname1020]

After install v2 hack,my camera also bricked with only steady yellow light on,was able to bring it back by use samtap's scripts fang-hacks-rescue.cfg and then press setup button,reboot,yellow light start to blink follow with voice prompt,now it is working.

[Perksls]

I've had the same yellow light always on, it happened when I tried to change the ssid, maybe it didn't stick, don't know, but I've also managed the recovered it using the same method as @noname1020

Thank you very much @samtap

[minomoto]

the same story with bricked cam: what I did - rm /etc/fang* by ssh. For what? I lost connection with cloud after last update. As result no visible activity except yellow led. Tried: to rename fang_hacks_rescue.cfg, to change network mode in fang_hacks.cfg to add ssid information in wpa_supplicant.conf. Thanks a lot in advance for LED indication in next release. Remains to look for a console cable at the moment.

[Cr4z33]

Sorry for the noob question, but I don't want to waste € 10,00.

Is it correct that if I have a static orange LED on the only way to recover is by a serial connection?

And if yes should the following device do the work? https://www.amazon.co.uk/dp/B00AFRXKFU

[TimDowker]

@samtap could you outline this process a bit more clearly?

"When you rename the fang-hacks-rescue.cfg.tmpl (removing .tmpl from the filename), it will get copied to /etc/fang-hacks.cfg during boot and activated after a reboot and set DISABLE_CLOUD=0."

[samtap]

I can try but more direct / specific questions would be helpful. Also consider reading the actual scripts, they're quite self explanatory.

The scripts are somewhat robust and I've tried to make sane choices like not modifying system files in ways that can cause corruption etc. but the goal has never been to make it absolutely fool proof. It's totally possible to lock yourself out by making a mistake in network config and rebooting (as far as I can tell from feedback here and elsewhere, this is what happens to most who complain stuff doesn't work).

When the cloud apps are either disabled or stopped by my scripts, you will have no way to restore a wifi connection using the app on your phone.

I'm assuming everyone using my scripts, has the ability to mount the sdcard and browse the fat filesystem (bootstrap partition) using a PC or laptop. This is why recovery files are placed on the fat partition of the sdcard. You'll find a number of files there that all get copied to the device, on each boot, once the hack is applied (check fang_hacks.sh for the details). So you can have multiple tries, modifying the files, rebooting the device with the sdcard inserted, to recover from a broken wifi connection. The fang-hacks-rescue.cfg will replace /etc/fang-hacks.cfg on the device, so it allows you to change settings without the webif (which obviously is not accessible if wifi is down). To 'activate' it, remove '.tmpl' from the filename. The file is removed from the sdcard to prevent it from overwriting /etc/fang-hacks.cfg on each boot (you would lose settings made in the webif).

For those who are still struggling to comprehend all this, it's probably easiest to re-enable the cloud apps and disable the hacks (DISABLE_CLOUD=0, HACKS_ENABLED=0). This assures the cloud apps are started and not killed by the stop_cloud script. You should then be able to re-connect using the app and setup button. Once wifi connection is restored, webif is accessible to re-enable hacks, fix wifi config etc.

[Cr4z33]

I just received the USB to serial adapter ordered from Amazon, connected everything, but after 1 minute the orange LED turned off and it doesn't want to turn on anymore.

Do I have to suppose that I wasn't careful enough to insulate properly my hands and the device is now DEFINITELY dead? :*(

[ephestione]

Just to report in. I got the camera straight from gearbest, configured network with the app (Actually I first frigged up by flashing image right off the bat with cloud disabled... but restored it quickly enough). Anyway finally got to the hack page ok, then tried to also open hello.cgi and that's where it stuck. I didn't try to reboot, it just got stuck at trying to open hello.cgi. So anyway, procedure is to rename the rescue.cfg.tmpl file to just .cfg, insert the card when the orange light is static, then I pressed for very long the setup button, then turned off, removed card, rebooted, bam flashing led again, with the network configuration still operational.

By the way, my ssid has a space in it, but I had configured the network beforehand via the app. Then I also edited the wpa supplicant file and removed the .tmpl extension, don't know if it changes anything. Also, I am on 2.9 firmware version

[Silencer3007]

Hello, I removed /etc/fang_hacks.sh and /etc/fang_hacks.cfg to delete the hacks etc. Now the Cam isn't booting anymore.. Only yellow light is on.. I tried it to recover it with the rescue files, but nothing worked. I think i have to unbrick it with Usb / Serial. Can someone explain how i can unbrick it with the Usb Serial Connection?

Thanks :)