hmjgriffon
Known around here
Good info, I can't think of any reason to use telnet though unless you're gonna do some cool programmer stuff, I've logged into hikvisions before and poked around and then was like meh, that was cool, heh.
Dahua Enable Telnet
- Thread starter nayr
- Start date
hmjgriffon
Known around here
I'd say if you don't know how to do that you probably don't belong testing firmware anyways lol wait til someone else is the guinea pig.
A posting for nothing. Do you want to disappoint me? I am not happy about this decision. And its not written in the change log for the cam firmware. So it´s of cause a bad news.
For me it´s not a security question, because i know how to set it up without beeing vulnerable. For me i use a separate real dmz for my cams (ipfire). I am not afraid of a bot
I only said, that now its much more work for recovering now.
And how knows for sure, that this is really wanted from dahua? Has anybody read about it? Or does they maybe only changed something again without documenting it. They are really experimental and every new firmware has new surprises.
This release has definitely new regressions.You can look in my weathercam thread.
I'm pretty sure it was mentioned in the changelogs:
and recovery does not require telnet access; if telnetd was running then upgraded is also running and you can push new firmware to it with the ConfigTool.. it was never an official way of recovery, they did not include any command line flashing tools.. serial access only needed if its no longer booting at all, and telnetd would not have even been running.
burning a new image with telnetd back into it is pretty trivial if you wish to restore such functionality.
telnetd served very little purpose and resulted in botnets spreading because idiots left default credentials; secure by default is a good thing.. these kinda devices shoulda never had telnet enabled in the first place.. they never advertised telnet access as a feature; so removing it is perfectly fine by me.
Code:
Optimizations & bug fixes:
1. Repair the network security vulnerabilities
2. Optimize smart codec effectand recovery does not require telnet access; if telnetd was running then upgraded is also running and you can push new firmware to it with the ConfigTool.. it was never an official way of recovery, they did not include any command line flashing tools.. serial access only needed if its no longer booting at all, and telnetd would not have even been running.
burning a new image with telnetd back into it is pretty trivial if you wish to restore such functionality.
telnetd served very little purpose and resulted in botnets spreading because idiots left default credentials; secure by default is a good thing.. these kinda devices shoulda never had telnet enabled in the first place.. they never advertised telnet access as a feature; so removing it is perfectly fine by me.
Last edited:
patching a firmware is not trivial, it´s the only known way for me for restoring these feature.
Security vulnerabilities can be everything (and maybe telnetd, you are right)
A bot must be able to activate telnetd first. Don´t know if this is possible from external or p2p. User with default credentials is not so easy, you must change the admin password with the first setup.
I hope the newer firmwares are more robust against bricking it self. In the firmware topic they wrote, that there are more checks nowadays before the flashing starts.
Maybe there is a unknown way for recovery. Who knows. I found a topic about tftp possibility without serial access .
Security vulnerabilities can be everything (and maybe telnetd, you are right)
A bot must be able to activate telnetd first. Don´t know if this is possible from external or p2p. User with default credentials is not so easy, you must change the admin password with the first setup.
I hope the newer firmwares are more robust against bricking it self. In the firmware topic they wrote, that there are more checks nowadays before the flashing starts.
Maybe there is a unknown way for recovery. Who knows. I found a topic about tftp possibility without serial access .
you can always find a copy of the version your running before updating; then reverting is very simple.. Dahua does not prevent you from downgrading versions.
Default credentials are not forced changed on first step; its encouraged but you can hit cancel and leave em defaults.. and thats a new feature on newer firmware released in last year.. updating from an older version is not likely to present that dialog, and few if any will ever update anyhow... The bots were enabling telnet then telneting in and infecting em; Dahua got hit VERY hard by the Marai Botnet on the older cameras.
Never heard of anyone misflashing or bricking a Dahua w/the the incorrect unmodified updates.. they have always been good about doing sanity checks before attempting to write.. Ive tried all sorts of wrong firmware for my cameras for years and it either worked or aborted.
If the system boots but Sonia fails to load for whatever reason you can push firmware files to it with the Dahua ConfigTool, Ive done it to fix cameras I fucked up w/custom firmware.. @cor35vet has totally FOOBARd a few cameras that required serial recovery, but he was hacking official images and caused his own problems.. yet recovery was still quite possible.
Your making mountains out of molehills; Telnet served absolutely no purpose for anyone not looking for a way to hack these things.. how is extracting the flash and burning your own firmware files manually any less trivial than dropping telnetd back into the image and adding it to init scripts? I have a feeling you never utilized what you claimed telnetd provided.
Default credentials are not forced changed on first step; its encouraged but you can hit cancel and leave em defaults.. and thats a new feature on newer firmware released in last year.. updating from an older version is not likely to present that dialog, and few if any will ever update anyhow... The bots were enabling telnet then telneting in and infecting em; Dahua got hit VERY hard by the Marai Botnet on the older cameras.
Never heard of anyone misflashing or bricking a Dahua w/the the incorrect unmodified updates.. they have always been good about doing sanity checks before attempting to write.. Ive tried all sorts of wrong firmware for my cameras for years and it either worked or aborted.
If the system boots but Sonia fails to load for whatever reason you can push firmware files to it with the Dahua ConfigTool, Ive done it to fix cameras I fucked up w/custom firmware.. @cor35vet has totally FOOBARd a few cameras that required serial recovery, but he was hacking official images and caused his own problems.. yet recovery was still quite possible.
Your making mountains out of molehills; Telnet served absolutely no purpose for anyone not looking for a way to hack these things.. how is extracting the flash and burning your own firmware files manually any less trivial than dropping telnetd back into the image and adding it to init scripts? I have a feeling you never utilized what you claimed telnetd provided.
Last edited:
Of course, i know. Maybe i didn´t specify exactly enough or i misunderstood you. I understand for bringing back telnet means patching the existing firmware.
I am no hacker and programmer, only a technician. Surly I have some knowledge about it but not in details.
You have forgotten me... I did it. I am not really sure how it was possible, but i flashed a version from the cz ftp which bootloops my hdw4431, i wrote about it. And it was not a really old firmware i started from. So i think, of course under some circumstances it´s possible.
I agree to you, that almost every normal customer don´t need it. I only wanted to explain, why I think a telnet can be useful. In my mind, dahua goes the wrong way for making there cams securer. Ok, telnet is one small part:
I mean, the better way would be an open update function, and an auto update possibility for security updates. This would be a big step. If they would release security updates for all customers, for all cams it would be also a very wise way. AVM as a german manufacture of router did it by this way, proactive! The hole market for IOT devices is having this problem. To many old libarys, so many open vulnerabilitys which are not closed because of making fast money.
Anyway, no one cares about it, until the reputation and customers are gone. That´s the business.
And you are also right, you can cancel changing admin password. A bad decision and why the hell is it allowed? It´s simple to change this. Or another simple way is to send every cam with a different secure password.
Your 4431 was hacked from the seller you bought it from; it was not running virgin dahua firmware if you had it in english.. thats why you had issues updating, one should really avoid buying cameras offered only to the Chinese domestic market.. if you dont find it listed on an english language Dahua site; its not an english language camera.. The chinese firmware for your camera off Dahua's china site should had been fine but you'd of lost english language, no guarantees everything going to go well when your camera has been modified by a 3rd party.
Auto Update would be horrible; as you see sometimes features are regressed and recovery is not very simple.. this should require interaction, always.. you cant wipe it and reload it like you can your windows desktop.
Many vendors test cameras before shipping them back out; they are likely to power it up and login and check its got a good image.. those guys are gonna hit cancel and not make any out of the box changes.
Auto Update would be horrible; as you see sometimes features are regressed and recovery is not very simple.. this should require interaction, always.. you cant wipe it and reload it like you can your windows desktop.
Many vendors test cameras before shipping them back out; they are likely to power it up and login and check its got a good image.. those guys are gonna hit cancel and not make any out of the box changes.
By short, i had talked with my german distributor about it. He is an office Seller for DACH. I had ordered the first cam of this type, and i was really unsatisfied about the changed plastic bottom. Now on all english and DACH sites, the material is metal and you can see the screw for fixing it, which is missing for the platic bodys. My distributor didn´t order them again, because of the plastic base which is a really bad quality. Now together with your suggestion, that we received a chinese cheap speacial one some points make sense. And also a not really good working quality of sound (like other here wrote, it crackles sometimes) and some performance problems with h265.
But maybe i use with a hdw4431EM-AS (DACH) version the wrong firmware for hdw4431E-AS (which i got)
Not if you use 2 ways, one for future updates, one for security. It is possible without interaction. Avm has solved it in a very good way. And they do it for the hole lifetime of there products (on of the first fritzbox 7170 has also received the telnet hack update, this one is over 10 Years old) After the big security fix (you could get root access from webbrowser) the changed from manual to auto update with 2 version (stable and feature)
But we are going to much off topic. Its an interesting discussion for me, but maybe to specific for here.
Do you happen to have a camera or firmware with german language? (Does that even exist?)
Serial Port, read: Dahua IPC unbricking / recovery over serial UART and TFTP
Get in with serial into the bootloader, then do "setenv dh_keyboard 0" and "boot".
You should have a root shell now where you can use the following script to backup all the mtd partitions:
Code:
#!/bin/bash
echo "Backing up to: $(pwd)"
echo "Enter to continue, CTRL-C to abort."
read
cp /proc/mtd ./layout.txt
# List remote mtd devices from /proc/mtd.
# The first line is just a table header, so skip it (using tail)
cat /proc/mtd | tail -n+2 | while read; do
MTD_DEV=$(echo $REPLY | cut -f1 -d:)
MTD_NAME=$(echo $REPLY | cut -f2 -d\")
echo "Backing up $MTD_DEV ($MTD_NAME)"
cp "/dev/${MTD_DEV}ro" "./${MTD_DEV}_${MTD_NAME}"
done
echo "MTD backup complete."Also when saving watch out for lineendings, or use dl link: https://i.botox.bz/backup_mtd.sh
when I use this and for the telnet function ok , and then I use putty to telnet , but failed. what is the reason , for the device is dh-hdw4431c-a
Dahua has disabled telnet on the new firmware.
On HDW4431C-A you can use my patched one to get telnet (on port 2300). vvvvvvvvvv
I am using dahua XVR4104-HS model, when put the "
http://<ip-address>/cgi-bin/configManager.cgi?action=setConfig&Telnet.Enable=true" an error appears as
Error
ErrorID=5, Detail=Server internal error!
Please suggest what should I do ? what could be next step ?
Thanks
http://<ip-address>/cgi-bin/configManager.cgi?action=setConfig&Telnet.Enable=true" an error appears as
Error
ErrorID=5, Detail=Server internal error!
Please suggest what should I do ? what could be next step ?
Thanks
New Dahuas has DSH (Dahua Protected SHell):
Code:
#help
Support Commands:
shell help getDateInfo
diagnose gethwid
Please set UTF-8 character encoding format in terminal for displaying Qrcode
#ls
ls:Not support try help!
#