Apply hack prior to upgrading to 2.7.6 for new users

[russinnes]

@guino - 2.7.6 came out today - and won't allow video stream in the app(s) until it is updated.
The new ppsapp is similar to the last update I posted for the v2.10.x firmware for other cameras, they closed up port 80 on this one as well.
Good news - if the hack is already applied, everything still works fine. I have yet to patch the new 2.7.6 app but booting from SD {and thus launching busybox etc} is still running fine.

I will patch it shortly and update as needed.

attached 2.7.6
--deleted--

[guino]

@russinnes After you posted this I opened the tuya app and while it shows the video it also shows a popup asking to update firmware (clicking cancel also closes the video feed). That being said, if I open the multi-camera view there's no popup and I can watch the video feed for the individual camera without limitations (just no playback features). I am going to take one last snapshot of the firmware before updating then another after updating to compare. Thanks for posting your ppsapp so I can look at it -- I would ask the devices/deviceinfo but port 80 is closed now so that won't work.

[guino]

guino/ppsapp-rtsp#1 (comment) has the patch addresses for the 2.7.6 ppsapp -- I also patched it to open port 80 again.

[guino]

It should be possible to apply the hack on 2.7.6 because we only use port 80 for 'confirmation' -- plus the generation of the /home/app/ppsapp on the SD card should be enough confirmation to apply the hack.

[russinnes]

I have an vanilla camera still in a box, I may try to update it from stock to 2.7.6, and then do a blind flash using {env} on an SD card. It would be nice to confirm so if folks land here and know exactly which camera they have, they can blindly flash it, even if they have missed the boat prior to this latest firmware update.

[guino]

That's cool, but there's no harm in you using guino/BazzDoorbell#11 to copy the flash before updating so that if all else fails you can use guino/BazzDoorbell#12 to put it back to 2.7.3 and install the hack before updating (again).

[guino]

I got a copy of my latest 2.7.3 fw, updated to 2.7.6 and got a copy of that fw as well to compare. It seems the update flashed a new kernel and new ppsapp partition (kernel is different but same version). I also saved the log of the firmware download process from ppsapp which includes a download link to the latest firmware update (which I downloaded for future reference -- could be used to verify/inspect/build a custom firmware update file).

[guino]

@russinnes so good news, I did some digging in the code and found a way to open port 80 on 2.7.6 -- I updated the instructions in https://github.com/guino/Merkury720 with a step to download/edit the ppsFactoryTool.txt file which allows opening port 80 (like it was before). I tested it on my device with 2.7.6 (without the hack) and port 80 opened like it was before. As long as that file is in the SD card port 80 should stay open from what I can tell.

[jjsmisbye]

That's cool, but there's no harm in you using guino/BazzDoorbell#11 to copy the flash before updating so that if all else fails you can use guino/BazzDoorbell#12 to put it back to 2.7.3 and install the hack before updating (again).

I tried performing guino/BazzDoorbell#12 to downgrade my mini7C (Mercury 720p) from 2.7.6 to 2.7.3. I used the flash dump that I created performing guino/BazzDoorbell#11 before the upgrade to 2.7.6. I modified the write address in the ppsMmcTool.txt #12 to match the read address in #11 but I can't seem to get it to work. It doesn't seem to perform the commands in the ppsMmcTool.txt as far as I can tell. It does not brick my device or seem to do anything. It just boots and runs 2.7.6 just like nothing happened. I've tried numerous times and went as far as zeroing out the sdcard before repartitioning and formatting to make sure there wasn't some remnant of anything on there but still no luck.

I know that there's no issue with my sdCard works since I was able to read my flash using #11 for both 2.7.3 and 2.7.6. Both binwalked just fine and everything looks like it's where it's supposed to be. I can also use it to record the video on it while it's in the camera.

Is it possible that flash write (#12) for the mini7C requires an env file just like the flash read (#11) does? Here is the ppsMmcTool.txt file that I used unsuccessfully for #12.

Thanks for your awesome work! It's been super useful and instructive.

[russinnes]

@jjsmisbye Depending what's on your SD card, if you have not moved a patched version of ppsapp into the SD card root, it will keep running the stock version. Also this new version blocks :80 so the first steps dont work any longer. Try editing your custom.sh on the SD card to ensure telnetd is running end enabled (/mnt/mmc01/busybox telnetd -l /bin/sh &) and try telnetting to its IP.
Just curious, did you press and hold reset until the LED pulses quickly on boot (~5-10 seconds) on the initial run with the modded SD card?

[guino]

@jjsmisbye the comments from @russinnes are valid but I wrote guino/BazzDoorbell#12 for the 2.9.x bootloader and I did not try it on 2.7.x hardware to verify if it would work. Just as guino/BazzDoorbell#11 required different commands to read 2.7.x hardware I assume that different commands would also be required to write 2.7.x firmware. The main question is why would you want to run 2.7.3 firmware instead of 2.7.6 which is fully working now. I would be uncomfortable testing the 2.7.x flash write process without a hot-air-soldering-gun to remove the flash chip (properly) and be able to restore it in case I did something wrong. As I don't do a lot of soldering work with SMD chips it doesn't justify buying $90 worth of equipment to use every now and then.
While I don't recommend running different versions of ppsapp I would be very surprised if you can't run an older version (i.e. 2.7.3) of ppsapp in 2.7.6 firmware -- but again, the question is why do you want 2.7.3 since 2.7.6 works just as good (I am using 2.7.6 with no issues with tuya app, rtsp, telnet, mjpeg/snapshot, etc).

[jjsmisbye]

Thanks for your answers @guino and @russinnes. I guess I'm mostly interested in the upgrade process, trying to map out what and how things happen. How the upgrade file is packaged, etc. I managed to also grab a copy of an upgrade file through some hooking on the phone app. I'm digging around with ghidra and trying to figure some things. This is an extra camera that I got for dirt cheap on sale so I won't cry if I brick it in the end but I'd rather not if I can help it because I'm enjoying spending time reversing this stuff. The flashing process/bootloaders are kind of outside of my wheelhouse a bit unfortunately.

That's cool, but there's no harm in you using guino/BazzDoorbell#11 to copy the flash before updating so that if all else fails you can use guino/BazzDoorbell#12 to put it back to 2.7.3 and install the hack before updating (again).

Seeing that the versions in the above comment matched the ones on my mini7c I was hopeful that this process would be as simple as the process for guino/BazzDoorbell#11 was. I backed up my flash and then made sure it was all good before proceeding with the upgrade and now I was hoping to be able to repeat the upgrade process. Any help, hints, pointers would be appreciated.

[guino]

@jjsmisbye having the 2.7.3 flash as a backup is always a good idea. If you by any chance 'brick' the device you can use a hardware programmer or the UART to restore the flash backup -- both processes will require opening and soldering work to make it work but would restore operation of the firmware in case it got bricked. If you do connect the UART and want to play with that I can give you some pointers/commands to execute so we know what's missing but my very best guess is that your ppsMmcTool.txt would have to look like this (should not need the env file):

style=upgrade,,writeAddr=0,,password=nothing,,writeLen=0,,fileName=flash.bin;sf probe;sf write 81808000 0 800000,,

(and do NOT forget to add a new line character at the end of the line + 0x00 character at the end of the file)

Additionally I would make sure the flash.bin file is exactly 8Mb in size as the instructions I provided grab a 16Mb file by default for devices with 16Mb flash and who knows if the bootloader/hardware would be ok with loading a 16Mb file into memory.

Again, I am just trying to be helpful but it's not something I would do without willing to open the device and do the soldering work in case I bricked it. If you think it may be helpful you can send me an email I can send you a copy of the upgrade file and the log I got during the upgrade process.

[jjsmisbye]

So good news/bad news. I tried style=upgrade,,writeAddr=0,,password=nothing,,writeLen=0,,fileName=flash.bin;sf` probe;sf write 81808000 0 800000,, with a 0x00 byte at the end (which was missing from the ppsMmcTool.txt in Issue #12). I check and made sure my flash.bin was also 8MB. This got me over the hump, something definitely happened but left my cam unable to boot. Fortunately, it would still take in ppsMmcTool.txt so not bricked! I could still dump out the flash using the procedure in #11 to compare results and binwalk gave odd results.

Binwalk of original dump flash.bin of 2.7.3 using issue #11: (Looks fine and extracts well so I used this file to try to downgrade)

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
114368        0x1BEC0         CRC32 polynomial table, little endian
458752        0x70000         uImage header, header size: 64 bytes, header CRC: 0x57382545, created: 2019-07-17 01:51:52, image size: 2076240 bytes, Data Address: 0x81808000, Entry Point: 0x81808040, data CRC: 0xF87F0477, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.4.35"
458816        0x70040         Linux kernel ARM boot executable zImage (little-endian)
472671        0x7365F         xz compressed data
472892        0x7373C         xz compressed data
3014656       0x2E0000        CramFS filesystem, little endian, size: 2969600, version 2, sorted_dirs, CRC 0x76B49630, edition 1, 726 blocks, 3 files
7733248       0x760000        JFFS2 filesystem, little endian
7747316       0x7636F4        JFFS2 filesystem, little endian
7778708       0x76B194        JFFS2 filesystem, little endian
7782412       0x76C00C        JFFS2 filesystem, little endian
7786496       0x76D000        JFFS2 filesystem, little endian
7821872       0x775A30        JFFS2 filesystem, little endian
7823360       0x776000        JFFS2 filesystem, little endian
7852032       0x77D000        JFFS2 filesystem, little endian
7936592       0x791A50        JFFS2 filesystem, little endian
7942156       0x79300C        JFFS2 filesystem, little endian
7945512       0x793D28        JFFS2 filesystem, little endian
8047552       0x7ACBC0        JFFS2 filesystem, little endian
8064508       0x7B0DFC        JFFS2 filesystem, little endian
8153656       0x7C6A38        JFFS2 filesystem, little endian
8180900       0x7CD4A4        JFFS2 filesystem, little endian
8331816       0x7F2228        JFFS2 filesystem, little endian
8375220       0x7FCBB4        JFFS2 filesystem, little endian

Binwalk after downgrade attempt from 2.7.6 to 2.7.3 through flash write using issue#12, then dumped again using issue #11: The CRCs were off, the date was wrong and the size of the data was wrong in the uImage header. A number of other odd entries popped up also. The cramfs looks off also. Obviously does not look good and produces sad results on extraction. e.g. The app.tar.gz is 0 bytes long

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
114368        0x1BEC0         CRC32 polynomial table, little endian
458752        0x70000         uImage header, header size: 64 bytes, header CRC: 0x16300100, created: 2019-06-21 00:13:28, image size: 2064960 bytes, Data Address: 0x81808000, Entry Point: 0x81808040, data CRC: 0x382E0405, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.4.35"
458816        0x70040         Linux kernel ARM boot executable zImage (little-endian)
472671        0x7365F         xz compressed data
472892        0x7373C         xz compressed data
635696        0x9B330         PARity archive data - file number 24592
1654534       0x193F06        PARity archive data - file number 17668
3014656       0x2E0000        CramFS filesystem, little endian, size: 2899968, version 2, sorted_dirs, CRC 0x34001200, edition 1, 710 blocks, 3 files
6030119       0x5C0327        Zlib compressed data, default compression
6034226       0x5C1332        Zlib compressed data, default compression
6038333       0x5C233D        Zlib compressed data, default compression
6042440       0x5C3348        Zlib compressed data, default compression
6046547       0x5C4353        Zlib compressed data, default compression
6050654       0x5C535E        Zlib compressed data, default compression
6050720       0x5C53A0        Zlib compressed data, default compression
7733248       0x760000        JFFS2 filesystem, little endian
7747316       0x7636F4        JFFS2 filesystem, little endian
7778708       0x76B194        JFFS2 filesystem, little endian
7782412       0x76C00C        JFFS2 filesystem, little endian
7786496       0x76D000        JFFS2 filesystem, little endian
7821872       0x775A30        JFFS2 filesystem, little endian
7823360       0x776000        JFFS2 filesystem, little endian
7852032       0x77D000        JFFS2 filesystem, little endian
7936592       0x791A50        JFFS2 filesystem, little endian
7942156       0x79300C        JFFS2 filesystem, little endian
7945512       0x793D28        JFFS2 filesystem, little endian
8014344       0x7A4A08        JFFS2 filesystem, little endian
8014912       0x7A4C40        JFFS2 filesystem, little endian
8020128       0x7A60A0        JFFS2 filesystem, little endian
8047552       0x7ACBC0        JFFS2 filesystem, little endian
8065024       0x7B1000        JFFS2 filesystem, little endian
8134892       0x7C20EC        JFFS2 filesystem, little endian
8153656       0x7C6A38        JFFS2 filesystem, little endian
8162824       0x7C8E08        JFFS2 filesystem, little endian
8173440       0x7CB780        JFFS2 filesystem, little endian
8180900       0x7CD4A4        JFFS2 filesystem, little endian
8331816       0x7F2228        JFFS2 filesystem, little endian
8375220       0x7FCBB4        JFFS2 filesystem, little endian

After spending a few days in this state trying various things I pushed the upgrade file that I downloaded from the phone app side after renaming it to upgrade.bin and I was finally able to boot back into 2.7.6.
The ppsMmcTool.txt used to restore my cam to a functioning 2.7.6.

style=upgrade,,writeAddr=0,,password=nothing,,writeLen=0,,fileName=upgrade.bin,,
Hexdumped:
00000000  73 74 79 6c 65 3d 75 70  67 72 61 64 65 2c 2c 77  |style=upgrade,,w|
00000010  72 69 74 65 41 64 64 72  3d 30 2c 2c 70 61 73 73  |riteAddr=0,,pass|
00000020  77 6f 72 64 3d 6e 6f 74  68 69 6e 67 2c 2c 77 72  |word=nothing,,wr|
00000030  69 74 65 4c 65 6e 3d 30  2c 2c 66 69 6c 65 4e 61  |iteLen=0,,fileNa|
00000040  6d 65 3d 75 70 67 72 61  64 65 2e 62 69 6e 2c 2c  |me=upgrade.bin,,|
00000050  0d 0a 00 d0 0a                                    |.....|
00000055

So I think I may have stumbled on way to do my downgrade using the sdcard and a repackaged upgrade file. I'll probably keep digging through that angle unless you have some other suggestions for the flash write method.

Thanks for the help, I'll email you soon about the upgrade stuff and some other tidbits if the offer still stands. Cheers!

[guino]

@jjsmisbye Well I am glad you didn't brick your camera, I mean, technically you did but got it restored. If you do figure out the upgrade.bin format that would be a good way to apply the hack to the cramfs without putting the bootloader in danger -- hopefully without requiring specifics of the device format (like partition sizes and such) ? Additionally this would allow the hack to work without a SD card for those that just want RTSP and nothing else.