Hikvision Permanent Region Change

What IP address shows in SADP? Presumably not 192.0.0.64?
If it's showing in SADP there is a fair bit running OK, surprised that TFTP won't work.
I was hoping the last camera I bought would have been 5.2.8 but it wasn't, so I've had no hands-on chances yet.
Are you going to connect to the serial console to see why it doesn't boot completely? Could be illuminating ...
 
It's ok back on 5.2.5 now all Chinese, alot of difference, but it is possible to get it to a lower firmware as it came with 5.20.
 
I've got several Chinese 2532 and 2432 cams... One cam is 2015-01-10 and has the old simple checksum-16. I was able to edit MTD5/6 and upgrade to v5.2.5 and it stayed English. The 2015-01-24 and 2015-01-25 cams have the new checksum that I can't figure out. I compared a pair of them byte-by-byte, and did a summation of the block and the difference in sum is not the same as the difference in the actual checksums. So, it seems I can't just decrement the checksum by one when changing the language byte from 0x02 to 0x01. Has anyone figured out the new checksum?
 
The fact that the difference in the sum when you compare 2 cameras isn't the same doesn't necessarily mean it's not still a checksum-16, if that makes sense. There may be other camera-specific bytes excluded or included, in the final value.
If you are prepared to experiment with a little risk, you may well be able to simply change the checksum by the same amount that you change something like the language byte, instead of a recalculate.
I was hoping to test that out on my latest purchase, but unfortunately (or not) it was a late 2014 manufacture so didn't have the new checksum, it's quite happy to be changed.

But you may be able to experiment if you give yourself a way back by taking a copy of all the of all the camera flash storage as a first step.
If you can add a NAS storage destination at the web GUI, you don't have to format it to be able to use it, even if it's very large. As long as the 'Test' button is OK.
At an SSH or telnet prompt, use 'mount' to check the path used by the NAS storage. Let's say it's /mnt/nfs00 if it's an NFS share.

cd /mnt/nfs00
cat /dev/mtdblock0 > mtdblock0
And repeat up to mtdblock17, but omit block8 & 16, do them like this:
cat /dev/mtd8ro > mtd8ro
cat /dev/mtd16ro > mtd16ro
Edit your mtdblock5 & 6 for the language byte and checksum.
Put it back like so:
cat mtdblock5 > /dev/mtdblock5
cat mtdblock6 > /dev/mtdblock6
reboot

If the camera does not boot fully - it's quite likely (but not guaranteed) that it will sit on the 192.0.0.64 IP address with a telnet daemon running, in which case you can connect to it and restore the original mtdblock5 & 6
Of course your PC will need to be on the same network segment - use 192.0.0.128 which will also help with when you use TFTP to change the firmware.
And if that doesn't work - do you have a serial TTL to USB convertor?

*edit* Just a final thought - if a camera does 'brick' but the telnet access works, you may be able to get an idea of what the problem is by using
cat /proc/kmsg
and inspecting a large cryptic log. I upgraded a 5.2.0 camera to 5.2.3, should have been perfectly safe, but it didn't start up after. kmsg complained 'not unpacking initramfs - junk in it' or some such. Somehow it had become corrupted. So I restored mtdblock11 where initrd resides and it cam back to life.

*edit2* I'm assuming that it's known that Checksum-16 is a simple sum of its parts, and not something like a CRC.
 
Last edited by a moderator:
  • Like
Reactions: ken830 and whoslooking
Thanks for your thoughts. Since this is my first Hikvision purchase, how confident are you that I won't brick the cam (unrecoverable brick) with an invalid checksum? I already have SSH enabled, an nfs share mounted, and backups of the mtdblocks. I have previously recovered from a bootlooping cam with TFTP. I don't have a TTL serial cable, but it's not a huge investment if I need one later. Just want to guage the risk before I proceed with decrementing the checksum.
 
To be honest, I can't evaluate the risk, I haven't had the opportunity to try changing the new checksum, and the ways out of a failing boot.
We can only go by what we've seen posted on this forum where a few people have broken their cameras, and some have been recovered.
Let's see who else adds their thoughts - and encourages you to take the plunge!

*edit* If anyone who still has a 'bricked' camera after changing the language bytes would check or confirm if it is still accessible to telnet on 192.0.0.64 that would be useful.
Given telnet access, recovery should be straightforward.
 
  • Like
Reactions: ken830
Yes its still there on 04/2015, you first have to use tftp but don't close it, then you can telnet in on 192.0.0.64
Not sure above 5.2.8
 
I have a DS-2CD3410FD-IW model IP camera and it disconnects when I use cat /dev/mtdblock5 > temp5 command then I'm checking for temp5 file under /dev/ but it removes the file immediately. MTDUTILS doesn't work as well.
 
thehereticson said:
I have a DS-2CD3410FD-IW model IP camera and it disconnects when I use cat /dev/mtdblock5 > temp5 command then I'm checking for temp5 file under /dev/ but it removes the file immediately. MTDUTILS doesn't work as well.
Click to expand...

Try using the /tmp/ to copy them into.
 
alastairstevenson said:
To be honest, I can't evaluate the risk, I haven't had the opportunity to try changing the new checksum, and the ways out of a failing boot.
We can only go by what we've seen posted on this forum where a few people have broken their cameras, and some have been recovered.
Let's see who else adds their thoughts - and encourages you to take the plunge!

*edit* If anyone who still has a 'bricked' camera after changing the language bytes would check or confirm if it is still accessible to telnet on 192.0.0.64 that would be useful.
Given telnet access, recovery should be straightforward.
Click to expand...

No need to worry about bricking now, I have done a recovery guide if you do brick, but make sure you keep a copy of your mtd6 & mtd5 files.
 
thehereticson said:
I have a DS-2CD3410FD-IW model IP camera and it disconnects when I use cat /dev/mtdblock5 > temp5 command then I'm checking for temp5 file under /dev/ but it removes the file immediately. MTDUTILS doesn't work as well.
Click to expand...
That's not a camera I'm familiar with.
Before taking a copy of mtdblock5 & 6 you need to decide where to save it , and check there is sufficient space. Running out of space could trigger a reboot.
The block sizes can vary in size between models. Use the 'df' command to show used and free space for all the camera file systems.
It's very convenient, if you have a suitable network share available, to definea network destination using the 'storage' menus of the camera. It doesn't have to be formatted - but it does have to 'test' OK.
Find the assigned path using 'mount', then 'cd' to the destination, something like:
cd /mnt/nfs00/sharename
Then you won't have any space issues, and the files are generated off the camera.
 
Good evening
I managed to brick my DS-2CD2032-I dated 01/2015 by changing language flag, although for the 12/2014 worked as charm... both on 5.2.5 FW.
Here what i've done to unbrick it after digging this forums and internets (Huge Thank You to people who share their knowledge and willing to help others):

set PC IP to 192.0.0.128
tftp the cam with suitable firmware (5.2.5)
don't close tftp window
telnet or PuTTY trough telnet protocol to cam using 192.0.0.64
ftp to cam root mdtutils files from sbin directory (flash_erase, flash_eraseall, nandwrite)
ftp to cam root mtd5 and mtd6 backed up files (i did dump working mtd5&6 from my working cam labeled as 12/2014)






telnet 192.0.0.64
Trying 192.0.0.64...
Connected to 192.0.0.64.
Escape character is '^]'.


(none) login: root
Password:
login: can't chdir to home directory '/root/'
# chmod 777 flash_erase
# chmod 777 flash_eraseall
# chmod 777 nandwrite
# ./flash_eraseall /dev/mtd5
flash_eraseall has been replaced by `flash_erase <mtddev> 0 0`; please use it
Erasing 128 Kibyte @ 60000 -- 100 % complete
# ./flash_eraseall /dev/mtd6
flash_eraseall has been replaced by `flash_erase <mtddev> 0 0`; please use it
Erasing 128 Kibyte @ 60000 -- 100 % complete
# ./nandwrite -o /dev/mtd5 mtd5_temp
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
# ./nandwrite -o /dev/mtd6 mtd6_temp
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
# reboot

Now both are working and with full english OSD and english iVMS support. Language mismatch in iVMS is the reason i did try to hack my cams.
 
This camera uses a cramfs system and does not take the usual firmware, I haven't found another one like it apart from 5.3.0 2xx0.
 
Last edited by a moderator:
If I am trying to use the ./nanddump -nof mtd5_temp /dev/mtd5 command in Telnet I get an error that this command does not exist. So I tried the nanddump -nof mtd5_temp /dev/mtd5. And the error about the missing command is gone. But now Telnet tells me that the -nof is wrong. What have I done wrong?


Thanks in advance
 
Much easier just to use 'cat mtd5_temp > /dev/mtd5'
From what I recall the nanddump in the camera doesn't support all the usual command-line options, hence the original suggestion to mount the external mtdutils, which it looks like you haven't done.

*edit* Oh, and by the way, the cat command should be 'cat mtd5_temp > /dev/mtdblock5'
 
Last edited by a moderator:
Here is a screenshot of the communication

attachment.php
 

Attachments

  • Unbenannt.JPG
    Unbenannt.JPG
    94.8 KB · Views: 325
OK, you've mounted the folder with mtdutils in it.
But you have not changed the current directory to it as you have a space following the /nfs00 leaving that as the current directory.
And you can see that it's the busybox nanddump that's being invoked.
Use 'pwd' to confirm that.

*edit* Oh, and by the way, the cat command should be 'cat mtd5_temp > /dev/mtdblock5'
 
Last edited by a moderator:
OK. Thank you. I think it worked using the cat command. I downloadet the mdb files changed and uploaded them. How do I observe if the camera is changed to multi language?
 
How do I observe if the camera is changed to multi language?
Click to expand...
Presumably you've rebooted or power-cycled the camera.
It's the region code that's being changed, how that's used varies with the specific camera firmware.
If you are still running hacked firmware the 'prtHardInfo' command may show masqueraded data for language=
But what you're looking for probably is the language drop-down on the login screen.
 
It worked! I updated the cam to a new firmware and it is working in english language now. Perfect. Thank you!
 
You must log in or register to reply here.
Top Bottom