Dahua Firmware Mod Kit + Modded Dahua Firmware

I have programmer and so I can do full dump and restore if needed.

My question is, is it possible to somehow use old bootloader with new firmware? (i.e. possible to use the cor35vet scripts to fix up the new chinese firmware and then package it with old bootloader? Is bootloader part of the new firmware? )

Also, cant we use TFTP to downgrade to old firmware without the programmer?
Sorry. NO.
 
I have programmer and so I can do full dump and restore if needed.

My question is, is it possible to somehow use old bootloader with new firmware? (i.e. possible to use the cor35vet scripts to fix up the new chinese firmware and then package it with old bootloader? Is bootloader part of the new firmware? )

Also, cant we use TFTP to downgrade to old firmware without the programmer?
If you have full dump, so what the question?
All is on your hand & you don't break anything, of couse if you be careful

Main problem was software downgrade new fullsigned firmware with boot to version 1809, without signed boot & this task is solved without programmer.
All other - maybe possible, but need many manipulation, patching code & etc.
It's too hard & usseless at the end more than "Sorry No" at Speed666 answer ;)
 
Hello everyone, can anyone help? Russian (English) modified firmware is required for the ipc-hdw1230c-a CN camera, I am not friends with Linux, I have never used it and it will probably be a pain for me) the problem is that the dahua registrar stopped seeing it, maybe even hack will help)
 
Update. Latest 2019 FW for new Dahua cams completly cracked :) Sorry, no public right now.
I never soon soo much shit in a software. They even overcome HikVision PSH and RSA. Multiple keys, encrypted kernel image.

They will die very fast with this software. Very....
 
It would be a good feat to break through Hikvision's psh.
They do consider this to be secure, based on its certificate use.
But what does psh have to do with Dahua firmware?
 
Dahua made DSH with a lot more limited options than PSH.
There are the problems i had:
1. Encrypted kernel image
2. Encrypted rootfs with AES
3. Encrypted patitions with AES
4. All has different keys
5. Heavliy modified kernel to support mounting crypted partitions
6. Kernel thread to valdate sign of every binary file in camera and all are signed using SHA and RSA.
7. Even getting to /bin/sh wont let you run any binary not signed with their tools
8. Limited u-boot commands

There are more of this shit inside.
 
Hi
@Killcam
I also own a HDW4431C-A with 2.420.0000.22.R, Build Date: 2016-12-09 firmware
I'm interested by the newest firmware resolving security issues
Can you tell me where to download it ?
Regards
I too own 3 HDW4431C-A Duhua camera's that since June 2019 are not able to email alarms. They work great otherwise. Is there a fix or new firmware rev that might fix this?
 
Hi All
I have just tried extracting firmware using 'firmware mod kit' however the new GUI firmware doesn't appear to have the file 'romfs-x.squashfs.img.raw'. Please see output from terminal.

~/Dahua-Firmware-Mod-Kit$ ./extract.py General_NVR4XXX-4KS2_MultiLang_PN_AlarmCenter_V4.000.10EX100.0.T.20191221.bin
WARNING Autodetected config: NVR4XXX-4KS2
INFO Extracting 8 files to: 'General_NVR4XXX-4KS2_MultiLang_PN_AlarmCenter_V4.000.10EX100.0.T.20191221.bin.extracted'
INFO Processing 'Install.lua'.
INFO Processing 'u-boot.bin.img'.
INFO Processing 'uImage.img'.
INFO Processing 'romfs-x.squashfs.img'.
Can't find a SQUASHFS superblock on General_NVR4XXX-4KS2_MultiLang_PN_AlarmCenter_V4.000.10EX100.0.T.20191221.bin.extracted/romfs-x.squashfs.img.raw
ERROR 'SquashFS' handler returned non-zero return value for file: 'romfs-x.squashfs.img.raw'
Traceback (most recent call last):
File "./extract.py", line 238, in <module>
extractor.Extract(args.source)
File "./extract.py", line 108, in Extract
raise Exception("Handler returned non-zero return value!")
Exception: Handler returned non-zero return value!

So my question would be how do we go about extracting all files on the .bin file?

Thank you in advance
 
Do you have squashfs tools installed?

Hi Alastair
I can successfully extract an image the does not include the new GUI for the NVR. So I am confident that all the repository's required are installed correctly. I am guessing Dahua have changed the file structure???? I will try the hex editor option and report back.
Thank you for your assistance.
 
To extract the files this usually works -
With a hex editor, change the DH in the header to PK then unzip all files.

Hi Alastair

After changing DH to PK with a hexeditor the issue is still the same. Please see output from terminal.

~/Dahua-Firmware-Mod-Kit$ ./extract.py General_NVR4XXX-4KS2_MultiLang_PN_AlarmCenter_V4.000.10EX100.0.T.20191221.bin.bak
WARNING Autodetected config: NVR4XXX-4KS2
INFO Extracting 8 files to: 'General_NVR4XXX-4KS2_MultiLang_PN_AlarmCenter_V4.000.10EX100.0.T.20191221.bin.bak.extracted'
INFO Processing 'Install.lua'.
INFO Processing 'u-boot.bin.img'.
INFO Processing 'uImage.img'.
INFO Processing 'romfs-x.squashfs.img'.
[sudo] password for andy:
Can't find a SQUASHFS superblock on General_NVR4XXX-4KS2_MultiLang_PN_AlarmCenter_V4.000.10EX100.0.T.20191221.bin.bak.extracted/romfs-x.squashfs.img.raw
ERROR 'SquashFS' handler returned non-zero return value for file: 'romfs-x.squashfs.img.raw'
Traceback (most recent call last):
File "./extract.py", line 238, in <module>
extractor.Extract(args.source)
File "./extract.py", line 108, in Extract
raise Exception("Handler returned non-zero return value!")
Exception: Handler returned non-zero return value!

Any other thoughts?

Thanks in advance.
 
The suggestion was to unzip the file after fixing up the tweaked header such that it's a valid zip file.
Maybe copy the file and change the extension to .zip
 
Update. Latest 2019 FW for new Dahua cams completly cracked :) Sorry, no public right now.
I never soon soo much shit in a software. They even overcome HikVision PSH and RSA. Multiple keys, encrypted kernel image.

They will die very fast with this software. Very....
I love it. Keep it quiet; it would be nice to be able to do some proofing to keep the Chinese government out of my network.
 
The suggestion was to unzip the file after fixing up the tweaked header such that it's a valid zip file.
Maybe copy the file and change the extension to .zip

Hi Alastair

I have done as requested however the unzip only creates the image files and I am still unable to extract the files. the error shown is Can't find SQUASHFS superblock.....
Is it possible to send you the firmware to see if you could manage to get the file extracted?

Many thanks
 
Hi all

I have just run 'binwalk' to see if there are any differences between the old firmware and the new and it appears as though the Dahua have started to encrypt there images. Please find differences between old and new.
New:

binwalk romfs-x.squashfs.img

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x72AE579C, created: 2019-12-21 01:45:25, image size: 41054208 bytes, Data Address: 0xA0F00000, Entry Point: 0xA4500000, data CRC: 0x1155415A, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: gzip, image name: "NVR4X-S2"
3934067 0x3C0773 Zlib compressed data, best compression
6646576 0x656B30 Zlib compressed data, best compression
6647029 0x656CF5 Zlib compressed data, best compression
6647222 0x656DB6 Zlib compressed data, best compression
6655178 0x658CCA Zlib compressed data, best compression
6658199 0x659897 Zlib compressed data, best compression
6658986 0x659BAA Zlib compressed data, best compression
6659138 0x659C42 Zlib compressed data, best compression
6659179 0x659C6B 7-zip archive data, version 0.3
18263854 0x116AF2E 7-zip archive data, version 0.4
21253852 0x1444EDC 7-zip archive data, version 0.4
21966244 0x14F2DA4 mcrypt 2.5 encrypted data, algorithm: "~_xa", keysize: 26871 bytes, mode: "2",
22251354 0x153875A 7-zip archive data, version 0.4
24559037 0x176BDBD Zlib compressed data, best compression
25819743 0x189FA5F Zlib compressed data, best compression
34672141 0x2110E0D 7-zip archive data, version 0.3
41013320 0x271D048 Zlib compressed data, best compression
41015297 0x271D801 Zlib compressed data, best compression
41019514 0x271E87A Zlib compressed data, best compression
41025607 0x2720047 Zlib compressed data, best compression
41027481 0x2720799 Zlib compressed data, best compression
41033019 0x2721D3B Zlib compressed data, best compression
41038786 0x27233C2 Zlib compressed data, best compression
41044255 0x272491F Zlib compressed data, best compression
41046098 0x2725052 Zlib compressed data, best compression

Old:

binwalk romfs-x.squashfs.img

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x8C2162AF, created: 2019-08-09 03:56:17, image size: 41463808 bytes, Data Address: 0xA0F00000, Entry Point: 0xA4500000, data CRC: 0x8A9829AD, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: gzip, image name: "NVR4X-S2"
64 0x40 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 41459876 bytes, 2660 inodes, blocksize: 131072 bytes, created: 2019-08-09 03:56:17

Maybe this can shed some light why the files aren't being extracted.
 
Dahua made DSH with a lot more limited options than PSH.
There are the problems i had:
1. Encrypted kernel image
2. Encrypted rootfs with AES
3. Encrypted patitions with AES
4. All has different keys
5. Heavliy modified kernel to support mounting crypted partitions
6. Kernel thread to valdate sign of every binary file in camera and all are signed using SHA and RSA.
7. Even getting to /bin/sh wont let you run any binary not signed with their tools
8. Limited u-boot commands

There are more of this shit inside.

Yeah I have to agree. Been looking at latest (AES encrypted) firmware for 3 camera types for this week for fun, though mostly static analysis as don't have any Dahua cameras :)

As you say different (though related) AES keys for everything including kernel which then takes care of mounting the other encrypted partitions. Looking at the unencrypted partition files, Signatures in everything. So more overhead for the camera that's not necessary. Sure can be patched out (or maybe whitelisted) but what a pain (if I had any of these cameras that is).

Then derived the keys for and decrypted a different Dahua camera and it was running a C-SKY cpu with a non standard instruction set. yuk!

Still was an interesting exercise though.