Dahua Firmware Mod Kit + Modded Dahua Firmware

[cor35vet]

Question out of ignorance but what does "dh_keyboard 0" do exactly? I've enabled telnet and poked around a little (gently) and run this command without setting any variable - it psits some info that looks to be related to flashing? Am mostly curious and like to poke at things Expecting to get myself some nice Starlight cameras to put up when the new year holiday is over...

This is a IPC-HFW4431M-AS-I2 with 2.420.0000.21.R, Build Date: 2016-07-24 firmware loaded.

The default for dh_keyboard is 1 which disables the serial UART on the camera that you could use to recover it when telnet is broken or the camera reboots right away (but still boots into linux).
So definitely set it to 0, there should be no drawbacks. (Unless you think it is a threat that someone takes apart your camera while it is running, solders two wires onto the pcb, gets root access and places a backdoor on it?? That they could do easier by unplugging the ethernet and flashing a modified firmware on it)

Does anybody have any idea what could be wrong with some HDBW4431R-S models I got from Aliexpress? These have 2.420.0000.21.R, Build Date: 2016-07-24 installed and English is the only language option available in the GUI.

I am assuming these are Chinese HW that's been hacked but I can't load the official Dec 2016 Chinese software update from the Dahua site onto these cameras - I can flash it using port 3800 and the camera is discoverable and I can telnet into it but have no web interface. The official English Eos update doesn't work either. Both custom Eos versions on here (2016-07-24 release the beta) also don't work. They will flash but don't give a web interface. I can flash the 2016-07-24 Chinese firmware back onto the device and it comes back to life.

I will release 2016-12-09 soon with a proper crack that makes the camera think it is an English region one that will hopefully solve your problems.
Got it ready here but haven't written down the changes or done longer testing. Exams keeping me busy.

 

[Fastb]

cor35vet,

You do great stuff here, thanks for your efforts.
I have almost the same cam BLKMGK, so I'm interested in the 2016-12-09 release you mentioned above.
Me: DH-IPC-HFW4431M-I2 with 2.460.0000.4.R, Build Date: 2016-06-21
H.265 doesn't work for playback
Substream goes wacky occasionally
The cam drops out for 3 minutes every few days, for no apparent reason
So I'm interested in flashing new f/w.

Good luck with the exams!

Fastb

 

[cor35vet]

Alright, update!
This firmware is based on the official English firmware unlike the previous versions which was based off of the chinese one.
However the English firmware by default was missing a bunch of IVS modes so I added them back (to the product configs).

For Eos (3rd gen) cameras (list below):
https://i.botox.bz/DH_IPC-HX4XXX-Eos_EngFraSpaRus_PN_Stream3_V2.420.0000.22.R.20161209.bin
(Software Version: 2.420.0000.22.R, Build Date: 2016-12-09)
MD5Sum: 1b8850f822860259ed7d1fd63f18220d
SHASum: 8256ae16dbee7cfa0910dbef5228b2ef151d0a73
Compatible cameras according to Dahua:

Spoiler

DH-IPC-HDBW4231R,DH-IPC-HDBW4236R
DH-IPC-HDBW4431R,DH-IPC-HDBW4436R
DH-IPC-HDW4231C-A,DH-IPC-HDW4236C-A
DH-IPC-HDW4233C-A,DH-IPC-HDW4238C-A
DH-IPC-HDW4431C-A,DH-IPC-HDW4436C-A
DH-IPC-HDBW4431R-S,DH-IPC-HDBW4436R-S
DH-IPC-HDBW4233R-AS,DH-IPC-HDBW4238R-S
DH-IPC-HDBW4231R-AS,DH-IPC-HDBW4236R-AS
DH-IPC-HDBW4431R-AS,DH-IPC-HDBW4436R-AS
DH-IPC-HDBW4231R-VF,DH-IPC-HDBW4431R-VF
DH-IPC-HFW4231F,DH-IPC-HFW4236F,DH-IPC-HFW4431F,DH-IPC-HFW4436F
DH-IPC-HFW4231B,DH-IPC-HFW4236B,DH-IPC-HFW4431B,DH-IPC-HFW4436B
DH-IPC-HFW4231D,DH-IPC-HFW4236D,DH-IPC-HFW4431D,DH-IPC-HFW4436D
DH-IPC-HFW4231R-Z,DH-IPC-HFW4431R-Z,DH-IPC-HFW4231R-VF,DH-IPC-HFW4431R-VF
DH-IPC-HFW4231F-AS,DH-IPC-HFW4236F-AS,DH-IPC-HFW4431F-AS,DH-IPC-HFW4436F-AS
DH-IPC-HFW4231B-AS,DH-IPC-HFW4236B-AS,DH-IPC-HFW4431B-AS,DH-IPC-HFW4436B-AS
DH-IPC-HFW4231D-AS,DH-IPC-HFW4236D-AS,DH-IPC-HFW4431D-AS,DH-IPC-HFW4436D-AS
DH-IPC-HFW4231K-I4,DH-IPC-HFW4236K-I4,DH-IPC-HFW4431K-I4,DH-IPC-HFW4436K-I4
DH-IPC-HFW4231K-I6,DH-IPC-HFW4236K-I6,DH-IPC-HFW4431K-I6,DH-IPC-HFW4436K-I6
DH-IPC-HFW4233K-I4,DH-IPC-HFW4238K-I4,DH-IPC-HFW4233K-I6,DH-IPC-HFW4238K-I6
DH-IPC-HFW4231M-I1,DH-IPC-HFW4236M-I1,DH-IPC-HFW4431M-I1,DH-IPC-HFW4436M-I1
DH-IPC-HFW4231M-I2,DH-IPC-HFW4236M-I2,DH-IPC-HFW4431M-I2,DH-IPC-HFW4436M-I2
DH-IPC-HFW4233M-I1,DH-IPC-HFW4238M-I1,DH-IPC-HFW4233M-I2,DH-IPC-HFW4238M-I2
DH-IPC-HFW4233K-AS-I4,DH-IPC-HFW4238K-AS-I4,DH-IPC-HFW4233K-AS-I6,DH-IPC-HFW4238K-AS-I6
DH-IPC-HFW4431K-AS-I4,DH-IPC-HFW4436K-AS-I4,DH-IPC-HFW4431K-AS-I6,DH-IPC-HFW4436K-AS-I6
DH-IPC-HFW4233M-AS-I1,DH-IPC-HFW4238M-AS-I1,DH-IPC-HFW4233M-AS-I2,DH-IPC-HFW4238M-AS-I2
DH-IPC-HFW4431M-AS-I1,DH-IPC-HFW4436M-AS-I1,DH-IPC-HFW4431M-AS-I2,DH-IPC-HFW4436M-AS-I2

Noteworthy:

• English, French, Spanish and Russian language.
• PAL/NTSC
• Unlocked option to disable P2P:
  • Network -> TCP/IP -> Easy4ip
• Hacked Playback to also work with NAS/NFS.
  • Playback tab will be enabled when you have an SD card (default) or enabled NAS/NFS feature. (F5 after you added a NAS)
  • Added option to select NAS instead of SD, obviously...
  • I barely tested it but it seemed to play fine... feedback welcome.
  • FTP can not be supported, stop using it, it's awful.
• Always enable serial console for disaster recovery.
• Unlocked all IVS modes.
• Disabled "CloudUpgradeServer".
• Telnet enabled permanently on port 2300.

Changes on Github: Commits · BotoX/DH_IPC-HX4XXX-Eos · GitHub

TIP: Reset your camera to default config before updating, seems like Dahua messed something up so sonia will crash on certain configs...

 

[cor35vet]

Aaand I bricked my HFW4431M-I2 ...
U-Boot still working says that the kernel boots but then gets stuck there because I was messing with some kernel modules... :v

Spoiler

U-Boot 2010.06-svn3089 (Jul 22 2016 - 19:15:59)
DRAM: 1 GiB
gBootLogPtr:80b80008.
Check spi flash controller v350... Found
Spi(cs1) ID: 0xC8 0x40 0x18 0xC8 0x40 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"GD25Q128"
partition file version 2
rootfstype squashfs root /dev/mtdblock7
In: serial
Out: serial
Err: serial
TEXT_BASE:81000000
Net: PHY found at 3

ETH0: PHY(phyaddr=-1, rmii) link UP: DUPLEX=FULL : SPEED=100M
MAC: 3C-EF-8C-FA-E7-88
Using gmac device
TFTP from server 192.168.254.254; our IP address is 192.168.1.108; sending through gateway 192.168.1.1
Download Filename 'upgrade_info_7db780a713a4.txt'.
Download to address: 0x84000000
Downloading: *
Retry count exceeded; starting again
Try again use backup_serverip
ETH0: PHY(phyaddr=-1, rmii) link UP: DUPLEX=FULL : SPEED=100M
MAC: 3C-EF-8C-FA-E7-88
*** ERROR: `serverip' not set
Failed to get info.txt
Fail to get info file!
Init error!
ETH0: PHY(phyaddr=-1, rmii) link UP: DUPLEX=FULL : SPEED=100M
MAC: 3C-EF-8C-FA-E7-88
Using gmac device
TFTP from server 192.168.254.254; our IP address is 192.168.1.108; sending through gateway 192.168.1.1
Download Filename 'failed.txt'.
Download to address: 0x82000000
Downloading: *
Retry count exceeded; starting again
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.4.35
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1453664 Bytes = 1.4 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ...OK
OK
partition file version 2
rootfstype squashfs root /dev/mtdblock7
fail to load bootargsParameters.txt
fail to load bootargsParameters.txt file
get bootargs info failed
cmdLine mem=85M console=ttyS0,115200 root=/dev/mtdblock7 rootfstype=squashfs
crashflasg:1, logmagic:54410011.

Starting kernel ...
Uncompressing Linux... done, booting the kernel.

So I guess I'll have to fuck with that SPI chip "GD25Q128".
Got a clip that attaches to it (one of the things I bought from ebay because I knew I'd need it one day )
Not sure if I should get an SPI programmer for this or use a raspberry pi?
Also have a "mySmartUSB light" for AVR that uses SPI so it should be able to flash normal SPI flash too, not only AVR?

Or maybe it is time for me to find out what the magical "upgrade_info_7db780a713a4.txt" does...
However IDA isn't very useful while looking at the

 

[keithshlo]

Thanks a lot cor35vet for your great work. I just flashed the firmware to my 4431CA. Although it said the upgrade had been successful, after the auto reboot, I can no longer access my camera via the same IP. I cannot even get any ping response from my camera. Can you please advise me what to do? Thanks a lot for your expertise.

 

[cor35vet]

Thanks a lot cor35vet for your great work. I just flashed the firmware to my 4431CA. Although it said the upgrade had been successful, after the auto reboot, I can no longer access my camera via the same IP. I cannot even get any ping response from my camera. Can you please advise me what to do? Thanks a lot for your expertise.

Do the IR lights turn off on your camera when it starts or do they stay on?
When did you download the file after I posted it, I swapped it out ~3 minutes after my post because I had a mistake in there that'd happen under certain conditions.

 

[tangent]

Not sure if I should get an SPI programmer for this or use a raspberry pi?
Also have a "mySmartUSB light" for AVR that uses SPI so it should be able to flash normal SPI flash too, not only AVR?

SPI is a pretty simply protocol, no need for a special programmer you can use an AVR or your PI. You can even do it with an RS-232 cable, level sifter, and some special software like this: RealTerm: Serial/TCP Terminal

 

[keithshlo]

Do the IR lights turn off on your camera when it starts or do they stay on?
When did you download the file after I posted it, I swapped it out ~3 minutes after my post because I had a mistake in there that'd happen under certain conditions.

I downloaded the new firmware when I got your message, as I subscribed to the thread. The IR lights stayed on for a moment when starting the camera, then they turned off. Can you please advise me what to do? Thanks a lot.

 

[cor35vet]

I downloaded the new firmware when I got your message, as I subscribed to the thread. The IR lights stayed on for a moment when starting the camera, then they turned off. Can you please advise me what to do? Thanks a lot.

If they turn off that means that the camera started, are you sure it doesn't ping?
Telnet should be running on it at the least but it could be that the camera is bootlooping so you need to be quick?

 

[keithshlo]

Thanks for your advice. However, even I just power up the camera, I still cannot get any ping response from it. The camera's IP was 192.168.2.200 when it was working. Could the firmware upgrade reset the IP address? Thanks.

 

[cor35vet]

Thanks for your advice. However, even I just power up the camera, I still cannot get any ping response from it. The camera's IP was 192.168.2.200 when it was working. Could the firmware upgrade reset the IP address? Thanks.

Shouldn't hurt to try 192.168.1.108 ?

 

[keithshlo]

Just tried and put my PC on the same subnet. Still doesn't work. Anything else I can try? Thanks.

 

[keithshlo]

Hi cor35vet, my camera may be bricked. I am considering to use TFTP to recover it. Do you have the TFTP firmware for 4431CA? I couldn't find it from Dahua. Thank you very much.

 

[cor35vet]

TFTP is not going to work unless someone figures out how to use "upgrade_info_7db780a713a4.txt"
I'd love to be the one that figures it out but I have no idea how to load the bootloader into IDA.

I have successfully recovered my camera however using a raspberry pi and no soldering!

Using following schematic:

You can find the clips/clamps for cheap on ebay, "SOIC8 clip"
I used a SOIC16 one that I had here + raspberry pi that was collecting dust with archlinuxarm and the tool flashrom.

Now the next thing I am going to try is replacing dahuas version of u-boot with the official one.

 

[alastairstevenson]

I'd love to be the one that figures it out but I have no idea how to load the bootloader into IDA.

Dumb question - what's stopping you grabbing a copy of the flash partition it resides in?

Now the next thing I am going to try is replacing dahuas version of u-boot with the official one.

Before you do that it may be a good idea to see where the board hardware info is provided.
I'd bet that there are a few hardware-specific values compiled in to the camera-specific u-boot.

An impressive bit of hacking by the way.
How does the setup handle the fact that on some pins of the flash IC there are competing drivers, including tying a couple to Vcc?

 

[cor35vet]

Dumb question - what's stopping you grabbing a copy of the flash partition it resides in?

Well the bootloader is already included in the firmware, that is not the problem.
However figuring out where the segments are and into which address they are loaded, where the main entry point of the bootloader is (after relocation) and inputting all that info into IDA so it can do it's auto analysis thing.

Before you do that it may be a good idea to see where the board hardware info is provided.
I'd bet that there are a few hardware-specific values compiled in to the camera-specific u-boot.

Thankfully HiSilicon provides an SDK for the Hi3516a SOC that Dahua is using.
And yeah there are a lot of changes that Dahua has done to their u-boot, however just reconfiguring this Hi3516 one to use the same addresses and partition layout as dahuas one should, in theory, already be enough to make it boot, no?

An impressive bit of hacking by the way.
How does the setup handle the fact that on some pins of the flash IC there are competing drivers, including tying a couple to Vcc?

I was actually afraid of that myself, first I tried accessing the flash while powering the camera - nope.
Then I just disconnected the power and did what the circuit I have post above does and it didn't power up the SOC.
I could read the flash right away with no further messing around.

So yeah recovering your camera is not even that hard, all you need is a SOIC clip with some wires and a raspberry pi.
Though I'd also recommend a CP2102 USB to UART bridge to know what is going on - or actually just use the UART on the Pi lol.

 

[alastairstevenson]

I'd love to be the one that figures it out but I have no idea how to load the bootloader into IDA.

Another method I've used, when the kernel won't run and had no ability to communicate except via the serial console, on a board with SPI NOR flash was to log the output of the bootloader 'spinor dump' command and convert the resulting hex file into binary, then split it down and analyse in the same way as a partition dump.

 

[cor35vet]

Another method I've used, when the kernel won't run and had no ability to communicate except via the serial console, on a board with SPI NOR flash was to log the output of the bootloader 'spinor dump' command and convert the resulting hex file into binary, then split it down and analyse in the same way as a partition dump.

Serial console is disabled on dahuas version of u-boot, else all you needed was a serial interface and two wires to restore the FW

 

[alastairstevenson]

Then I just disconnected the power and did what the circuit I have post above does and it didn't power up the SOC.
I could read the flash right away with no further messing around.

Neat.
I've never tried desoldering, I expect it would take a bit of practice.
What you've done as an alternative seems pretty good.

And yeah there are a lot of changes that Dahua has done to their u-boot, however just reconfiguring this Hi3516 one to use the same addresses and partition layout as dahuas one should, in theory, already be enough to make it boot, no?

That's not something I've tried, it sounded far too ambitious.
I'm assuming there are a lot more hardware-related values around than those in the SoC SDK which may be needed. But I'm only guessing from what I've seen poking around a bit in dtbs and the like.

 

[alastairstevenson]

Serial console is disabled on dahuas version of u-boot,

That's a mean trick.
I suppose that means there isn't the handy dandy set of strings that help figuring out what the code is likely to be doing.