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

Have you tried using Virtual Host to access the camera directly?

Remind me what you are trying to do -
The camera is working ok with the NVR.
You want to change the camera password, but you can't access the camera to confirm the camera is using the NVR password?
 
alastairstevenson said:
Have you tried using Virtual Host to access the camera directly?

Remind me what you are trying to do -
The camera is working ok with the NVR.
You want to change the camera password, but you can't access the camera to confirm the camera is using the NVR password?
Click to expand...
The camera is not working any more on the nvr after new password
 
Got a question on firmware for the DS-2CD2635FWD-IZS . My camera has firmware listed as V5.6.3 build 190923 from its systems setting page in the web gui. Yet the latest firmware posted by Hikvision is V5.5.61 per 3 MP Ultra-Low Light Network Bullet Camera . So I'm a little confused at what to do. I want to make sure my camera is at the latest stable code...
 
Another mostly successful upgrade here. Thanks to Alastair for making it possible.
I upgraded 5 cameras after they were rendered bricked by hackers. I've kept them around for a couple years and just now to around to fixing them and upgrading them to 5.4.5.

I did make a stupid mistake I think with one of them. Since all my cameras were identical models, I used the fixed mtd6ro_mod from another camera to flash another cam, hoping to skip the Hex editing step. This didn't work out ultimately but it did write the file to the new camera and now there is a strange issue with it flickering back and forth between two IP addresses.
Even if I assign it a fixed IP then it still randomly changes back and forth between two IPs. This happens in the IVMS viewer but it does not seem to affect the camera video while it's happening.

Any idea of what might cause this? I'm thinking there may be some kind of issue with the MAC ID that is now identical between the two cameras.
If that is the case, any suggestions on how to fix it?
 
ChicagoJerry said:
I'm thinking there may be some kind of issue with the MAC ID that is now identical between the two cameras.
Click to expand...
You are correct - MAC address values must be unique on a LAN. A duplicate will break the networking.

To fix this - you will need to re-do the brickfixV2 process on one of the affected cameras, using the process to just change the MAC address and update the checksum.

Here is what I suggest:
First, survey the MAC addresses of the 5 cameras to be sure you don't get another duplicate.
At a Windows command prompt, ping the IP addresses of all the cameras of interest.
Then use the command arp -a to list the MAC addresses of the cameras.
Now go through the motions of the brickfixV2 method to change the MAC address and update the checksum on one of the 2 duplicate cameras.
The MAC address is held in locations 0x35 to 0x3A
Change the last byte (or just any one of those bytes) up or down by 1 and check that the result doesn't match any of your other cameras.
Change the checksum byte at 0x04 by the same amount.
Finish the brickfixV2 process, after which all should be OK.
 
HNeemelaid said:
I'm stuck in step 7. Camera is ds-2cd2532f-iws. Till step 6 tu end is all ok but i can't connect to camera with putty... i cant even ping camera. if i start up camera and use ping -t
then ping responds only 2 times and thats it.
Click to expand...
I have a DS-2CD2532F-IS Camera that I purchased online from China. By mistake, I updated the firmware and now cannot communicate with the camera. The camera's infrared lights turn on so I am assuming it works. I downloaded all the files for the nine step approach to brick-fix the camera but am unable to get pass step 5. I have tried using both the English and Chinese dav files (copying and then renaming to digicap.dav) I set my Ethernet base address to 192.0.0.128 and checked to make sure it was changed using the DOS ipconfig command. I even tried the entire process using the original ip address the camera was set to (192.168.254.6 so 192.168.254.128 on my computer) and that didn't work. Finally I tried doing a factory reset on the camera by holding the reset/WPS button down and then powering up the camera while holding the button for 10 seconds and then trying the tfrp.exe updater with both the English and Chinese dav files. I am out of ideas! Any suggestions? Thanks for your help.
 
alastairstevenson said:
The original 'brick-fix tool' and 'enhanced mtd hack' has proven pretty useful for those with R0 cameras that had been bricked by doing a firmware update.
It's been even more useful to deal with the fallout from the 'Hikvision backdoor' disclosure where so many people are finding their cameras are being messed with from the internet, mischievously or maliciously, and need to update to safer firmware.
However - the rather techy original method to make the changes, and probably my not-very-clear instructions have been a challenge for some people.
* And I only just noticed this - my original .txt attachments were in Linux format, not Windows format, making them hard to read without proper line breaks. And no-one let me know! Dohh! *

So here is 'Brick-fix tool V2' aimed at making the process less complex, a bit automated and easier to use, with the following changes:
  • After Brick-fix toolV2 has been installed using the Hikvision tftp updater, following the power cycle to activate and drop the payload, the camera will boot directly into 'min-system' mode with telnet and tftp access and a 'fixup' script ready and primed for use.
  • No web GUI access or Windows shares are needed to move files in and out of the camera.
  • The fixup script handles all the basics of extracting the original mtdblock6, importing and applying the user-modified mtdblock6 that has had the 'enhanced mtd hack', and initiating a firmware update.
  • The Brick-fix toolV2 automatically writes a valid template into mtdblock1 that stops cameras that originally had firmware 5.2.0 or 5.2.8 from otherwise going into a bricked state when newer firmware is applied.
  • Attached to this post are the resources required to convert your R0 / DS-2CD2x32 cameras into full English upgradeable devices.
  • The brick-fix tool V2 in both EN and CN header language versions (brick_fixv2.zip).
  • A required resource list and step-by-step guide to the fixup script.
  • A description of how to do the 'enhanced mtd hack' with screenshot with a list of devType codes for those cameras that have the masqueraded values.
  • A sample transcript of the fixup script going through all 3 stages - extract mtdblocks, import modded mtdblock6, apply firmware update.

edit 15Dec17 By popular request, a video worked example using a DS-2CD3332-I camera donated by a generous forum member.


edit 28Jan18 devType codes updated - thanks @hikcamuser

Resource List
Step By Step Guide:
Here are the steps to take when using the brick-fixV2 tool to recover a bricked camera, and running the fixup script to change the camera to English / upgradeable. The camera doesn't have to be bricked to run the brick-fix tool if all that's required is a helping hand doing the 'enhanced mtd hack'.
  1. Create a folder on the local drive of your Windows PC to hold the Hikvision tftp updater, the chosen tftp server program (e.g. jouinin.net version), the unzipped 'brick-fixV2' files, and the Hikvision firmware to use for updating. The HxD hex editor should be installed on the PC.
  2. With the PC and the camera each on a wired connection (not WiFi) set the PC IP address to 192.0.0.128, subnet mask to 255.255.255.0 The default gateway does not matter.
  3. Make a copy of brickfixV2EN and name it as digicap.dav If the EN version does not work, e.g. "System update completed" is not displayed in step 5 or you don't get the login prompt when trying to telnet in step 8, try the CN version.
  4. Start the Hikvision tftp updater tftpserve.exe and if a Windows firewall popup appears, click OK to accept what the program needs.
  5. Power on the camera and observe the status messages in the tftp updater. Hopefully you will see 'System update completed' after 2 or 3 minutes.
  6. Close the Hikvision tftp updater, delete the digicap.dev file from step 3 and make a copy of the Hikvision firmware to use for updating and name it digicap.dav.
  7. Power down the camera. At this point the brickfixV2 tool has been installed but not yet activated. Power on the camera to activate the tool, it will then drop the payload, fix up mtdblock1 and reboot into min-system mode for telnet access.
  8. Using PuTTY, start a telnet session to 192.0.0.64 and make sure the telnet radio button is selected. At the login prompt username=root password=12345. You should see a # prompt. The message "can't chdir to home directory '/root/'" isn't an error and can be ignored.
  9. Start the normal tftp server (not the Hikvision tftp updater). If it's the jouinin.net version, the program is tftpd32.exe

    At this point, Stage 1 of 3 is ready to be executed.
    At the telnet command prompt, type:
    /dav/fixup.sh
    and watch the on-screen messages.​

    ​
    ​
    • On success with Stage 1, check the PC folder that the tftp server is running in for the presence of the file 'mtd6ro_orig'. You may have to hit F5 to refresh. Make a copy of mtd6ro_orig rename to mtd6ro_mod. Do the 'enhanced mtd hack' on it, using the instructions in the spoiler below.
  10. These are the steps that are used to do the 'enhanced mtd hack' to mtdblock6 in an R0 IP camera.
    • Extract a copy of mtdblock6 from the camera. The 'Brick-fixV2 tool / fixup script' will conveniently do this for you, or it could be done manually by other methods.
    • Make a copy of the mtdblock6 file and name it mtd6ro_mod
    • Open it with the HxD hex editor.
    • Referring to this image
      View attachment 24161
    • Check / change as needed the language byte at location 0x10 to ensure it is 01
    • Check the devType value in locations 0x64 and 0x65
    [*]
    ​
    If the value shown is FF98 - then the FF value needs to be replaced with the true numeric value. Ideally the true value is determined from the 'devType' line from the prtHardInfo shell command, but as that is going to be unavailable on a bricked camera use this (partial) cross-reference list, paying careful attention to the exact model number.

    There is some slight uncertainty here - it would be good if any forum members could confirm / supplement the content.

    devType - Model
    2698 - DS-2CD2032F-I
    2698 - DS-2CD2032F-IW
    0598 - DS-2CD2032-I
    0698 - DS-2CD2132-I
    1E98 - DS-2CD2132F-IS
    1E98 - DS-2CD2132F-IWS
    0798 - DS-2CD2232-I5
    0898 - DS-2CD2332-I
    1298 - DS-2CD2432F-IW
    1498 - DS-2CD2532F-IS
    1098 - DS-2CD2632F-IS
    0E98 - DS-2CD2732F-IS
    0698 - DS-2CD3132-I
    1C23 - DS-2DE2103-DE3/W
    2198 - DS-2CD2T32-I8​


    ​
    ​

    ​
    ​
    • Replace the FF in location 0x64 with the first 2 digits of the numeric devType value.
    • If location 0x64 already has a 2-digit numeric value, no change is needed.
    • Starting at location 0x09, drag to select and highlight a length of F4 bytes, as shown he the HxD bottom status bar.
    [*]
    Using the Analysis / Checksum menu, double-click Checksum-16 to calculate the new checksum. This will show as a 2 byte value in the Checksums tab at the bottom of the screen. These need to be applied using the correct 'endian-ness', which is the reverse of how the values are presented on the screen.

    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

    Use your own just-calculated values - not those from the screenshot.

    Click File | Save and the mtd6ro_mod file has had the 'enhanced mtd hack' and is ready to be applied to the camera.

    This is done during Stage 2 of the fixup script in the brick-fixV2 tool.​


    Good luck!​

    ​
    ​
    ​
    ​


    At this point, Stage 2 of 3 is ready to be executed.
    At the telnet command prompt, type:
    /dav/fixup.sh
    and watch the on-screen messages.

    This will bring in the modified mtd6ro_mod and apply it to the camera to convert it to English / upgradeable.

    At this point, Stage 3 of 3 is ready to be executed.
    At the telnet command prompt, type:
    /dav/fixup.sh
    and watch the on-screen messages.

    This will attempt a firmware update using the Hikvision firmware file digicap.dav that you placed in the same folder as the tftp server.​
  11. Assuming a successful result, shut down the tftp server and power cycle the camera. Interestingly, on testing I did find that a straight jump to the 5.4.5 firmware version worked OK. YMMV. But worth trying.
  12. Start SADP and check for the camera presence running the firmware version used for the update.
  13. If you used the 5.4.5 firmware, the camera will require 'activation' with your choice of strong password.
    If already active, if earlier firmware was used for the upgrade, log in with the admin password=12345
    Change the IP address to what you want the camera to use.
How To Upgrade
  1. Rename the firmware to digicap.dav
  2. Put the firmware under the same folder of this TFTP
  3. Set the IP of computer as 192.0.0.128
  4. Camera's IP can be anyone.
  5. Run the tftpserv.exe
  6. Power off and power on the DVR/DVS/IPC. The device will search the new firmware and upgrade it automatically.
  7. Please wait until TFTP shows "Device [192.0.0.64] system update completed!" It takes about 5 minutes.
  8. Close the TFTP before the camera reboots.
  9. DVR/DVS/IPC will restart automatically after upgrading.
Click to expand...

I have a DS-2CD2532F-IS Camera that I purchased online from China. By mistake, I updated the firmware and now cannot communicate with the camera. The camera's infrared lights turn on so I am assuming it works. I downloaded all the files for the nine step approach to brick-fix the camera but am unable to get pass step 5. I have tried using both the English and Chinese dav files (copying and then renaming to digicap.dav) I set my Ethernet base address to 192.0.0.128 and checked to make sure it was changed using the DOS ipconfig command. I even tried the entire process using the original ip address the camera was set to (192.168.254.6 so 192.168.254.128 on my computer) and that didn't work. Finally I tried doing a factory reset on the camera by holding the reset/WPS button down and then powering up the camera while holding the button for 10 seconds and then trying the tfrp.exe updater with both the English and Chinese dav files. I am out of ideas! Any suggestions? Thanks for your help.
 
smcconnery said:
I downloaded all the files for the nine step approach to brick-fix the camera but am unable to get pass step 5
Click to expand...
What does the tftp updater window show when you start it?
What does the tftp updater window show if anything when you power on the camera?

The tftp updater works best when -
Using a 12v power supply as opposed to PoE
Both the PC and the camera are wired to a switch or router as opposed to being directly connected, or the PC or camera on WiFi.
The Windows firewall properly allows inbound connections to tftpserve.exe The popup when first started should automatically create the firewall rule, but if in doubt, temporarily disable the Windows firewall.
The inbound access can also be blocked if there is an active AV that provides network access protection.
 
  • Like
Reactions: VorlonFrog
alastairstevenson said:
What does the tftp updater window show when you start it?
What does the tftp updater window show if anything when you power on the camera?

The tftp updater works best when -
Using a 12v power supply as opposed to PoE
Both the PC and the camera are wired to a switch or router as opposed to being directly connected, or the PC or camera on WiFi.
The Windows firewall properly allows inbound connections to tftpserve.exe The popup when first started should automatically create the firewall rule, but if in doubt, temporarily disable the Windows firewall.
The inbound access can also be blocked if there is an active AV that provides network access protection.
Click to expand...
The tftp shows TFTP server [192.0.0.128]initialized
Nothing more is shown when the camera is powered on however every 20 seconds or so I the Link and 10/100 Mps lights flash on the switch for the port which the camera in connected to.
I don't have a 12 volt power source for the camera however I am using a stand alone POE injector to power the camera.
Both he camera and PC are wired (Cat 6 ) to an 8 port switch
There is no firewall popup when I start the tftpserve.exe
I am not connected to any network when I preform the test other than the 8 port switch (WIFI is turned off) I will however, disable Norton AV and give that a try.
I will let you know how that turns out. Thanks for your help.
 
alastairstevenson said:
The tftp updater works best when -
Using a 12v power supply as opposed to PoE
Both the PC and the camera are wired to a switch or router as opposed to being directly connected, or the PC or camera on WiFi.
The Windows firewall properly allows inbound connections to tftpserve.exe The popup when first started should automatically create the firewall rule, but if in doubt, temporarily disable the Windows firewall.
The inbound access can also be blocked if there is an active AV that provides network access protection.
Click to expand...
I can strongly confirm the switch/router item above.
It makes things a LOT more reliable and easy.
(This comes from many years of de-bricking and re-flashing consumer routers.)
 
  • Like
Reactions: alastairstevenson
smcconnery said:
I don't have a 12 volt power source for the camera however I am using a stand alone POE injector to power the camera.
Click to expand...
The extra PoE link detect timing can embarrass the rather tight timeout of the probe for the tftp updater that the camera makes on startup.

smcconnery said:
There is no firewall popup when I start the tftpserve.exe
Click to expand...
This would only happen the first time tftpserve.exe is run - which if 'OK' is clicked will create an inbound firewall rule.
If in doubt - disable the Windows firewall.
 
alastairstevenson said:
The extra PoE link detect timing can embarrass the rather tight timeout of the probe for the tftp updater that the camera makes on startup.


This would only happen the first time tftpserve.exe is run - which if 'OK' is clicked will create an inbound firewall rule.
If in doubt - disable the Windows firewall.
Click to expand...
I will see about getting a 12 volt power supply and disable the Window as well as Norton firewall and let you know the results. Thanks again.
 
  • Like
Reactions: alastairstevenson
You must log in or register to reply here.
Top Bottom