yi-hack-v5
yi-hack-v5 copied to clipboard
alienatedsec
Edited: Now with video proof -> *6* Bricked Cameras in 3 Months. Please add a warning!
I take on all risk and responsibility for my own cameras but 5 cameras dying from this hack is a little excessive.
I have a bunch of Chinese Yi version (yi app not xiaomi home app) 1080p cameras. At the beginning of the year I started playing with yihack and found this v5 version worked for my cameras. Problem is now I've had five stop connecting to wifi and seem unable to be reset. The first three happened one day when I overloaded a fuse on the circuit they were connected to. I thought it must have been a surge or something but this week I've had two die simply by disconnecting the power.
I think a much stronger warning needs to be attached to the readme for this project.
edit: https://youtu.be/clLbNu7ALdo I had a camera plugged in for months and today I needed to unplug it while replacing an airconditioning unit. There was no way to keep it powered so I decided to video what happens when a camera has been plugged in for a long time and gets power cycled.
There absolutely should be a warning on this hack.
sounds like you damaged them electrically and has nothing to do with the firmware.
sounds like you damaged them electrically and has nothing to do with the firmware.
if it was just the first 3 I would be inclined to agree. Maybe. The circuit they were connected to had a high quality rcd in place and one of the cameras was powered by the usb port of my home server which suffered no damage.
All five of the cameras exhibit the exact same symptoms despite dying at different times and connected to different power sources. All except the one plugged into the server were powered by their original xiaomi power adaptors. One camera was on a circuit not connected to my house so we can also rule out my house have dodgy wiring.
When they boot up they go orange forever, then the blue light starts flashing (searching for wifi?) and then they reboot. If you reset the camera you can go through the setup process but they always reboot as soon as they start searching for wifi.
If you look through the other issues for this firmware, you will see that they can probably be recovered by wiring a serial port to them and deleting the log files or something thats filled up their built in flash. Other people have prevented this by making some kind of script to clean up the mess so they dont crash like mine have. I don't have time for that and I have about ten more of these things in a bag left over from an old business so I'm just using a new one for now.
I think my point still stands. There is a problem with this firmware and it will brick cameras. There should be a warning until this is fixed.
sounds like you damaged them electrically and has nothing to do with the firmware.
Here's a video of it happening in real time. I have multiple spares so I let a camera die so that someone with only one might learn from it. https://youtu.be/clLbNu7ALdo
hi, this is dead memory card, at least this is what happened to mine camera - replacing the microsd with FW on new one did the job on bringing the cameras back to life.
but then I assume you've tested with new card, right?
hi, this is dead memory card, at least this is what happened to mine camera - replacing the microsd with FW on new one did the job on bringing the cameras back to life.
but then I assume you've tested with new card, right?
The cards still work fine. I've repurposed them to other projects. The cameras wont boot or pair with or without a memory card new or not.
Looking through the other issues reported on this page it's more likely that the internal storage has been completely filled with some kind of log or cache file.
https://github.com/alienatedsec/yi-hack-v5/issues/125#issue-1065030683
I believe I am encountering the same issue as this person.
Does the hack author still visit this page?
I've got 2 Yi 1080p Dome cameras and 1 Yi Outdoor 1080p Camera using this firmware. I've had both Dome cameras just stop and go into a continuous reboot cycle once or twice now and they fail to find my wifi after a reset. To solve it I replace the SDcard with one that has the recovery files from Yi-hack-v3 in the root directory and then reset it. It reboots and loads the recovery firmware and I'm able to connect to my home wifi( with 5G switched off) as normal. The camera then updates itself to the latest version of the stock firmware. I switch it off, replace the sdcard with one containing yi-hack-v5 and switch it back on. It loads Yi-Hack_V5 and is up and running again. Hope this helps someone with this problem. EDIT. The recovery files are specific to certain models and are found at https://app.box.com/s/cibs7n1mgvhqaqjlidtveegu1uajt5yr/folder/23494084746. Therefore this solution may not be available to everyone.
I've got 2 Yi 1080p Dome cameras and 1 Yi Outdoor 1080p Camera using this firmware. I've had both Dome cameras just stop and go into a continuous reboot cycle once or twice now and they fail to find my wifi after a reset. To solve it I replace the SDcard with one that has the recovery files from Yi-hack-v3 in the root directory and then reset it. It reboots and loads the recovery firmware and I'm able to connect to my home wifi( with 5G switched off) as normal. The camera then updates itself to the latest version of the stock firmware. I switch it off, replace the sdcard with one containing yi-hack-v5 and switch it back on. It loads Yi-Hack_V5 and is up and running again. Hope this helps someone with this problem. EDIT. The recovery files are specific to certain models and are found at https://app.box.com/s/cibs7n1mgvhqaqjlidtveegu1uajt5yr/folder/23494084746. Therefore this solution may not be available to everyone.
Thankyou for this. I'll check it out. Hopefully the hack author sees this and can help too.
Looks like I am running into the same issue. I have 2 Yi Home 47US with v5 fw installed - one in the garage and one in a guest room. When the camera in the garage stops responding, I equated it to heat as the temp rises to about 100f. But the same thing happened to to the cam in the guestroom where the temperature is always between 70-80f. Both were setup with minimal services to minimize wear on the sd cards and both contained different brands of sd cards.
Try the suggestions from the user above. I managed to save 4 out of 5 failed cameras.
On Tue, 30 Aug 2022, 23:39 iointerrupt, @.***> wrote:
Looks like I am running into the same issue. I have 2 Yi Home 47US with v5 fw installed - one in the garage and one in a guest room. When the camera in the garage stops responding, I equated it to heat as the temp rises to about 100f. But the same thing happened to to the cam in the guestroom where the temperature is always between 70-80f. Both were setup with minimal services to minimize wear on the sd cards and both contained different brands of sd cards.
— Reply to this email directly, view it on GitHub https://github.com/alienatedsec/yi-hack-v5/issues/178#issuecomment-1231839798, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY3BNU3NNPJCSYEYWFS5LDV3YTMXANCNFSM5YRCQJFA . You are receiving this because you authored the thread.Message ID: @.***>
I believe I am encountering the same issue as this person.
Does the hack author still visit this page?
After my post, and before I go ahead and refresh the firmware, I followed the instructions on the thread mentioned above. It might be a case of the root growing in size. So I took the sdcard out and ran an fsck.vfat repair to repair it. Sure enough there were some corruptions due to the abnormal reboots. After this cleanup, it seems to be working alright now. I'll run it for a day or two and see if there are any issues and report back.
So my solution was:
- SSH into the cams and symlink the two files:
-
ln -sf /dev/null /var/run/utmp -
ln -sf /dev/null ~/.ash_history
- Turn off cam, pull out SD card and do a fs repair on the root: (I'm on linux):
-
sudo fsck.vfat -a -v /dev/mmcblk0p1that repaired the fs
- Then I re-inserted the card and voila - RTSP seems to be working fine. Before I wouldn't get RTSP at all.
Currently root fs usage is at 97%. If it grows, this could indicate a problem might still exist where the filesystem becomes full.
Update 1: The solution worked for one of the devices unfortunately. The 2nd one I followed your other post regarding switch to v3 and then upgrade to v5. After doing that, I proceeded with the symlink updates I posted.
#125 (comment) I believe I am encountering the same issue as this person. Does the hack author still visit this page?
After my post, and before I go ahead and refresh the firmware, I followed the instructions on the thread mentioned above. It might be a case of the root growing in size. So I took the sdcard out and ran an fsck.vfat repair to repair it. Sure enough there were some corruptions due to the abnormal reboots. After this cleanup, it seems to be working alright now. I'll run it for a day or two and see if there are any issues and report back.
So my solution was:
- SSH into the cams and symlink the two files:
ln -sf /dev/null /var/run/utmpln -sf /dev/null ~/.ash_history
- Turn off cam, pull out SD card and do a fs repair on the root: (I'm on linux):
sudo fsck.vfat -a -v /dev/mmcblk0p1that repaired the fs
- Then I re-inserted the card and voila - RTSP seems to be working fine. Before I wouldn't get RTSP at all.
Currently root fs usage is at 97%. If it grows, this could indicate a problem might still exist where the filesystem becomes full.
Update 1: The solution worked for one of the devices unfortunately. The 2nd one I followed your other post regarding switch to v3 and then upgrade to v5. After doing that, I proceeded with the symlink updates I posted.
What do you mean by "The solution worked for one of the devices unfortunately"?
Did you apply symlink and all to 2 devices but one of them still died?
Sorry I'm bit confused so could you help clarify a bit? You mention how root fs usage is 97%, is that after creating all these symlinks? - I thought puprose of symlinks was to move files to cache so they end up being deleted and not fill up the device?
I'm thinking of doing this but I'm bit hesitant as is xd
I'm sketching out the source code wondering if all is actually open source and secure ( As in author doesn't have remote access into your bedroom.... ). Coupled with cameras dying it makes me rly hesitant xd
Did you try going through the source code of the project? What do you think if so?
Try the suggestions from the user above. I managed to save 4 out of 5 failed cameras. … On Tue, 30 Aug 2022, 23:39 iointerrupt, @.> wrote: Looks like I am running into the same issue. I have 2 Yi Home 47US with v5 fw installed - one in the garage and one in a guest room. When the camera in the garage stops responding, I equated it to heat as the temp rises to about 100f. But the same thing happened to to the cam in the guestroom where the temperature is always between 70-80f. Both were setup with minimal services to minimize wear on the sd cards and both contained different brands of sd cards. — Reply to this email directly, view it on GitHub <#178 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY3BNU3NNPJCSYEYWFS5LDV3YTMXANCNFSM5YRCQJFA . You are receiving this because you authored the thread.Message ID: @.>
I wish but the link is nuked x:
I was gonna save just in case I ever wanna give this a try
What do you mean by "The solution worked for one of the devices unfortunately"? Only the symlink and sdcard repair approach worked on one of the two Yi home cams. The second one, I had to follow @twosheds solution of reverting to YiHack v3 and then applying YiHack v5 again. Afterwards I applied the symlink as well
Did you apply symlink and all to 2 devices but one of them still died?
None of them are dead. Both are alive and kicking :-). In fact none of them had any abrupt reboots or anything since I added them yesterday evening - I checked by ssh-ing to the devices and running uptime
Sorry I'm bit confused so could you help clarify a bit? You mention how root fs usage is 97%, is that after creating all these symlinks? - I thought puprose of symlinks was to move files to cache so they end up being deleted and not fill up the device? Actually root fs was at 94% AFTER the symlinks. I checked today and they have risen to 95%. This means there are probably other files in the root parition that are growing. Ill check tomorrow again. Results are below.
Symlinking them to /dev/null will just send the text out to a null stream meaning they are just disappearing into a blackhole so it wont end up increasing the filesize. It will also cause less wear as there wont be any writes to the SD card.
I have also symlinked /tmp/log.txt and /tmp/debug_alarm.txt to /dev/null. These two files tend to get larger when motion is detected regardless of whether you set up mqtt notification or not. This will probably impact debugging as it wont save any info making troubleshooting a bit harder. Also, anything in the /tmp folder are cleared at reboot, so the symlinks will probably have to be scripted into startup.
I'm sketching out the source code wondering if all is actually open source and secure ( As in author doesn't have remote access into your bedroom.... ) I cannot vouch for the code as I have not 100% examined it (or the binary firmware from the makers for that matter), but along with all my other home automation sensors and devices, both Yi cameras are on my IoT VLAN. This VLAN is tightly firewalled and has no access to the internet, or beyond the vlan itself for that matter. I use this firmware because it provides an RTSP stream which I can access locally and via another proxy streamer like Live555.
Here are my results using df. As you can see, since yesterday the root parition has grown by 1%. Im going to leave it alone and see if it gets to 96% tomorrow around the same time.
# 2022-08-30 15:59
/dev/root 1280 1208 72 94% /
tmpfs 9296 4 9292 0% /dev
/dev/mtdblock5 12992 7692 5300 59% /home
tmpfs 16384 684 15700 4% /tmp
/dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd
/dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd/yi-hack-v5/www/record
# 2022-08-31 15:59
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1280 1220 60 95% /
tmpfs 9296 4 9292 0% /dev
/dev/mtdblock5 12992 7724 5268 59% /home
tmpfs 16384 732 15652 4% /tmp
/dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd
/dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd/yi-hack-v5/www/record
Edit 1: Correction - /tmp is not on SD but rather the storage on the camera itself. So it shouldnt cause any wear on SD even if written to.
Thank you, and yeah it makes sense to go with vlans :o
Scary thing is how it keeps dying z: ( Filling up ) Really wish author will look into this issue... I messaged him but no reply so far - he did say on his discord that he's taking a break tho so prolly will be a fair bit longer
Btw why v3? Did using stock firmware not work when trying to unbrick? I'm trying to find the recovery file on the hack v3 github page but I'm not even sure what I'm looking for ( There's nothing named "recovery " firmware ) @iointerrupt
On Thursday, September 1, 2022, iointerrupt @.***> wrote:
What do you mean by "The solution worked for one of the devices unfortunately"? Only the symlink and sdcard repair approach worked on one of the two Yi home cams. The second one, I have to follow @twosheds https://github.com/twosheds solution of reverting to YiHack v3 and then applying YiHack v5 again. Afterwards I did the symlink as well
Did you apply symlink and all to 2 devices but one of them still died? None of them are dead. Both are alive and kicking :-). In fact none of them had any abrupt reboots or anything since I added them yesterday evening - I checked by ssh-ing to the devices and running uptime
Sorry I'm bit confused so could you help clarify a bit? You mention how root fs usage is 97%, is that after creating all these symlinks? - I thought puprose of symlinks was to move files to cache so they end up being deleted and not fill up the device? Actually root fs was at 94% AFTER the symlinks. I checked today a while while and they have risen to 95%. This means there are probably other files in the root parition that are growing. Ill check tomorrow again. Results are below.
Symlinking them to /dev/null will just send the text out to a null stream meaning they are just disappearing into a blackhole so it wont end up increasing the filesize. It will also cause less wear as there wont be any writes to the SD card.
I have also symlinked /tmp/log.txt and /tmp/debug_alarm.txt to /dev/null. These two files tend to get larger when motion is detected regardless of whether you set up mqtt notification or not. This will probably impact debugging as it wont save any info making troubleshooting a bit harder. Also, anything in the /tmp folder are cleared at reboot, so the symlinks will probably have to be scripted into startup.
I'm sketching out the source code wondering if all is actually open source and secure ( As in author doesn't have remote access into your bedroom.... ) I cannot vouch for the code as I have not 100% examined it (or the binary firmware from the makers for that matter), but along with all my other home automation sensors and devices, both Yi cameras are on my IoT VLAN. This VLAN is tightly firewalled and has no access to the internet, or beyond the vlan itself for that matter. I use this firmware because it provides an RTSP stream which I can access locally and via another proxy streamer like Live555.
Here are my results using df. As you can see, since yesterday the root parition has grown by 1%. Im going to leave it alone and see if it gets to 96% tomorrow around the same time.
#2022-08-30 15:59 /dev/root 1280 1208 72 94% / tmpfs 9296 4 9292 0% /dev /dev/mtdblock5 12992 7692 5300 59% /home tmpfs 16384 684 15700 4% /tmp /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd/yi-hack-v5/www/record
#2022-08-31 15:59 Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 1280 1220 60 95% / tmpfs 9296 4 9292 0% /dev /dev/mtdblock5 12992 7724 5268 59% /home tmpfs 16384 732 15652 4% /tmp /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd/yi-hack-v5/www/record
— Reply to this email directly, view it on GitHub https://github.com/alienatedsec/yi-hack-v5/issues/178#issuecomment-1233475230, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3VJK64H3ZPLC4JCQLXUOTV37KSZANCNFSM5YRCQJFA . You are receiving this because you commented.Message ID: @.***>
To unbrick just flash stock. Worked every time.
On Thu, 1 Sept 2022, 06:48 Rstment25, @.***> wrote:
Thank you, and yeah it makes sense to go with vlans :o
Scary thing is how it keeps dying z: Really wish author will look into this issue... I messaged him but no reply so far - he did say on his discord that he's taking a break tho so prolly will be a fair bit longer
Btw why v3? Did using stock firmware not work when trying to unbrick? I'm trying to find the recovery file on the hack v3 github page but I'm not even sure what I'm looking for ( There's nothing named "recovery " firmware )
On Thursday, September 1, 2022, iointerrupt @.***> wrote:
What do you mean by "The solution worked for one of the devices unfortunately"? Only the symlink and sdcard repair approach worked on one of the two Yi home cams. The second one, I have to follow @twosheds https://github.com/twosheds solution of reverting to YiHack v3 and then applying YiHack v5 again. Afterwards I did the symlink as well
Did you apply symlink and all to 2 devices but one of them still died? None of them are dead. Both are alive and kicking :-). In fact none of them had any abrupt reboots or anything since I added them yesterday evening - I checked by ssh-ing to the devices and running uptime
Sorry I'm bit confused so could you help clarify a bit? You mention how root fs usage is 97%, is that after creating all these symlinks? - I thought puprose of symlinks was to move files to cache so they end up being deleted and not fill up the device? Actually root fs was at 94% AFTER the symlinks. I checked today a while while and they have risen to 95%. This means there are probably other files in the root parition that are growing. Ill check tomorrow again. Results are below.
Symlinking them to /dev/null will just send the text out to a null stream meaning they are just disappearing into a blackhole so it wont end up increasing the filesize. It will also cause less wear as there wont be any writes to the SD card.
I have also symlinked /tmp/log.txt and /tmp/debug_alarm.txt to /dev/null. These two files tend to get larger when motion is detected regardless of whether you set up mqtt notification or not. This will probably impact debugging as it wont save any info making troubleshooting a bit harder. Also, anything in the /tmp folder are cleared at reboot, so the symlinks will probably have to be scripted into startup.
I'm sketching out the source code wondering if all is actually open source and secure ( As in author doesn't have remote access into your bedroom.... ) I cannot vouch for the code as I have not 100% examined it (or the binary firmware from the makers for that matter), but along with all my other home automation sensors and devices, both Yi cameras are on my IoT VLAN. This VLAN is tightly firewalled and has no access to the internet, or beyond the vlan itself for that matter. I use this firmware because it provides an RTSP stream which I can access locally and via another proxy streamer like Live555.
Here are my results using df. As you can see, since yesterday the root parition has grown by 1%. Im going to leave it alone and see if it gets to 96% tomorrow around the same time.
#2022-08-30 15:59 /dev/root 1280 1208 72 94% / tmpfs 9296 4 9292 0% /dev /dev/mtdblock5 12992 7692 5300 59% /home tmpfs 16384 684 15700 4% /tmp /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd/yi-hack-v5/www/record
#2022-08-31 15:59 Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 1280 1220 60 95% / tmpfs 9296 4 9292 0% /dev /dev/mtdblock5 12992 7724 5268 59% /home tmpfs 16384 732 15652 4% /tmp /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd /dev/mmcblk0p1 129039 87070 41970 67% /tmp/sd/yi-hack-v5/www/record
— Reply to this email directly, view it on GitHub < https://github.com/alienatedsec/yi-hack-v5/issues/178#issuecomment-1233475230 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AH3VJK64H3ZPLC4JCQLXUOTV37KSZANCNFSM5YRCQJFA
. You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/alienatedsec/yi-hack-v5/issues/178#issuecomment-1233736155, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKOYRFCVAJRV326ABQ2H2RDV4AYRXANCNFSM5YRCQJFA . You are receiving this because you commented.Message ID: @.***>
Thank you, and yeah it makes sense to go with vlans :o Scary thing is how it keeps dying z: ( Filling up ) Really wish author will look into this issue... I messaged him but no reply so far - he did say on his discord that he's taking a break tho so prolly will be a fair bit longer Btw why v3? Did using stock firmware not work when trying to unbrick? I'm trying to find the recovery file on the hack v3 github page but I'm not even sure what I'm looking for ( There's nothing named "recovery " firmware )
To be fair to all the authors of the Yi-Hack-v* firmwares, this might out of their control as well. These firmwares are not fully open sourced. They are, as the title suggests, hacks of the original firmware provided by makers of the Yi cams or the generic-line cams that use this specific chipset. The authors reverse-engineered the firmwares and added enhancements to the firmware than many of us use. The root 'filling up' could have been a bug of the original underlying firmware. The work done by @alienatedsec and the other developers along with community are able to try to fix a lot of the bottlenecks and restrictions that could have been baked into the original firmware.
I have the same problem with 2 outdoor cameras and one home one. I have flashed v3 and then updated to the latest stock FW followed by v5 hacked firmware as well as symlinking.
I can access the rtsp stream and everything seemed to have worked for a day, until I repositioned the camera (therefore power cycling). I can see the camera connected to my router but I cannot SSH or access via web interface. Any ideas what could be wrong?
Same and no idea ...
Power cycling is killing cameras regardless of what you do. Camera worked in my instances for total of 1-2 hours of up time ( I power cycled it 6-7 times , most of it being via it's web interface and other 2/3 times by unplugging cable ) and then it wouldn't work... I wake up , plug camera in and wait for it to boot up - only to face the same thing , connects to router but can't be accessed in any way. RTSP not working, interface not working, ssh same
I was thinking of trying v3 firmware as per suggestion on discord but it doesn't seem like it'll fix anything...
Guess only thing now is to reflash stock firmware > then yi hack v5 and then make a configuration and save it for when this happens again... And keep camera plugged in at all times ( hard brick is a real possibility too I guess ... )
On Sunday, September 11, 2022, kirilldem @.***> wrote:
I have the same problem with 2 outdoor cameras and one home one. I have flashed v3 and then updated to the latest stock FW followed by v5 hacked firmware as well as symlinking.
I can access the rtsp stream and everything seemed to have worked for a day, until I repositioned the camera (therefore power cycling). I can see the camera connected to my router but I cannot SSH or access via web interface. Any ideas what could be wrong?
— Reply to this email directly, view it on GitHub https://github.com/alienatedsec/yi-hack-v5/issues/178#issuecomment-1242914301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3VJK4UNFWE7XNB32PCK2DV5WIORANCNFSM5YRCQJFA . You are receiving this because you commented.Message ID: @.***>
So camera connects to wifi but has no hostname ... Do I need to reset camera by it's button and pair it again via qr code for hostname to be restored? Idk... likely that's why people say camera connects to Wi-Fi but can't be accessed.
I'll try resetting this later , like way later... If anyone can do it sooner please give update if pairing again via qr code makes camera functional again - without having to reflash any of the firmware
If you have the same problem then repairing won't work. Every time it boots up and tries to connect to wifi it will reboot .
On Sat, 17 Sep 2022, 07:35 Rstment25, @.***> wrote:
So camera connects to wifi but has no hostname ... Do I need to reset camera by it's button and pair it again via qr code for hostname to be restored? Idk... likely that's why people say camera connects to Wi-Fi but can't be accessed.
I'll try resetting this later , like way later... If anyone can do it sooner please give update if pairing again via qr code makes camera functional again - without having to reflash any of the firmware
— Reply to this email directly, view it on GitHub https://github.com/alienatedsec/yi-hack-v5/issues/178#issuecomment-1249936425, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY3BNRR5UHSQCEO5JZOMWDV6T73HANCNFSM5YRCQJFA . You are receiving this because you authored the thread.Message ID: @.***>
I also have a Yi Home 47US camera and it refuses to connect to my Wifi saying pairing failed.
Is there a way to unbrick it? I have tried all three versions of recovery firmware.
The work done by @alienatedsec and the other developers along with community are able to try to fix a lot of the bottlenecks and restrictions that could have been baked into the original firmware.
@iointerrupt I would not call myself a developer but thanks for the recognition. I am doing it as a hobby and learned more on this than in any other course.
I released v0.3.3 but there is a slight problem which I have to resolve somehow in the next release.
There are two places where .ash_history is located:
So we need to do the same for the second location:
ln -sf /dev/null /home/yi-hack-v5/.ash_history
Is there a way to unbrick it? I have tried all three versions of recovery firmware.
@kirilldem try this version (a single file) change the name to home_y18m and place in the / of the SD card.
Is there a way to unbrick it? I have tried all three versions of recovery firmware.
@kirilldem try this version (a single file) change the name to
home_y18mand place in the/of the SD card.
Thanks for the suggestion - I downloaded 1.8.7.0D_201708091510home_y18m renamed it to home_y18m and flashed from sd card root. Still failing on wifi connection, the camera goes back to waiting to connect prompt. Tried with or without reset and on two different 2,4 networks. Video and logs attached.
https://drive.google.com/file/d/1wiq0a9NI71SY1o3ty-eOtxVZj_cLkqS2/view
log_init.tar.gz log_start_reset.tar.gz log_no_wifi_dev.tar.gz
@kirilldem Any chance you are using the WPA3 or any mixed WPA2/WPA3?
I'm using WPA/WPA2-Personal no problem to connect to it with v5 hack earlier.
Is there a way to unbrick it? I have tried all three versions of recovery firmware.
Are there 3 versions of recovery software ? I'm only aware of the Yi-Hack-V3 recovery. Where would I find the other two ?
Is there a way to unbrick it? I have tried all three versions of recovery firmware.
Are there 3 versions of recovery software ? I'm only aware of the Yi-Hack-V3 recovery. Where would I find the other two ?
Perhaps I could have been clearer, there are three versions of the home camera variant, 47US, 27US and one more. I think they have different chips. I tried all 3 of them with the same result.