Hikvision 5.2.5 & 5.2.8 Full English (INC DAYS OF WEEK) mtd Hack

Is there a general consensus at this point as to which bytes are OK or "best" to modify in order to "balance the checksum"? I noticed that @whoslooking preferred modifying the MAC or Reset codes:

The change can be made in a few different locations, what you must remember is keeping the checksum intact, i found that the build date and serial number played up on some models, but the mac code and reset didn't have any side effects. If you find where else works and the model add to the post,
If the checksum is good it will still boot without bricking, but keep a copy of the mtd file just to be safe.
Click to expand...

But I would prefer not to play with my MAC address, and for that matter the reset code. I also would prefer not to go against the best practices set forth by those before me. I have seen several other posts that appear to mention that modifying the build date to account for the byte offset works OK, but I was hoping that @whoslooking might specifically chime in and mention whether your opinion on modifying the build date may have changed.

I'm thinking of performing this on about 5 2032 Chinese models that I received with 5.2.5 firmware (in English) - I don't know what version the boxes/stickers have on them. I have 8 other 2032's that all stream over the address rtsp://<username>:<password>@<ipaddress>/Streaming/channels/1 to a ZoneMinder server, but these 5 will not, and I was hoping that I could try other firmware versions (after doing the mtd hack) in order to enable that functionality. The US models that I have are version 5.1.6, and I've seen posts that mention that version being the most functional, so I will probably try that. I would still like to have the ability to upgrade to other English firmwares should this one not work out. I will attempt the mtd hack on the cameras in question on the 5.2.5 firmware. At that point, can I TFTP the 5.1.6 firmware posted by @whoslooking (the "freedom release"), or do I need to use the official English 5.1.6 firmware?
 
Last edited by a moderator:
The main reason for not touching the build date, is there is to many cross references in the firmware to the build date, version and serial number, that said it still works with that changed as well, as I have said before it's more about the balance than anything else.
Just remember to always back up your mtd files that way you can recover
 
Last edited by a moderator:
  • Like
Reactions: heathloder
You can use either after the mtd hack Mine or Original
 
But I would prefer not to play with my MAC address
Click to expand...
People have had no problems with using that to balance the region byte change, it seems a reliable choice.
If you are using it for DHCP reservations, it's simple enough to update your router settings.
You are right, best leave the 'Unique reset code' alone, in my view. You never know when you might need it.
 
  • Like
Reactions: heathloder
OK, so I just pulled the mtdblock5 and mtdblock6 off the first camera. Strange thing is, when I ran prtHardInfo, the terminal responds with version 5.2.3, but the web interface reads 5.2.5.

attachment.php



Either way, I had no issues with pulling the mtdblocks off, but I figured that I'd take a look at the checksum already in place (before making any modifications), just to make sure that Checksum-16 is indeed the algorithm used for my camera. When I highlighted the bytes in the hardware descriptor to get their checksum, I get a different value then what is already in place.


attachment.php



Again, this is before I made any changes. I believe I should be seeing 48 0E instead of 7F 0C. Is it true that the manufacturers have a way of getting the firmware to work without this checksum being correct, or can I just not use the mtd hack on this camera due to an unknown checksum algorithm? Basically, is it still OK for me to perform the mtd hack (being sure to balance the checksums by changing the same info in both mtd files) even though the checksum is not currently correct (using the Checksum-16 method)?
 

Attachments

  • Hik1OrigInfo.PNG
    Hik1OrigInfo.PNG
    42.8 KB · Views: 338
  • HxDHik1.PNG
    HxDHik1.PNG
    38.3 KB · Views: 337
The checksum is covering the hardware descriptor block, which is configured during manufacture to define the model number and options and device-specific things like serial number, MAC address, region code etc.
What the firmware hackers have managed to do for the sellers is to adjust the firmware to make a Chinese region camera (Language=2) to all intents and purposes dynamically masquerade as an English-region camera (language=1) whilst leaving the 'hardware descriptor block' and its checksum unchanged.

'Balancing the checksum' is the method that was used starting with early 2015 manufactured cameras where the calculated Checksum-16 value for the 0xF4 bytes after the checksum itself no longer matched that which was stored in the hardware descriptor block in mtdblock5 & 6. The scope of the bytes covered by the checksum calculation had been changed making the simple 'Checksum-16 sum of the 0xF4 bytes' invalid.
Forum members (@whoslooking I think was the first) determined empirically (ie trial and error ...) that a Checksum-16 was still part of the calculation by making changes that summed to zero when adjusting the region byte.
I hope that makes sense.

Curious about the differently reported firmware versions.
If you keep the original mtdblocks in a safe place you should be able to get back where you came from, though (unless the seller gave you a copy) it would be from an official Hikvision firmware download, or a tweaked one from this forum.
 
Thank you for the in-depth explanation. I believe I understand, at least for the most part.

What I am still confused about is if what you said means that I have one of the "post-2015" cameras you are talking about which means I can no longer use the simple 'Checksum-16 sum of the 0xF4 bytes' to change my region byte. Up to this point, I was under the impression that the cameras that were no longer vulnerable to the 'Checksum-16 sum' had 5.3.0 installed, or at least said that on the sticker, and would have a minimum of 5.2.5 FW installed. Mine appears to have 5.2.3 installed. I suppose that I have just not read about the others with firmware below 5.2.5...

Should I flash with 5.1.6 first and then try to do the mtd hack, or did I miss the point entirely and either: a) yes, I can modify the bytes, but I must modify the checksums for the 0xF4 bytes, or b) My camera is just not susceptible to the mtd hack?
 
I can no longer use the simple 'Checksum-16 sum of the 0xF4 bytes' to change my region byte.
Click to expand...
As of sometime early 2015, you can no longer simply calculate a new valid checksum after modifying something like the region byte, because it's no longer simply a 'Checksum-16 sum of the 0xF4 bytes that are after the checksum'. The byte range that is used to calculate the checksum is now unknown, it's been changed, it covers a bigger range, and has some additional steps.
But - to change the region byte you can quite simply ignore the checksum by making a double change, ensuring that what you subtract in one place (eg language to 01 from 02) you just add in another place (eg a byte of the MAC address changed to 0x57 from 0x56) - a 'zero sum'. This method will also work on the older manufacture cameras too.
The bottom line for your 20150125 camera is 'don't touch the checksum' or you will brick it.
But you can change the region code to 01 if you also pick another byte, for example at 0x67A, part of the MAC address, and change it to 0x57 from its current value of 0x56, ensuring the sum of both changes is zero.
 
  • Like
Reactions: vasycara and heathloder
I appreciate your patience... I do believe I understand now. Just for clarification then: I don't really need to know the checksum at all all so long as my modifications don't make the 'Checksum-16 sum of the 0xF4 bytes that are after the checksum' change from its original value. Correct?

(Sorry if my posts seem repetitive... There is just a lot of information - some very opininated - floating around on a couple of different threads here, and it's hard to keep up with the absolute latest)
 
Yes, that is correct.
You ensure there is no aggregate change that would affect the checksum comparison the firmware does by matching a reduction in value in one place (where you do want to make a change) with a corresponding increase in value in another place (where it doesn't matter if you make a change).
Good luck!
 
  • Like
Reactions: catseyenu
Figured I'd post my results after trying to perform the mtd hack on one of these cameras. First of all, I realized that my comment about the version differences reported by prtHardInfo and the web interface was incorrect - the particular camera I was working with had FW 5.2.3 installed, and was reported that way in both applications. I have 8 Chinese cameras and 6 US cameras, and of the 8 Chinese ones, almost NONE of them function identically.

Anyways... I modified the language byte from 02 to 01 and changed the second octect of the mac address from 56 to 57, as recommended. I double-checked the 'Checksum-16 sum of the 0xF4 bytes that are after the checksum' before and after the changes, just to be sure. I then restored the modified files to /dev/mtdblock5 and /dev/mtdblock6 respectively, and rebooted from the shell.

The camera began the dreaded reboot loop, but from what I've read so far, these cameras are practically indestructible from a FW standpoint (especially now with the Custom 3.0 firmware downgrader), so after a few patient reboots just to be sure that all configurations had been reloaded, I started tftp-ing firmwares to the camera. First, I tried two different 5.1.6 firmwares from this forum that were both posted by @whoslooking (one's labelled "CHINESE FULL ENGLISH" or something, and the other is just labelled "5.16 build 140612"). Neither worked, both leaving me in the same position as after the initial mtd hack - the reboot loop. So I tried with the 5.2.5 firmware in this thread: http://www.ipcamtalk.com/showthread.php/1784-Hikvision-2532F-IS-not-getting-any-audio-through/page2. It worked! Everything seemed normal, so I started configuring the settings back to the way I needed them. Once I got the camera all set up, I tried to reboot it, just to find that the reboot button in the web interface no longer did anything. Rebooting it by unplugging it and plugging it back in, did. I didn't really have any more time to mess with the interface to see what else didn't work, but it also appeared to be quite a bit slower, but that might have just been my patience leaving... I tried to find anything I could that might still be in Chinese, but I didn't find anything.

That being said, the camera is in a usable state, but it still doesn't respond to the URL I was initially trying to configure it for (/Streaming/Channels/1 over rtsp), so I am pretty determined to get these cameras on 5.1.6, if it's possible. Any insight as to what I might need to do to get myself on to 5.1.6?
 
Last edited by a moderator:
Nevermind... Sorry about the wasted space. I just noticed several posts from this thread where @whoslooking mentions that my symptoms describes one of the newer 5.2.x cameras and that "most version of manufacturing dates 2015/01 won't work with anything less than 5.2.5".

I guess this just means that I am stuck with 5.2.5 for the time being. Thanks for all the help nonetheless!
 
Last edited by a moderator:
  • Like
Reactions: catseyenu
heathloder said:
Nevermind... Sorry about the wasted space. I just noticed several posts from this thread where @whoslooking mentions that my symptoms describes one of the newer 5.2.x cameras and that "most version of manufacturing dates 2015/01 won't work with anything less than 5.2.5".

I guess this just means that I am stuck with 5.2.5 for the time being. Thanks for all the help nonetheless!
Click to expand...

There's nothing wrong with 5.2.5 now being stuck on 5.3.0 thats a place not to be happy with.
Since the release of 5.2.0 all Hikvision has done, is remove features nothing more.
Enjoy your camera's in your chosen language.
 
Last edited by a moderator:
this is my model. DS-2DC2202-DE3/W . I buy this product from China. web interface is in Chinese. Can I change it?
 
I have new chinese 2CD2032 and 2CD2132F-IS cameras with modyfied FW by seller.
There are one problem only - cameras cant connect to NVR by Hikvision protocol, record by motion detection is not avalable.

In order to change region
do i have to modify:
- language byte
- MAC address byte (better second octet)
- the checksum must be same

Correct?
 
Yes that's correct, what's more important is the checksum 16 remains
 
I modified mine by following your posted images. Is that sufficient too @whoislooking, or did I need to also change the date/MAC? Thanks.
 
yes totally, if you changed only the 2 bytes per MTD you should be good, if your camera reboots after the files are put back then you are good to go.
If it didn't boot it's the end of the world as it can be recovered.
 
You must log in or register to reply here.
Top Bottom