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

Hi I have a DS-7616 Region 2 English Hack and multiple cameras Region 1 English Hacked as well. I get Language Version Mismatch on the NVR. Question is will the MTD hack on the Cameras fix this? And which version firmware do I need to do the MTD hack? I have 5.2.0 on the 3MP bullet and 5.2.3 on the 3MP Cube. All Hikvision products.

Also I wanna vent that Hikvision is doing alot to stop this kind of stuff and I hope they know it will hurt their sales. I will switch back to Dahua if Hikvision continues with adding restrictions such as unable to downgrade, cloud services, camera checking in with hikvision servers, removing ssh and telnet, etc.
 
Hi with the camera you have, the best option is the mtd hack then load 5.1.6 to get the best functions out of your camera's
Your camera will be all good to go on English firmware after the hack is done.
 
  • Like
Reactions: IPCAMPR34
Thanks, 2 things...

1) Does 5.1.6 have line crossing and motion detection? I like having line crossing send me an email but motion detection record to NVR.

2) I tried the MTD hack but I cannot find the values they were talking about changing, which firmware do I need on my camera to do the MTD hack successfully?

Thanks whoslooking!

whoslooking said:
Hi with the camera you have, the best option is the mtd hack then load 5.1.6 to get the best functions out of your camera's
Your camera will be all good to go on English firmware after the hack is done.
Click to expand...
 
If you get the mtd files off your camera, add them to dropbox and PM me the links I will change the values for you.
 
Did you ever test an untouched legit region=1 mtd5/6 dump on a chinese device? If this doesn't work either on v5.3.0 the trigger must be somewhere else. Maybe there's different hardware/vendor strings or something. There is also no trace to mtd5/6 in davinci binary. The actual data access to mtd5/6 might be done by other libs or they access the flash memory by other interfaces (i've seen 'ioctl' apis related to the errors below, whatever that is...:)).

When i adapt/apply CBX's davinci patch to v5.3.0 it triggers additional integrity check violations.
.text:00225040 54 90 C4 E5 STRB R9, [R4,#0x54]
.text:00225044 82 30 DD E5 LDRB R3, [SP,#0x148+var_C6]
.text:00225048 30 90 9D E5 LDR R9, [SP,#0x148+var_118]
.text:00225048 01 90 A0 E3 MOV R9, #1
Click to expand...

I have no experience with firmwares below v5.3.0 but if i get it right CBX's davinci patch sets the language bit after the checksum function has been successfully passed already (otherwise it wouldn't have worked at all in the past).

Did you manage to attach an online debugger yet?
 
Last edited by a moderator:
I have tried the CBX patch and he went about it in a different way, but I didn't try it on a 5.3.0 camera as there is no English files in the camera to start with, as he no longer supports this maybe its time to decompile the patch to see how he was going about it.
 
whoslooking said:
I didn't try it on a 5.3.0 camera as there is no English files in the camera to start with
Click to expand...
I meant running legit donor (from real EN device) mtd5/6 on EN firmware and chinese hardware.

whoslooking said:
maybe its time to decompile the patch to see how he was going about it.
Click to expand...
What i posted above is the decompiled CBX patch. See here. Some posts back it's confirmed it's CBX's patch.

It should get you on the right track easily (if you have a proper debugging environment) regarding calculating the checksum and the additional integrity check to get 5.3.0 running properly just by mtd hacking (or get the reason why it's failing).
 
  • Like
Reactions: catseyenu
I think one of the reason Tom stop his support was he new it wouldn't work on 5.3.0. Thats why he was starting to offer firmware
again nothing above 5.2.5 due to the change is firmware structure.

Hey, but I maybe proved wrong but until I see it.

Can you add the complete decompile to a dropbox as would like to see the serial number checking side of the patch.
 
Last edited by a moderator:
I used to patch my 5.1.6 cameras with this:
nanddump -obf /dav/mtd6copy /dev/mtd6
echo -ne '\x01' | dd of=/dav/mtd6copy bs=1 seek=16 count=1 conv=notrunc
dd if=/dav/mtd6copy of=/dev/mtdblock6
Click to expand...
This fully worked but didn't touch the checksum or MAC or even mtdblock5. Will the cameras still boot if I upgrade them to 5.3.0?

Also, if I do remember well, mtdblock5 is parsed from mtdblock6 at boot, hence why changing mtdblock5 won't work alone and wasn't even needed.

I am beginning to wonder if all the people who didn't tell how to change the language permanently (like me as I agreed with CBR to not disclose my method till now that I see that the method has been disclosed anyway) were not just trying to avoid Hikvision making tougher checks, like it seems to be the case in 5.2.5 or 5.3.0?
 
Last edited by a moderator:
The 'hardware descriptor blocks' in the flash of the Hikvision camera and NVR series in question is flagged by the Hikvision 'magic number' SWKH, and the assignment of the values to device hardware configuration is largely given away in the 'bootpara' boot info list that the firmware refers to when determining mode of operation.
 
renaud said:
I used to patch my 5.1.6 cameras with this:

This fully worked but didn't touch the checksum or MAC or even mtdblock5. Will the cameras still boot if I upgrade them to 5.3.0?

Also, if I do remember well, mtdblock5 is parsed from mtdblock6 at boot, hence why changing mtdblock5 won't work alone and wasn't even needed.

I am beginning to wonder if all the people who didn't tell how to change the language permanently (like me as I agreed with CBR to not disclose my method till now that I see that the method has been disclosed anyway) were not just trying to avoid Hikvision making tougher checks, like it seems to be the case in 5.2.5 or 5.3.0?
Click to expand...

That was CBX understanding too, as he didn't touch mtd5, but in the original region 1 camera the mtd5 is also changed.
It was only after 5.2.5 that the checksum -16 was totally necessary or the camera would brick to min-system 4.08.
 
whoslooking said:
It was only after 5.2.5 that the checksum -16 was totally necessary or the camera would brick to min-system 4.08.
Click to expand...
What do you mean by min-system? MTD8 (recovery)?

I have a hard time booting up 5.3.0 EN on CN device. Did previous EN firmwares ever work (no matter in what language state) on CN devices?
Do 5.2.x language patched firmwares (or mtd hacked) CN devices provide english interfaces for 'remote config' (eg. in ivms)?
 
Before 5.2.5 the checksum didn't check the mtd5 or mtd6 files, thus allowed us to fully swap the region, so just changing the flags allowed all languages to work and no futher hacking was needed, this seem to have changed with 5.3.0 the languages have all been stripped from the CN camera fw.
Yes a mtd hacked & custom fw allows the NVR and IVMS to work correctly
 
Sure.. but what exactly is "min-system"? A different kernel/initrd booted up or davinci that puts you in jail (degrades the hw capabilities)? Mtd8 is a completely isolated system on flash that one could also call "min-system" (the telnet/recovery system after tftp). That's why i'm asking what you mean by min-system.
I was about to patch mtd6 as i read your post "it will put you in min-system" so i will not do it until i have the checksum but i would like to know what it is.

Are these CN devices exact hardware clones? Do they have minor quality cmos chips or something?
 
Last edited by a moderator:
Sorry yes, min-system is recovery based os this has not changed,
no the camera's are identical in every way, it's just ment for the home region of China only,
The mtd balance only needs to be done on 5.2.5, it will min-system a 5.3.0 and 5.2.3 or below doesn't care about the balance.

The easy way to get inside a 5.3.0 is to use the downgrader to take you to 5.2.5 then look at the other mtd's
 
  • Like
Reactions: Maniaxx
Sure.. but what exactly is "min-system"? A different kernel/initrd booted up
Click to expand...
The 'mini system' is invoked when post-bootup checks suggest that there is a problem with the full system, for example after an upgrade to an incompatible firmware version.
It's a Linux image, shows in SADP typically as version 4.0.8, that doesn't load any of the application modules of the camera, but still does provide a good deal of functionality. Networking is active including telnet, and full access to the flash areas is available.
It may well be loaded from mtdblock8, that does have a Linux image, but I've never checked it out,.
Here is a log fragment below of 'mini-system' being invoked following installation of a tweaked version of the 5.3.0 firmware where a couple of status indicators were not left in the needed state, possibly due to a validity check.

[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_srcs_write][2080]:Firm file=t1 upgrade write beg.
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_srcs_write][2102]:Firm file=t1 upgrade write end.
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_part_finish][780]:UPG PART FINISH SET:iVersionFlg=0x10000,iUpgSuccCnt=0x3,iUpgFailCnt=0x0
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_upglib_proc][2151]:Firm iPackIdx=0 upgrade end.
[06-25 15:36:54][pid:852][PSIA][ERROR]************* PSIA Upgrading END **************,iRet=0
[06-25 15:36:55][pid:852][OTHER][ERROR] checkUserIdValid is ERROR
[06-25 15:36:55][pid:852][SYSLOG][ERROR]Invalid userID 0

U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|BIND err|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2015-03-20 17:37:48 CST)
starting pid 378, tty '': '/etc/init.d/rcS'
Starting udev: [ OK ]
UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:0x0, sec_iUpgSuccCnt:0x0
pri_part and sec_part data error.
cat: read error: Invalid argument
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot

U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
begin to enter mini system
#
Click to expand...

Are these CN devices exact hardware clones? Do they have minor quality cmos chips or something?
Click to expand...
It's a bit of a myth that electronics manufacturing generates a high proportion of rejects. These days, especially with digital electronics, there is very little scrap.
In high-volume lines a single product is built, with the sub-options such as region or number of channels applied at the end of manufacturing.
 
  • Like
Reactions: Maniaxx
Maniaxx said:
How did you get the offset of mtd6 in the first place? Which process/binary/function accesses that area?
Click to expand...

This might be only for DS-2CD2xx2 cameras, I don't really know as this is all I have. But the offset for the language has always been 16 on all the ones I have.
 
Did anyone notice that mtd6 is mirrored at 0x40000 (on 5.3.0)? So we have 3 blocks with language byte.

Did you know... the mtd7/dpt partition is actually a 'dead pixel table'. :)
 
Last edited by a moderator:
You must log in or register to reply here.
Top Bottom