I'm sorry to say but your camera is using Motorola M-Core processor (the other cameras i patched were using ARM cores) and is not supported by the version of IDA Pro I have.
That means I can not patch it, sorry
That means I can not patch it, sorry
How it problem solved? I not see with COM-port debug info...(((I'm sorry to say but your camera is using Motorola M-Core processor (the other cameras i patched were using ARM cores) and is not supported by the version of IDA Pro I have.
That means I can not patch it, sorry
You can use the firmware for Eos camera in the first post.
Direct Link: https://i.botox.bz/DH_IPC-HX4XXX-Eos.bin
I've also just updated the firmware in the first post, changes are:
- Added russian language.
- Unlocked options to disable P2P:
- Network -> TCP/IP -> Easy4ip
- Network -> Access Platform -> Lechange Pro
- Unlocked "Auto Register" in Network settings, no idea what it is. Maybe something the NVR sets?
- Unlocked Remote Log in Log.
- I think Lock Login in System -> General is new?
- 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.
Sadly still no new firmware version for Eos from Dahua....
Hello cor35vet,
Thank you very much for the great effort!
I have tried your Build: https://i.botox.bz/DH_IPC-HX4XXX-Eos.bin (Software Version: 2.420.0000.21.R, Build Date: 2016-07-24) and unfortunately the FTP option for Storage is consuming all 100% CPU in my server.
When I disable the FTP under Storage > Destination > FTP the CPU goes to normal values.
I have 9 cameras on my system and 1 of the cameras has your firmware. As soon I enable the FTP on the camera with your firmware CPU gets to 100%.
Is there any chance you can help me please?
Thank you very much for the great effort!
I have tried your Build: https://i.botox.bz/DH_IPC-HX4XXX-Eos.bin (Software Version: 2.420.0000.21.R, Build Date: 2016-07-24) and unfortunately the FTP option for Storage is consuming all 100% CPU in my server.
When I disable the FTP under Storage > Destination > FTP the CPU goes to normal values.
I have 9 cameras on my system and 1 of the cameras has your firmware. As soon I enable the FTP on the camera with your firmware CPU gets to 100%.
Is there any chance you can help me please?
Attachments
Try flashing the official dahua one: ftp://ftp.asm.cz/Dahua/kamerove_systemy/_Firmware/04IPC/IPC-HX4XXX-Eos/DH/1607/
I doubt that I have anything to do with that.
Also stop using FTP, NFS is far superior.
Thank you very much for your answerer. I will consider start using NFS.
How you suggest me to flash the camera with the firmware you sent me? Do I use the Web Interface on the camera or the Config tool? I don’t want to brick the camera, by now is more complex to telnet. Any precautions?
Kind regards,
Sergio.
I always flash through webinterface. No problems.
Just make sure your camera doesn't turn off during flash - that's certain death.
Hi,
I'm trying to unbrick a HDW4431C-A which is stuck in a bootloop after flashing DH_IPC-HX4XXX-Eos_Eng_P_Stream3_V2.420.0000.21.R.20160724.bin
I tried to use a serial connection in order to interrupt Uboot, but it seems like the '***' characters do not interrupt it.
I've previously used this method successfully on other Dahua equipment, so I know my PC setup/FTDI serial dongle is ok.
I see the Uboot text, so I know the serial line TX is connected ok. Does anyone know whether the RX line is working ok
and whether '***' should still work with this camera? Or did they perhaps disable this method in recent firmware builds ?
In case this method is no longer viable, does anyone know another way to prevent the bootloop and allow a firmware update ?
I tried the method of enabling telnet, but using the http URL to enable this won't work as I seem to loose connection with the camera really fast and the page ends up not loading completely. Even a ping only responds 3 times during the boot phase.
Perhaps using this special TFTP file upgrade_info_7db780a713a4.txt ?
Uboot version which is displayed upon booting is 2010-06.svn3089 (Jun 20 - 2016 - 12:33:38)
I'm trying to unbrick a HDW4431C-A which is stuck in a bootloop after flashing DH_IPC-HX4XXX-Eos_Eng_P_Stream3_V2.420.0000.21.R.20160724.bin
I tried to use a serial connection in order to interrupt Uboot, but it seems like the '***' characters do not interrupt it.
I've previously used this method successfully on other Dahua equipment, so I know my PC setup/FTDI serial dongle is ok.
I see the Uboot text, so I know the serial line TX is connected ok. Does anyone know whether the RX line is working ok
and whether '***' should still work with this camera? Or did they perhaps disable this method in recent firmware builds ?
In case this method is no longer viable, does anyone know another way to prevent the bootloop and allow a firmware update ?
I tried the method of enabling telnet, but using the http URL to enable this won't work as I seem to loose connection with the camera really fast and the page ends up not loading completely. Even a ping only responds 3 times during the boot phase.
Perhaps using this special TFTP file upgrade_info_7db780a713a4.txt ?
Uboot version which is displayed upon booting is 2010-06.svn3089 (Jun 20 - 2016 - 12:33:38)
The dahua build of u-boot disables serial console so you can not interrupt it.
When I bricked mine it would boot linux and I got a console (over serial UART) where I could killall sonia or ^C it, can't remember.
Then you can flash my firmware from there by launching "upgraded" service or using flashcp (expert mode - dangerous)
OH CRAP ATTENTION!!!! AFTER YOU KILL SONIA DO NOT FLASH FIRMWARE BECAUSE THE WATCHDOG WILL MURDER YOUR CAMERA IN 30 SECONDS!!!
Run "appauto 0" and "dh_keyboard 0" right after killing sonia - then let the camera reboot and it will not run sonia anymore and you can play around with the console
I've tried ^C, after the message "Uncompressing Linux...... done, booting the kernel" but this will not show me any console.
I think in order for this to work I would have already needed to have set dh_keyboard 0 in order to see the console right ?
When dh_keyboard still on 1 only prevents me to see the console but does allow me to type then it might be possible to do a 'blind login' perhaps..
Does anyone have an automated script that force repeats such a login with a killall sonia etc ?
I think in order for this to work I would have already needed to have set dh_keyboard 0 in order to see the console right ?
When dh_keyboard still on 1 only prevents me to see the console but does allow me to type then it might be possible to do a 'blind login' perhaps..
Does anyone have an automated script that force repeats such a login with a killall sonia etc ?
Oh, well fuck. Untitled - p.botox.bz
I don't think you'll have much luck with serial...
If you can use curl to enable telnet on the camera that'd be great.
This is why I enable telnet on my images by default ^^
I should probably also remove that crap up there from my images, absolutely stupid.
Yeah, I can't think of anything other than trying to enable telnet with curl.
That or flashing the SPI chip on there - I can make a full dump of the flash chip if you want to do that.
If you don't have the hardware/skill for that you could donate the camera to me so I can try to play with a dead one xd would be fun trying to flash a custom bootloader on it.
I don't think you'll have much luck with serial...
If you can use curl to enable telnet on the camera that'd be great.
This is why I enable telnet on my images by default ^^
I should probably also remove that crap up there from my images, absolutely stupid.
Yeah, I can't think of anything other than trying to enable telnet with curl.
That or flashing the SPI chip on there - I can make a full dump of the flash chip if you want to do that.
If you don't have the hardware/skill for that you could donate the camera to me so I can try to play with a dead one xd would be fun trying to flash a custom bootloader on it.
Think also the serial option will be a no-go as I have the feeling I must have had set dh_keyboard 0 in advance for a shell.
A full dump would be great ! I might try this tomorrow then using an arduino.
If you have some info on the chip location on the cam that would be great btw.
I assume that I will need to desolder it, have you done this before yourself ?
Also, do you know whether I would have to skip a certain region in order for the cam to maintain a unique serial number ?
Thank so far for your responses and support !
A full dump would be great ! I might try this tomorrow then using an arduino.
If you have some info on the chip location on the cam that would be great btw.
I assume that I will need to desolder it, have you done this before yourself ?
Also, do you know whether I would have to skip a certain region in order for the cam to maintain a unique serial number ?
Thank so far for your responses and support !
Check this file for layout: https://p.botox.bz/view/raw/1f421280
hwid is the u-boot environment which contains your serial number.
by using my script you can unpack the firmware (my modded one probably since telnet is already enabled) - you'll have a bunch of .raw files in there, these are the raw partitions, the information where they are flashed is stored in the uImage header (in filename without .raw)
Output looks like this:
mkimage -l dhboot.bin.img
Image Name: boot
Created: Sun Jul 24 05:02:22 2016
Image Type: ARM Linux Firmware (uncompressed)
Data Size: 188416 Bytes = 184.00 kB = 0.18 MB
Load Address: 00090000
Entry Point: 000c0000
Load Adress = start address
Entry Point = end address
the check.img is not flashed btw.
so you can flash the partitions each by itself with the right offsets from the uimage headers or the partition.txt
if you just corrupt the user partition then you should drop into an emergency shell where you can start telnet - or probably not because startup script dh_keyboard symlinks the terminal tty to /dev/null XDDD
so eh yeah either flash these or wait until I make a full dump tomorrow because going to sleep now :V
Getting familiar with GitHub - BotoX/Dahua-Firmware-Mod-Kit: Unpack and repack Dahua IP camera firmware upgrade images. is probably not a bad idea ^^
hwid is the u-boot environment which contains your serial number.
by using my script you can unpack the firmware (my modded one probably since telnet is already enabled) - you'll have a bunch of .raw files in there, these are the raw partitions, the information where they are flashed is stored in the uImage header (in filename without .raw)
Output looks like this:
mkimage -l dhboot.bin.img
Image Name: boot
Created: Sun Jul 24 05:02:22 2016
Image Type: ARM Linux Firmware (uncompressed)
Data Size: 188416 Bytes = 184.00 kB = 0.18 MB
Load Address: 00090000
Entry Point: 000c0000
Load Adress = start address
Entry Point = end address
the check.img is not flashed btw.
so you can flash the partitions each by itself with the right offsets from the uimage headers or the partition.txt
if you just corrupt the user partition then you should drop into an emergency shell where you can start telnet - or probably not because startup script dh_keyboard symlinks the terminal tty to /dev/null XDDD
so eh yeah either flash these or wait until I make a full dump tomorrow because going to sleep now :V
Getting familiar with GitHub - BotoX/Dahua-Firmware-Mod-Kit: Unpack and repack Dahua IP camera firmware upgrade images. is probably not a bad idea ^^
Thanks again for your reply.
I'll look further into desoldering the chip etc tomorrow as I'm also going to sleep now
.
I already have experience with the firmware unpacking so that will give me a headstart.
I would still appreciate a full dump but only if its not too much hassle for you ..
I'll look further into desoldering the chip etc tomorrow as I'm also going to sleep now
.I already have experience with the firmware unpacking so that will give me a headstart.
I would still appreciate a full dump but only if its not too much hassle for you ..
Last edited: