R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

Hello, any instruction to change CN to EN for DS-2CD3366WDA4-L, V5.7.5 build 241103.
Many thanks
 
Last edited:
I just followed these steps to update a bricked DS-2CD2432F-IW to V5.4.5build 170401!

So is there a way I can update my other cameras that are still running V5.2.5build 141201 and not have them be bricked in the process so that I can avoid the brickfixv2 brick recovery process?
 
Bionic said:
I just followed these steps to update a bricked DS-2CD2432F-IW to V5.4.5build 170401!
Click to expand...
Well done!

Bionic said:
So is there a way I can update my other cameras that are still running V5.2.5build 141201 and not have them be bricked in the process so that I can avoid the brickfixv2 brick recovery process?
Click to expand...
If they are not China region cameras with hacked firmware - then the normal upgrades should work OK.
A clue may be in the serial numbers - CCCH usually indicates Chinese.
 
alastairstevenson said:
If they are not China region cameras with hacked firmware - then the normal upgrades should work OK.
A clue may be in the serial numbers - CCCH usually indicates Chinese.
Click to expand...
So I just checked, and they have CCCH in the serial number. So I need to do this entire process for all of them? Or since are there some short cuts that I can take since they are all the same model number?
Perhaps I can use the same mtd6ro_mod file for all of them?

Since the others are not bricked maybe the steps to do this are not exactly the same as a bricked camera? maybe there is a faster way to update all of them?

@EMPIRETECANDY Maybe I should just replace them. What would be the recommended replacement for the DS-2CD2432F-IW cameras? They provide enough resolution and features for my needs. The only issue I have with them is that some of them the IR no longer works... Other than that they work fine.
 
Last edited:
Bionic said:
So I just checked, and they have CCCH in the serial number. So I need to do this entire process for all of them? Or since are there some short cuts that I can take since they are all the same model number?
Perhaps I can use the same mtd6ro_mod file for all of them?

Since they others are not bricked maybe the steps to do this are not exactly the same? maybe a faster way to update all of them?
Click to expand...
Read this blog post, download the service firmware, and simply update your camera through the web interface. Your camera will be permanently converted to the European model.
 
  • Like
Reactions: alastairstevenson
Hello, I have Ds-7616-e2/8p with V3.4.106 build 191009. I have ds-2cd2032i camera. I have downloaded the 5.30 from EU site and probable brick it. I have updated with brickfixV2CN . the problem is i can't access with telnet with 192.0.0.64. Did they disable with telnet with latest firmware?IMG_9788.jpgIMG_9784.jpeg
 
softfree said:
the problem is i can't access with telnet with 192.0.0.64. Did they disable with telnet with latest firmware?
Click to expand...
Is the camera still connected to the NVR PoE port? And the PC on the LAN?
If so, the camera isn't directly accessible.

If the camera is still connected to the NVR, either connect the PC to an unused NVR PoE port, or connect the camera to the same LAN as the PC and power the camera with 12v.

And give the PC an IP address in the same range as the camera - which looks like 192.168.254.2
 
Is the camera still connected to the NVR PoE port? yes And the PC on the LAN? pc on NVR Poe port Yes
If so, the camera isn't directly accessible. not, only after flashed brickcn/en you can see the mini-system on sadp tool.

If the camera is still connected to the NVR, either connect the PC to an unused NVR PoE port (this is the method I'm being using), or connect the camera to the same LAN as the PC and power the camera with 12v.

And give the PC an IP address in the same range as the camera - which looks like 192.168.254.2

TFTP all came out complete and successful.
 
alastairstevenson said:
And give the PC an IP address in the same range as the camera - which looks like 192.168.254.2
Click to expand...
Min-System mode should allow telnet access, so the fixup script can be activated.
But it would normally use the 192.0.0.64 IP address, not the 192.168.254.2 address that your SADP list is showing.
I'm not sure why that is.

If you change the PC IP address to, say, 192.168.254.100 does a telnet access connect?
 
I finally got into telnet connection, I have to switch the pc into different poe port. Now the hex checksum the number is different from the video. Once I get home I will unload the screenshot here thx can you confirm the hex number is right that i replace it? thanks
The left hand byte (0x0C in the screenshot) is the most significant byte and should be used in location 0x05

The right hand byte (0x5F in the screenshot) is the least significant byte and should be used in location 0x04 DO i need to replace with 0C? also checksum needs to replace too?
 
Last edited:
  • Like
Reactions: alastairstevenson
Amazing guide. Worked perfectly for DS-2CD2332-I cameras. I also have a DS-2CD2x35 with a chinese firmware, I believe this is a G1 camera, not R0. Can this also be modded and upgraded? I tried plugging it in and sending the BrickFix firmware file using the hikvision TFTP but it doesn't send. Tried both EN and CH versions. Can I skip this part? Grab the 6ro file, mod it, then udpate using the latest publish EU firmware? Thanks
 
lewcrowley said:
Worked perfectly for DS-2CD2332-I cameras.
Click to expand...
Good to hear - thanks for sharing.

lewcrowley said:
I also have a DS-2CD2x35 with a chinese firmware, I believe this is a G1 camera, not R0. Can this also be modded and upgraded?
Click to expand...
Not using the R0-specific method that you have used, the G1 cameras have a different architecture.
I've not had my hands on a Chinese G1-series camera, so I've not explored how the region is defined, sorry.
 
DS-2CD2032F-I R0 CCCH – BrickFix works, normal firmware stuck in TTL=255 bootloop


I am trying to recover a Hikvision DS-2CD2032F-I, 4 mm, CCCH/China, originally running V5.2.5 build 141201.


Recovery works:


  • BrickFixV2 CN via Hikvision TFTP
  • Min-System V4.0.8 starts at 192.0.0.64
  • Telnet/PuTTY works
  • PC is set to 192.0.0.128/24

BrickFix Stage 1–3 completed successfully, including the mtd6 modification. Stage 2 and Stage 3 finished without errors.


set_sysflag -m 0 returns 0.


I also flashed normal R0 firmware from the Min-System using /bin/update:



<span>Download File [OK]<br>Writing Flash<br>Write Flash [OK]<br>***** UPDATE COMPLETE *****</span>


However, after reboot the camera always ends up in the same early boot loop:




<span>2–3 replies with TTL=255<br>then offline<br>short pause<br>TTL=255 again</span>


There is no TTL=64, no SADP detection and no normal Linux boot.


Already checked:


  • mtd9/mtd10 kernel partitions are identical
  • mtd11/mtd12 ramdisk partitions are identical
  • Dumps taken immediately after the update match the kernel/rootfs from the firmware
  • mtd1/PTB is unchanged
  • mtd4/mtd5/mtd7 are unchanged
  • recover_mtd reports:



<span>No need to recover kernel pri partition.<br>No need to recover ramdisk pri partition.</span>


  • /proc/cmdline after set_sysflag -m 0 contains no MS_ACTION=auto_update
  • NAND has only one known bad block in the cfg_sec area, not in kernel/ramdisk/app
  • UBI partitions mount successfully

I tested normal R0 5.3.0 as well as an older normal DAV file with 18,858,119 bytes. Both result in the same early TTL=255 boot loop.


BrickFixV2 CN itself is 18,558,206 bytes and reliably boots into the Min-System.


What are we missing? Is there another boot/rollback flag or partition selector on R0 cameras that we should check? Does anyone have an original R0 V5.2.5 build 141201 for a CCCH camera, or has anyone seen this exact TTL=255 boot-loop behaviour before?


Would UART/serial console now be the best next step to find out why the normal kernel/rootfs is not starting?
 
Last edited:
netpirat said:
Would UART/serial console now be the best next step to find out why the normal kernel/rootfs is not starting?
Click to expand...
What you've described in detail looks good - so there is not an obvious cause for the bootloop, unless the bad block in the backup cfg_sec is implicated..
The serial console hopefully would provide a clue.

netpirat said:
Does anyone have an original R0 V5.2.5 build 141201 for a CCCH camera
Click to expand...
I don't think an original - but what may be a 'hacked to English' version from @whoslooking - attached.
 

Attachments

You must log in or register to reply here.
Top Bottom