Hikvision Chinese day of week fix question

[drocer 0]

Seems like a lot of work for nothing.

 

Also ..... How would the camera stand up to electronic signature or watermark.

 

No point if they show up as tamper.

 

Source = custom flashes, eventually depending on how much is actually proprietary. My guess is only codecs and embedded sensors are. This should the #1 item for the people complaining about chinese firmware.

 

Unknown whether this is still the same chip:

http://www.cctvforum.com/viewtopic.php?f=19&t=37006

http://www.ambarella.com.cn/uploads/docs/A5s-ipcam-product-brief.pdf

 

Linux 2.6.32 (or later) with drivers, kernel patches and toolchain

 

That looks like nice hardware to get control of. Would be funny if the cheaper camera's have the same hardware and are only limited via firmware.

[mroek 0]

Yes, it would be better to change the language flag in the flash, and the commands for doing so are already on the camera. Then no need to change davinci.

 

But I won't be doing that as I don't know what the ramifications are. To anyone that wants to try I would advise you nanddump all mtds to a server first and have access to the bootloader via UART just in case.

 

As you can see from the command I posted the language flag looks to be at 0x0654 in /dev/mtd5. Overwriting it with 0x01 may work, not work or brick your camera.

 

I'll stick with my davinci change as that won't kill that camera

Great info, good job!

I can fully understand that you don't want to try modifying the flash partition, I'm also reluctant. My cameras are all installed outside my house, and taking one down to experiment with this is not something I have the time to at the moment. However, if there is some brave soul that would try it, it would certainly be interesting. If there is in fact a simple way to permanently turn a Chinese camera into a US/European one, that would be good news.

 

I gather it should be possible to change this one byte in the mtd by using the dd-command to write to the flash instead of reading. That's what you meant, right?

 

When will you publish the required changes to the davinci binary?

[CBX 0]

Great info, good job!

 

Thanks

 

When will you publish the required changes to the davinci binary?

 

Now we seem to have confirmed things I hope to post today. Will do so in a new thread as this one has wandered a bit

[CBX 0]

Now posted.

 

Also, just to let you know the language flag also seems to be set in mtd6 also.

 

Specifically,

 

VAR=`dd if=/dev/mtd6ro skip=16 bs=1 count=1 2>/dev/null` ; if [ $VAR == $'\002' ]; then echo Chinese ; elif [ $VAR == $'\001' ]; then echo English ; else echo Unknown; fi

 

As to how to write this to flash, I think I'll keep quiet on that. If you don't know how, you shouldn't be doing it

[mroek 0]

Now posted.

 

Also, just to let you know the language flag also seems to be set in mtd6 also.

 

Specifically,

 

VAR=`dd if=/dev/mtd6ro skip=16 bs=1 count=1 2>/dev/null` ; if [ $VAR == $'\002' ]; then echo Chinese ; elif [ $VAR == $'\001' ]; then echo English ; else echo Unknown; fi

 

As to how to write this to flash, I think I'll keep quiet on that. If you don't know how, you shouldn't be doing it

As far as I know, the mtd layer should handle the necessary operations (erase before write etc) if the flash is accessed through either the block or the character device for the partition.

 

If this is true, then using dd to modify data within the partition should work. Are you saying that this is not the case here? If so, the only other option I can see would be nanddump and nandwrite.

[CBX 0]

As far as I know, the mtd layer should handle the necessary operations (erase before write etc) if the flash is accessed through either the block or the character device for the partition.

 

If this is true, then using dd to modify data within the partition should work. Are you saying that this is not the case here? If so, the only other option I can see would be nanddump and nandwrite.

 

I'm saying there is complexity depending on a variety of factors. Both in terms of changing the values in the flash memory correctly, and the ramifications of doing so.

 

You may change the flash memory only to find it fails checksum at bootloader stage, the kerlel load or davinci load. Then your camera may not boot, and TFTP may or may not be an option.

 

I'm not saying it can't be done, but I am sounding a note of caution. If I started putting up commands I think may work someone may brick their camera - I'm not going to do that.

 

Even if it's done correctly, if Hikvision take exception they could detect this upon future firmware upgrades and do who knows what. I've no idea if they care or not.

 

But good luck to anyone who wants to take this on!

[CBX 0]

I was primiarily interested in the kernel source as I wanted to turn my 2732 into a NAS server for my 2032 so they can record to the same SD card (the 2032 doesn't have an SD card slot), and I don't need to have a power hungry NAS/PC server with hard disk on all the time. Just to 2 cameras and the switch is all that is needed. That means I needed to compile kernel modules etc. As it turned out I managed to do by getting another Ambarella 2.6.8 linux kernel source released by a company of a different product who actually do abide by GPL V2 conditions. The point is they should release the linux kernel sources upon request.

 

Whether in China or no they accepted the license conditions by putting linux on their products. They should abide by that license irrespective of any enforcement issues. It should be noted that they have companies in other legal jurisdictions such as EU and US.

 

They haven't refused as of yet, but not yet provided them so we'll see.

 

They have now provided the kernel source. Well done Hikvision!

 

viewtopic.php?f=19&t=39874&p=242667#p242667

[drawz 0]

I bet if you simply copy the whole MTD5 and MTD6 partitions from a US camera, you'll get it to show up as a US camera. Most likely, these flash partitions are not touched during a firmware upgrade, which is why the language flag is persistent, even after a TFTP flash. And when you use TFTP, it just does as it's told and doesn't check the language flag.

 

The only issue would be if something else important is contained within these partitions, such as the MAC address of the network adapter(s), a serial number, or perhaps some information related to WIFI on devices that have it. A simple file comparison/differential after dumping these partitions from both a US and Chinese camera may help determine if there is any other useful information stored besides the language flag.

 

I think CBX mentioned he has RS232 access to the boot loader, which means he should be able to recover any brick this may cause. I would only recommend that someone with that kind of access try this in case I am wrong.

 

PS - I take no responsibility for anything that goes wrong!

[drawz 0]

Another useful hack would be to have DHCP enabled by default, which would save people a lot of grief if their network doesn't default to a 192.168.0.x IP scheme.

[CBX 0]

I bet if you simply copy the whole MTD5 and MTD6 partitions from a US camera, you'll get it to show up as a US camera. Most likely, these flash partitions are not touched during a firmware upgrade, which is why the language flag is persistent, even after a TFTP flash. And when you use TFTP, it just does as it's told and doesn't check the language flag.

 

I agree - it doesn't touch those areas and is why there is no point flashing a different region firmware.

 

The only issue would be if something else important is contained within these partitions, such as the MAC address of the network adapter(s), a serial number, or perhaps some information related to WIFI on devices that have it. A simple file comparison/differential after dumping these partitions from both a US and Chinese camera may help determine if there is any other useful information stored besides the language flag.

 

These partitions do indeed contain serial and MAC info, as well as device specific data. I would only advise anyone who is planning to write to flash to change the 2 language flags I've already identified, nothing else though I could be wrong (if Hikvision decide to compare serial code region to language flag for example).

 

I think CBX mentioned he has RS232 access to the boot loader, which means he should be able to recover any brick this may cause. I would only recommend that someone with that kind of access try this in case I am wrong.

 

I've said this also - the risk of bricking is real. Access to the bootloader and nand dumps of your flash areas beforehand should be considered prerequisites. It's also worth noting there is at least one CRC relating to the flash though I've not looked into which areas it covers.

 

PS - I take no responsibility for anything that goes wrong!

 

Me either

 

Another useful hack would be to have DHCP enabled by default, which would save people a lot of grief if their network doesn't default to a 192.168.0.x IP scheme.

 

It's 192.0.0.0/24 but I know what you mean. I always just added a virtual interface on the 192.0.0.0/24 subnet and configured from there - but whatever works. I never really understood why they used a public IP of 192.0.0.64 rather than the RFC 1918 private 192.168.0.0/16 range.

Edited March 2, 2014 by Guest

[drawz 0]

CBX - thanks for the info. It might be worth documenting this on a wikidevi page, where everything would be in one place and

there can be multiple contributors. I think someone else posted a teardown, which could be included. I'd also love to see a bootlog.

 

e.g. https://wikidevi.com/wiki/Netgear_WNDR3700

https://wikidevi.com/wiki/Western_Digital_My_Net_N750

 

These sorts of detailed documentation have allowed for some great work by the community on numerous devices.

 

I personally would still like to see a firmware/flash based permanent fix for the language flag. Patching the binary with each new version is a pain, and if you ever go away, the rest of us may never figure it out! It's also nice to avoid the need for a TFTP flash if only a US firmware is available.

[CBX 0]

CBX - thanks for the info.

 

You're welcome

 

It might be worth documenting this on a wikidevi page, where everything would be in one place and

there can be multiple contributors. I think someone else posted a teardown, which could be included. I'd also love to see a bootlog.

 

I certainly don't mind the info I've posted being reproduced though it would be nice to get a credit

 

I personally would still like to see a firmware/flash based permanent fix for the language flag. Patching the binary with each new version is a pain, and if you ever go away, the rest of us may never figure it out! It's also nice to avoid the need for a TFTP flash if only a US firmware is available.

 

Well I feel I've done my bit by identifying what I think are the language flag locations Good luck!

[Roswell426 0]

I agree with drawz, we need a developers wiki for all the good information that programmers are discovering about these cameras.

 

So I started one:

 

https://wikidevi.com/wiki/Hikvision

 

I will be adding more info as I find it, but please join in and contribute!

[buellwinkle 0]

Came across an oddity. I have Hikvision USA camera and MTD5 or for that matter MTD5RO is empty or all hex 'FF' but on my Chinese cameras there's the contents as described above and the dd command CBX wrote returns Chinese (or English after the CBX update).

 

The MTD6 file shows up as expected, the dd command shows English/Chinese, nanddump or dd the file has serial number and stuff as clear text.

 

CBX, wonder if you every encountered a USA version of the camera and seen this? Since it's not used in the USA camera, I wonder if mtd5 is referenced at all.