Merkury720P 2.7.10 firmware rooting struggle #29
Comments
mascencerro
changed the title
|
@mascencerro from your outputs this does look like a bad/incompatible SD card. I have seen many cases of devices not liking specific brands or even just the partitioning/formatting on the SD card. Please try a different SD card and make sure it is formatted as FAT32 (you can also try formatting it from the phone app but you said you have not connected it). In the UART log, do you see the 'countdown' where you can press a key to stop booting ? if so, send me an email (my address is in my github profile) and I can give you some pointers. I'll tell you in advance that once the device is rooted, it will not fully boot the application until it has been paired with the phone app (even if we make an offline patch for it). The phone pairing does some registration/preparation of the device required for it to boot 100% otherwise it just stays in some 'factory mode' waiting for setup. I do not believe this has anything to do with your SD card issue but wanted to make sure you know about it. |
I'm sure its formatted as FAT32, have tried within windows with GUI an from command line, as well as in linux with mkfs.vfat.
What I posted from the UART output is all there is. No countdown, no prompt, nothing. It attempts to boot, fails with the
I was hoping to be able to read the firmware prior to pairing and investigate the pairing requirement, but have had no luck reading as you can see. I'll see if I can find a different brand/model of SD card, then move onto pairing the device and see what I can turn up from that. I don't have a programmer, but do have a rPI I can use if you happen to know a method to pull the firmware that way through SPIO. |
|
@mascencerro The countdown I mentioned is something that should show up on 'normal' boot (without pressing reset), it only shows something like 'some message 2..1..0' <- if you press a key there it may show a prompt. You should be able to root it and get a copy of the flash (i.e. guino/BazzDoorbell#11) before first registration, that is: if you can get your SD card working in the boot loader. I have a device which doesn't like the 'best' SD card I have (Industrial grade) but works fine with the cheaper ones, so you never now (the cheap Samsung cards seem to work on most of my devices) -- all my cards seem to work after the device boots, it is just the boot loader that is picky. At least on the tuya cameras, it seems that the 'reset' procedure does a decent job in reverting the device 'factory' state -- it may not be perfect but there's no 'visible' difference between a device that is brand new and a device that's just been reset. |
Yeah, I get no countdown on normal boot, just loads directly but without the section where the fail occurs.
I've tried several different methods and changes mentioned in the BazzDoorbell issue, along with address changes and adjustments, but always with same result. I'm thinking it doesn't like this cheapo card and I'll look around town for a different brand to try. |
|
Update: with a different card (PNY) I am able to make some progress. I think it read the flash and binwalk is doing its thing now extracting. There were some messages in UART output while reading flash that led me to believe there might be problems with the read, but I'll see what extraction produces and get back. |
|
It appears using a different card (slightly more expensive card) was the ticket. |
|
@mascencerro looks good. FYI you are working on a device that already has an update released for it (2.7.12) -- that obviously won't matter if you just want to use it offline. |
Does the device auto-update in the event that I connect it with the app? And is the 2.7.12 version patched where it no longer works with this exploit? |
|
@mascencerro some apps will auto-update -- I use the tuya app and it doesn't automatically update (there's an option to turn automatic updates off). It is also possible that depending on the app and account region you won't get the 2.7.12 update offered to your device. 2.7.12 does not remove or prevent using the boot loader exploit, so you can update it after installing it, and/or you can update it and apply the exploit just the same. |
Ok, I was worried if/when I do associate it with the app, the 2.7.12 update would kill the boot loader exploit. Basically the version will just determine which ppsapp I need for that firmware version streaming functionality, correct? Now on to cross compiling some stuff for this thing and seeing what I can break. 🙂 |
Correct -- and both 2.7.10 and 2.7.12 have patches available. |
I'm not sure if this is a me issue, card issue, or issue issue.
This is a "new" device that has never been connected to a capable internet connection or the app. I have connected UART for logging via FTDI USB.
Here is the output from /devices/deviceinfo:
/proc/cpuinfo:
/proc/mounts:
/proc/cmdline (missing exploit content):
mem=64M console=ttySAK0,115200n8 mtdparts=spi0.0:256k(bld)ro,64k(env)ro,64k(enc)ro,64k(sysflg)ro,2496k(sys),4608k(app),640k(cfg) ppsAppParts=5 ip=192.168.1.99:::255.255.255.0 eth=00:55:7b:b5:7d:f7I have tried multiple env and ppsMmcTool.txt combinations and modifications to addresses and the like.
Following the instructions along, it appears I may be having issues with the SD card not booting, but I want to check for insight.
I've also tried reading the flash with info gathered from BazzDoorbell #2 and BazzDoorbell #11 .
When trying to boot to root the device by holding reset while powering up, I have the following output consistently:
I'm able to add ppsFactoryTool.txt to the root of the drive and it connects to my AP of choice, so it is able to read the card. However any attempt to make it read the flash or access /proc/self/root/mnt/mmc01/hack with results have been fruitless.
I have tried partitioning and formatting combinations using windows and linux with no change in results.
Would it be safe to assume from the following that the card may be having boot issues and I need to try a different card or is this device one that would require programmer to root? I had seen another issue with what appeared to be the same firmware, and their device was farther along in the process with patching issues.
The text was updated successfully, but these errors were encountered: