whoslooking
IPCT Contributor
NVR region change?
- Thread starter SirJMD
- Start date
Ahmad Mohy
n3wb
- Joined
- Jul 19, 2015
- Messages
- 2
- Reaction score
- 0
i dont understand why the language would make diffrent if iam assuming the dvr and the cameras communicate in binery net work signals , 0000 and 11111
alastairstevenson
Staff member
In some of the newer NVR firmware, Hikvision can and does limit the ability to connect cameras that could be described as being purchased on the 'grey market', ie not through their authorised resellers, by not allowing use of the very functional 'Hikvision command and control protocol' with a complaint about 'language mismatch'.
The cameras and NVR communicate with a high-level protocol at Application Layer 7, well above the bits and bytes of the network layer.
The cameras and NVR communicate with a high-level protocol at Application Layer 7, well above the bits and bytes of the network layer.
Ok, i have gone to this topic in order to hack my cameras properly http://www.ipcamtalk.com/showthread.php/3474-Hikvision-5-2-5-amp-5-2-8-Full-English-(INC-DAYS-OF-WEEK)-mtd-Hack/
alexander.omiz
Young grasshopper
- Joined
- Jan 14, 2015
- Messages
- 33
- Reaction score
- 8
Changing the MTDBLOCK0 seems not work as cameras.You are correct, it shouldn't.
But the supplier had installed firmware that gave language=1 via getHardInfo (though not via /proc/hkvs/bootpara) so had English menus etc both via the web and the VGA/HDMI output.
The hardware descriptor, which is flashed during manufacture, shows language=2
So as delivered, it worked fine with cameras that were supplied with hacked English firmware, and also the same cameras subsequently converted to English region.
Before making any changes, I made a backup copy of mtdblock0,1 and 2 (which is where the firmware resides) and also created an installable firmware from mtdblock2 (with @wzhick Hiktools, I posted this somewhere here) so I could go back to as-delivered if I wished to. Which I have quite a few times during experiments. And - important - a copy of the system configuration after the settings and cameras were finalised, for each firmware version in use.
Going forward - a firmware upgrade via the web GUI maintains / maybe converts the system configuration, including the language, so the 3.2.1 firmware is still working as English despite the region still being Chinese.
That doesn't happen if I do a TFTP update as the config gets wiped - but if I reload the saved config specific to the version of firmware, all is OK again.
I hope that makes sense!
[root@dvrdvs hkvs] # df
Filesystem 1024-blocks Used Available Use% Mounted on
udev 87140 4 87136 0% /dev
/dev/mtdblock2 13520 13520 0 100% /home/hik
/dev/msa1 7815140 1641820 6173320 21% /mnt/msa1
[root@dvrdvs hkvs] # cd /mnt/msa1/
[root@dvrdvs msa1] #
[root@dvrdvs msa1] # cat temp0 > /dev/mtdblock0
cat: write error: Operation not permitted
[root@dvrdvs msa1] #
alastairstevenson
Staff member
That's correct, the Linux image in the NVR firmware is built with a RO (read-only) setting for mtdblock0, which will block any writes to that area of the flash. The RO status flag cannot be dynamically changed under /proc either.
Also - in some of the newer firmware - 3.2.1 for example - the size of mtdblock0 is set to half its actual, hiding away the section holding the 'hardware descriptor block'.
Also - in some of the newer firmware - 3.2.1 for example - the size of mtdblock0 is set to half its actual, hiding away the section holding the 'hardware descriptor block'.
alastairstevenson
Staff member
Eh? Wrong thread?
alastairstevenson
Staff member
You can build your own firmware with modified mtdblock2 - that's where the firmware is stored, it's purely a cramfs.img
Using the Linux kernel in the firmware - mtdblock0 is write-protected, and the u-boot bootloader is restricted to firmware updates only. Unless you know what zenmekeneng does.
Using the Linux kernel in the firmware - mtdblock0 is write-protected, and the u-boot bootloader is restricted to firmware updates only. Unless you know what zenmekeneng does.