Dahua IPC EASY unbricking / recovery over TFTP

I have no help.
It's crazy to me the different named NVR/Cam systems that are most likely built in china within a few blocks of each other. I was able to upgrade a lorex to a dauha sys (learned it here) but I think most low end systems wont allow it. ... and i like the features ....but probably can't do it anymore....the cameras seem to be the intellegent part of the system.

I purchased a Hornbull sys years ago (8 poe ports in the back, cameras were shit but Quality Uniview cams are ok with the system....but it's limited to 1 small HD.
If you want a good system, purchase a good system even if you have to build it up slowly. ....and if your new to building your system up slowly as you learn more about the cameras and features you'll be glad you didn't purchase a system that uses all the buzzwords like super starlight vision.

...........and i have a 2mp cam with optical zoom that works great, because the cmos sensor is not overloaded at night.

.....so if it's really bricked, you may look back one day and think you may have been lucky.

I don't know and wont be angry if you tell me to mind my own business....hope it all works out.
 
cawauk said:
Thank you, thank you, thank you!!!!

Without your post, I would never have revived my bricked AMCREST IP2M-841W.
So thank you again!
I followed your steps and had a few hesitations/hickups along the way I thought I should share:

1.
It wasn't clear to me that the firmware from amcrest, a .bin file, was in fact a package which could be opened with 7zip to extract the .img files. I eventually figured it out before flashing.
2.
I didn't understand your statement of not flashing the boot files, but after downloading your custom eos rom file to compare to the amcrest files, I saw two additional files called dhboot.bin.img and dhboot-min.bin.img with the amcrest files, so I removed these from the folder.
3.
All files were successfully transferred, except pd-x.squashfs.img which showed 'Timeout'. I have no idea why.
4.
The tftpserver was running in a loop. I never got to the "FLASHING_DONE_STOP_TFTP_NOW" message. Maybe I did something wrong, but after the 5th loop flashing, I figured out roughly when to close the server whilst watching activity in Wireshark (as soon as "Read Request, File: upgrade_info_7db780a713a4.txt" appeared for the 6th time).

Immediately after, the PTZ began on boot (which it wasn't doing since bricking). You can't imagine how happy I was; Amcrest's IP Tool could now see the camera again!

At this point, I decided to flash the Amcrest BIN file again using the Amcrest IP Tool to make sure 'boot' files I hadn't included in the TFTP folder and the 'timeout' squashfs.img were correctly loaded.

The flash was successful and I have a fully working camera again.

So thank you thank you thank you!!!
Click to expand...
I ran into some similar issues while trying to recover an Amcrest IP2m-841w that had started freezing and then couldn't be reset by long pressing the reset button and was just boot-looping. I hooked up my USB-TTL adapter to the Gnd/Tx/Rx on the camera's circuit board (it was in a silkscreened section labeled "J12") and was able to monitor the serial output but was never able to interrupt the boot process and issue commands.

My first issue was that when I downloaded the Amcrest recent and previous firmware files for the camera, Windows 11 was giving error messages when trying to extract the "Install" file and 7-zip was able to extract but the file was a 0-byte blank text file. I ended up using a commands.txt file with the below commands that I had seen used by someone else in the thread () and created the upgarde_info_7db780a713a4.txt file using the python code with the command.txt in the same directory where I ran the python code: (source; dahua-tftp-recover-docker/tools/upgrade_info.py at main · ayushin/dahua-tftp-recover-docker)

Python: 
import zlib
import sys

with open("command.txt", "rb") as cmdfile:
    data = cmdfile.read()

    magic = b"MagicString:c016dcd6-cdeb-45df-9fd0-e821bf0e1e62\n"
    crc = zlib.crc32(magic)
    crc = zlib.crc32(data, crc)

    output = b"CRC:" + str(crc).encode("ascii") + b'\n'
    output += magic
    output += data

    with open("upgrade_info_7db780a713a4.txt", "wb") as outfile:
        outfile.write(output)

That resulted in the upgrade_info_7db780a713a4.txt with the following contents which I copied to the TFTP directory:


Code: 
CRC:4136420423
MagicString:c016dcd6-cdeb-45df-9fd0-e821bf0e1e62
run dr
run dk
run du
run dw
run dp
run dc
tftp 0x82000000 pd-x.squashfs.img; flwrite
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

I already had used TFTPD64 windows app for other device recoveries in the past, and after setting my ethernet interface's address to 192.168.1.1 and using "Advanced" to also add 192.168.254.254, I was able to bind TFTPD64 to the .254.254 address, and with all of the files in place, I saw it downloading and writing all of the partitions (multiple times until I realized that I was seeing the same partitions which had previously been written, so I decided to pull the power when it seemed like the process was starting again by requesting the upgrade_info... file, and after rebooting, the camera came up on the 192.168.1.108 ethernet interface, and I was able to reconfigure it from scratch. I had already replaced it with another camera when it started freezing and boot-looping, so this will now be a portable wifi camera that I can move around and use as needed.

Thanks again to everyone who helped contribute to this thread!
 
  • Like
Reactions: VorlonFrog
You must log in or register to reply here.
Top Bottom