Dahua IPC unbricking / recovery over serial UART and TFTP

Yes Riogrande, at this moment you saved a part of my brain that was smoking. Thanks for you help !
The VTO seems recovered with that old firmware and this is a great new. Unfortunately until now can't do login because it seems the default password is not admin. And I have to figure out how to access to VTO.
 
That's ridiculous. When done the more difficult work, can't access to the VTO for a unknown password.
All this evening trying passwords, reflashing with this apparently working firmware, resetting with back button pressed for 5 seconds and with intrusion front button (pressed 5 times).
Have to wait a friend with skills and kali distro to try something. That's incredible.
 
It was a war but the VTO is now fully working. Thanks to all for help and suggestions. Thanks to riogrande for last decisive support. Don't sure if I'll should suggest to a friend without strong skills to come in this tunnel . Anyway I would like to upgrade VTO with a new firmware ( I have a pair ) but still unsure if do it with VDP tool or not. Could anyone tell the real difference between the config tool and VDPconfig of the toolbox ? Is this last more appropriate or is absolutely the only suggested one ?
 
It was a war but the VTO is now fully working. Thanks to all for help and suggestions. Thanks to riogrande for last decisive support. Don't sure if I'll should suggest to a friend without strong skills to come in this tunnel . Anyway I would like to upgrade VTO with a new firmware ( I have a pair ) but still unsure if do it with VDP tool or not. Could anyone tell the real difference between the config tool and VDPconfig of the toolbox ? Is this last more appropriate or is absolutely the only suggested one ?

From what I understood from the doc: VDPConfig is the "new" Configtool, a branch-off for the VDP (meaning VTO/VTH/VTN* gear) - it only detects those components and can only work with them (eg. mass firmware upgrades).
 
Does anyone know the abbreviation code for flashing the sign.img partition?
could it be "run ds"?
 
Does anyone know the abbreviation code for flashing the sign.img partition?
could it be "run ds"?
Just this morning was triyng to do it. But doesn't work.Then I've tried to modify with "vi" editor the install file you can find in the same unarchived folder adding last command:
{
"Commands" : [
"burn kernel.img kernel",
"burn partition-x.cramfs.img partition",
"burn romfs-x.squashfs.img rootfs",
"burn pd-x.squashfs.img pd",
"burn user-x.squashfs.img user",
"burn custom-x.squashfs.img custom",
"burn web-x.squashfs.img web",
"burn data-x.squashfs.img data"
"burn sign.img sign"

but when I successfull unbricked my VTO I've stopped further attempts. So I don't now if it works.You could try.
 
A question to anyone can answer: wich tool could be useful to reverse the action of unarchiving a bin image file?
I mean how can I do reconvertion of unarchived files from a firmare image to recreate a new one ? With 7zip we learned how to open a firmware bin image and see the files, but 7zip can't make a bin file archiving the same files.
Trying to modding an image bin if it works but the first wall is make a bin.
 
A question to anyone can answer: wich tool could be useful to reverse the action of unarchiving a bin image file?
I mean how can I do reconvertion of unarchived files from a firmare image to recreate a new one ? With 7zip we learned how to open a firmware bin image and see the files, but 7zip can't make a bin file archiving the same files.
Trying to modding an image bin if it works but the first wall is make a bin.

On all firmware since from what I read, sometime in 2016 or 2017, the firmware is signed. You would need to decompress the archive, easy, then make your changes, then decompress the file, then generate a new CRC checksum, than use the CRC checksum along with a 2048 bit key to sign the file. This means you cannot modify the firmware unless you can get Dahua to send you their 2048 bit RSA key they use to sign the firmware files and that is not gonna happen. If you make any change to any of the files in any way than the CRC checksum and signatures will no longer be valid. As soon as you try to load the firmware the device will immediately reject it.

If you are working with old firmware you very well could though. You would just need a deep understanding of Linux and the various compression and archiving tools used under Linux. Binwalk the firmware image to both determine its specific type of compression routine used as well as extract the files.
 
Thanks for answer. Surely I know it appears an ingenuous question. But I have in mind if this device accepts old unsingned and new signed also firmwares could mean that if you remove all signs on each folder/file it should accept it like an old unsigned fimware.
 
in the commands.txt, what is the "pd-x.cramfs.img" mentioned ? It is nowhere in the package ... do I need to replace this by the .img file I need to copy in the root folder ?

run dc
run dr
run du
run dd
run dw
run dk
run up
tftp 0x82000000 pd-x.cramfs.img; flwrite
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

Many thanks !
 
  • Like
Reactions: observant1
You only use the run commands for the files your particular firmware has. There are other commands because some devices have different files. Remove the run commands for any files you do not have as well as the pd-x.cramfs line. One special one is if you have a update.img file than use ONLY that file and ONLY the run up command as an update.img file internally contains all of the others.
 
My bin file firmware is named "General_Multi3_VTO2000A_EngItlFreGetDutSpaPor_P_16M_V3.200.0000.0.R.20170912.bin"

I do not get "remove the run commands for any file you do not have" ... those run commands are used to navigate through the device directory structure to get at the correct location and launch the update no ?
ok, I understand I can remove the "tftp 0x82000000 pd-x.cramfs.img; flwrite" line ... but can you please confirm the purpose of those run commands ?

Also the commands do I have to launch them in a command window (DOS black window) or just double click the batch files from explorer ?
Many Thanks !!!
 
You are getting two very different methods confused here.
1 - there is the method of using a TTL serial cable and connecting to a device. This is where you manually type in commands at the devices boot prompt in a console window. That is this thread.
2 - there is the other method which is where you do NOT need a serial cable and are replying on the commands.txt file. The "easy" method. That method relies on the fact that almost all Dahua devices at boot will for a moment initialize a network connections and looks for a file named upgrade_info_7db780a713a4.txt on a TFTP server. That method is in another thread here Dahua IPC EASY unbricking / recovery over TFTP

These are TWO DIFFERENT methods and used in totally different ways. The method in this thread does NOT use the "commands.txt, commands.bat, etc" files. Those are strictly related to the method in the other thread.

For the purpose of clarity. The commands used in that file from the other thread are indeed some of the very same commands used at a console prompt in this thread.
There are also some commands that while valid for one device are not valid on another. Different devices have different file structures and a few devices have some files that others do not.
In either method a "run" command has a specific purpose and is ONLY for a very specific file.

These are ones that I know of, and again, not EVERY device has every one of these. NOTE - these are the "run" commands I figured out from my A46 and some from my DVR and others reading on these forums. Not likely that any device will have all of these but I thought it could be useful to know about as many as possible.
da=dhboot.bin.img (can also optionally load dhboot-min.bin.img or u-boot.bin.img depending on device)
dr=romfs-x.squashfs.img
dk=kernel.img
du=user-x.squashfs.img
dw=web-x.squashfs.img
dc=custom-x.squashfs.img
dt=data-x.squashfs.img
dp=partition-x.cramfs.img
dl=logo-x.squashfs.img
ds=tftp slave-x.squashfs.img
dx=u-boot_slave.bin.img
pd=pd-x.squashfs.img
pm=575s_PMX.bin.img (this is on my DVR but I do not have that file)
tk=uImage (my A46 showed this is hawthorn.dts.dtb. I have no idea what this one is, my firmware does not have that file but the printenv on my serial console did show it as a valid "run" type command)
up=update.img (if the firmware you want to flash has an update.img, use this one ONLY and skip all the others)
NOTE: each of these "run" commands can ONLY be used with the exact file name shown.

There are a few different ways that Dahua provides firmware and each is in a different format for loading in a different manner. There are two that are an "all in one" type of firmware which contain all of the different files. One will be named update.img which is the only "all in one" type that can be used with either this serial console method or the "easy" method in the other thread. The other "all in one" type is what you have which will be a firmware named "General_Multi3_VTO2000A_EngItlFreGetDutSpaPor_P_16M_V3.200.0000.0.R.20170912.bin" or something like that. That type of a firmware file is intended for updating firmware within the devices interface or one of the software tools and is not directly usable in this method or the "easy" method in the other thread. As it is that firmware file CANNOT be used with ANY of the "run" commands. Simply renaming that type of a firmware file will also NOT work. The third type of firmware that Dahua provides is broken into multiple individual parts and can ONLY be used via this serial console method or with the "easy" method in the other thread. Neither method is particularly "easy" for the average computer user though.

If the only type of firmware you can find for your device is the type intended for using in the devices web interface like "General_Multi3_VTO2000A_EngItlFreGetDutSpaPor_P_16M_V3.200.0000.0.R.20170912.bin" or something like that you can extract that to a folder. You would need 7zip or some other compressed file extractor. Extraction will also likely give you an error but still should extract the majority of the firmware files fine. Once extracted you should then have the individual .img files related to the commands listed above.
 
@riogrande75 @TheDude

I jumped from the 'easy' unbricking thread to this 'serial' one, as you both absolutely right that this is the place here to ask questions around the serial interface.

And my apologies, as my VTO2000A of course has this same connector as shown by @riogrande75 in a previous post. I didn't had access to my device yesterday, only to some pictures I had with me on my phone, so could not verify directly on the system itself. But todayI did, and yes, the connector is there. ;-) I would never have spotted it myself, and was convinced it was the other one, however this turns out to be an RS485 connector... <duh, slapping fronthead>.

Anyhow, will try again with the new connector, and see what it brings. Fingers crossed! :D
Will keep you posted!

BTW, many thanks for your continious replies! Much much appreciated!
 
  • Like
Reactions: TheDude
Hi, Please can someone help? In the first post it states "Start the TFTP server and point it to the files you have extracted from the firmware image". Can someone explain in a bit more detail. I have started the TFTPServer.bat and commands.bat but nothing happens. Is this the correct way to do it? Thanks
 
I have worked out how to get the run commands to work but camera will still not boot. It looks like it has failed to load bootargsParameters.txt and bootargsParameters.txt file. Could this be the cause and do anyone know how too fix? Thanks
 
This what the U-Boot screen shows

U-Boot 2010.06-svn5163 (Jan 16 2018 - 05:03:02)
I2C: ready
DRAM: 110 MiB
gBootLogPtr:00b80008.
NAND: 128 MiB
amb_nand_read_oob read page:49152 err
partition file version 2
rootfstype squashfs root /dev/mtdblock8
fail to load bootargsParametersV22.txt
fail to load bootargsParametersV21.txt
fail to init bootargsParametersV2
TEXT_BASE:01000000
Net: Detected MACID:14:a7:8b:15:8c:23
PHY:0x001cc816,addr:0x00
phy RTL8201 init

partition file version 2
rootfstype squashfs root /dev/mtdblock8
MMC: sdmmc init
Hit any key to stop autoboot: 0
 
My advice: Read the whole thread from the beginning, not just the first post! All issues have been discussed many times and while reading you will start more and more understanding it snd for sure find out whats your problem. If not, read it again.
Don't want to flood the thread with always same hints and questions.

Gesendet von meinem SM-T819 mit Tapatalk