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
Does this solution work for NVR's? I have a working NVR4208 that I wanted to rollback the firmware version on..

I have the network all setup... NVR is communicating from 192.168.1.108:1701 and pulling root\ID_NVR--Serial-number.txt it says 1 Blocks serverd and stops.

I used the similar setup from the cams but changed the command txt file name ...

What other config is require to have the NVR pull the firmware files

txt file
Code: 
CRC:4278823631
MagicString:c016dcd6-cdeb-45df-9fd0-e821bf0e1e62
custom-x.cramfs.img
logo-x.cramfs.img
web-x.cramfs.img
romfs-x.cramfs.img

These are the firmware files I have ... removed loader from root

1767289845972.png

cc: @thatotherguy
 
Last edited:
iTuneDVR said:
;)

In 2017 rom NVR4XXX ID_XXX inside must be with calculated CRC & magic string
After upgrade via TFTP it need by your hand reboot with already closed TFTP server
Example in attach. Util tools the same.
Just change XX.XXX to your SN
Click to expand...
@iTuneDVR is there a preferred editor & encoding to get this txt file configured on a pc... i have a feeling my notepad or VS Code is adding some characters making it not complete
 
Last edited:
I have three Dahua SD22204T-GN cameras, one of them running in boot-loops since month. Now I could spend some time on trying to bring this one back to live.
With the help of the instructions here I could get a connection via TFTP and with TFTP I could execute some commands.
Most of the commands I was forwarding to the camera were running successfully but camera still kept on with the booting loop.

The last few commands that I was executing finally brought it back to live and boot-loop could be stopped.

So, the first step I was doing (after a few trials the days before) was to retrieve information about the camera with the following commands.txt
printenv
nand info
tftp 0x02000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

Following to that I was sending all of the image files that I could find in my TFTP-Root-folder for the Firmware update (DH_SD-Mao-Rhea_MultiLang_NP_Stream3_IVS_V2.623.0000000.7.R.181124.zip)
tftp 0x2000000 romfs-x.squashfs.img
flwrite
tftp 0x2000000 kernel.img
flwrite
tftp 0x2000000 user-x.squashfs.img
flwrite
tftp 0x2000000 web-x.squashfs.img
flwrite
tftp 0x2000000 partition-x.cramfs.img
flwrite
tftp 0x2000000 custom-x.squashfs.img
flwrite
tftp 0x2000000 pd-x.squashfs.img
flwrite
tftp 0x2000000 update.img
flwrite
tftp 0x2000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

Next step was to send out only the basic images with a different sequence, as I noticed that something was stopping the
correct upload for pd-x.squashfs.img and because of that I swapped pd-x and custom
tftp 0x2000000 romfs-x.squashfs.img
flwrite
tftp 0x2000000 kernel.img
flwrite
tftp 0x2000000 user-x.squashfs.img
flwrite
tftp 0x2000000 web-x.squashfs.img
flwrite
tftp 0x2000000 partition-x.cramfs.img
flwrite
tftp 0x2000000 pd-x.squashfs.img
flwrite
tftp 0x2000000 custom-x.squashfs.img
flwrite
tftp 0x2000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

As the camera was still running in the boot-loop after that, I decided to make tha next step and calling a cfgRestore via TFTP
printenv
help
cfgRestore
tftp 0x2000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

After that call the camera was booting again but then it was coming up stable with IP 192.168.1.108 and could be seen via Advanced IP-Scanner, Advanced Port Scanner, ping command and finally the Dahua ConfigTool

So I think that finally the cfgRestore via TFTP brought back my camera to live but only after having sent all of the available firmware image files.
 
You must log in or register to reply here.
Top Bottom