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

I upgraded a DS-2CD2032-I cam using your procedure and it worked out well.
I then tried a 2nd cam (same model and bought at the same time). I was able to install digicap.dav using the Hikvision TFTP but when I booted up the cam I am unable to connect via putty (I am using telnet).
I figured I would re-install the brickfixv2 firmare via Hikvision tftp but no joy. The cam never connects. I made sure my firewall was off, rebooted windows pc, tried multiple times with EN and CN version of firmware.

Any ideas appreciated.

Here is what I see in the log for the 2nd cam:

[2022-03-02 16:16:55] TFTP server[127.0.0.1] initialized [2022-03-02 16:17:00] Device[192.0.0.64] test tftpserver [2022-03-02 16:17:11] Connect client[192.0.0.64] success [2022-03-02 16:17:11] Start file[C:\Temp\3-2-2022 firmware upgrade\TFTP\digicap.dav] transmitting [2022-03-02 16:18:22] Completed file[C:\Temp\3-2-2022 firmware upgrade\TFTP\digicap.dav] transmit [2022-03-02 16:18:39] Device[192.0.0.64] system update completed! [2022-03-02 16:20:55] TFTP server[127.0.0.1] initialized [2022-03-02 16:21:01] Device[192.0.0.64] test tftpserver [2022-03-02 16:22:30] Device[192.0.0.64] test tftpserver [2022-03-02 16:25:15] TFTP server[127.0.0.1] initialized [2022-03-02 16:25:22] Device[192.0.0.64] test tftpserver [2022-03-02 16:33:36] TFTP server[127.0.0.1] initialized [2022-03-02 16:33:41] Device[192.0.0.64] test tftpserver [2022-03-02 16:35:12] Device[192.0.0.64] test tftpserver [2022-03-02 16:39:13] TFTP server[127.0.0.1] initialized [2022-03-02 16:39:18] Device[192.0.0.64] test tftpserver [2022-03-02 16:41:33] Device[192.0.0.64] test tftpserver [2022-03-02 16:44:03] TFTP server[127.0.0.1] initialized [2022-03-02 16:44:08] Device[192.0.0.64] test tftpserver [2022-03-02 17:09:23] TFTP server[192.0.0.128] initialized [2022-03-02 17:09:31] Device[192.0.0.64] test tftpserver [2022-03-02 17:11:09] Device[192.0.0.64] test tftpserver [2022-03-02 17:11:27] Device[192.0.0.64] test tftpserver [2022-03-02 17:12:20] Device[192.0.0.64] test tftpserver
 
It looks like the camera is in a bootloop.
If you wanted to spend the time to explore this further, maybe fix it, maybe not, you'd need to connect up to the serial console, which should provide more detail.
To do this 2 items are needed :
A 4-pin 1.5mm ZH JST wired connector, usually available in 10-packs.
A serial TTL to USB convertor such as a PL2303TA-based device.
Both widely available at low cost.
 
What info should I extract when I set up the serial console?
To begin with - just the transcript of the boot process, without any intervention.
PuTTY has a useful 'copy rollback to clipboard' facility that captures the text scrollback, easier and better than a screen capture.

Hopefully the transcript will provide some clues as to what is stopping normal operation.
But it's likely that there may be an underlying hardware issue.
 
Here is the transscript from Tera Term VT (putty did not seem to want to connect for me)


Code:
U-Boot 1.3.4-84026 (Jul 16 2014 - 16:51:43)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
check bad block failed >> read spare data error.
check bad block failed >> read spare data error.
 
@alastairstevenson
I am able to hot Ctrl-u and it stops autoboot and I get a HKVS prompt

Code:
U-Boot 1.3.4-84026 (Jul 16 2014 - 16:51:43)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 2
HKVS #
Unknown command:
HKVS #
HKVS #
 
I did a diag command

Code:
HKVS # diag
diag [command]
Run diagnostic code to test various system hardware.
The available commands are:
        diag adc  - Test ADC.
        diag gpio - Test GPIO.
        diag ir   - Test IR.
        diag nand erase [end_block] - Test NAND erase.
        diag nand read - Test NAND read.
        diag nand prog - Test NAND prog.
        diag nand rclm [init|late|other|all]- Reclaim nand bad blocks.
        diag nand verify [boot|storage|all]- Test NAND read write verify.
        diag nand part [partition|all] [times] -
                Where partition is bst|bld|pri|bak|rmd|rom|dsp
                Check CRC32 for every partition.
        diag nor verify - Test NOR read write verify.
        Loop command:
        diag nand erase loop - Test NAND erase in forever loop.
        diag nand read loop - Test NAND read in forever loop.
        diag nand prog loop - Test NAND prog in forever loop.
        diag nand prog verify - Test NAND verify in forever loop.

                [slot]: sd/sdio/sd2
                [type]: sd/sdhc/mmc/MoviNAND
        diag sd read slot type - Test read.
        diag sd rst slot type - Test read speed.
        diag sd write slot type - Test write
        diag sd wst slot type - Test write speed
        diag sd verify slot type - Test read write verify.
HKVS # diag nand verify all
running nand stress test ...
press any key to terminate!
.....check bad block failed >> read spare data error.
initial bad block. <block 85>
Try next block...
.check bad block failed >> read spare data error.
initial bad block. <block 87>
Try next block...
check bad block failed >> read spare data error.
initial bad block. <block 768>
Try next block...
................ 1023/1024 (99%)
total bad blocks: 3

done!
HKVS #
 
I did an "update" command and it game me
Code:
check bad block failed >> read spare data error.
check bad block failed >> read spare data error.

After the error messages from the update command it locked up.

It might be fully dead now. When i remove power and reapply power I get nothing. No message on the TFTP server windowd and nothing on the USB/TTL serial console either. The LEDs on the board light up (one solid green and one flashing green on the CPU board and one red on the power board). The eithernet LEDs on my PC's ethernet connection are also lit up showing a connection.
 
check bad block failed >> read spare data error. check bad block failed >> read spare data error.
It looks like the flash memory has exhausted the spare pool of blocks that can be used to replace failed blocks.
Depending on where the unfixed failed block exists, that can be a fatal error.

HKVS # diag nand verify all running nand stress test ... press any key to terminate! .....check bad block failed >> read spare data error. initial bad block. <block 85> Try next block... .check bad block failed >> read spare data error. initial bad block. <block 87> Try next block... check bad block failed >> read spare data error. initial bad block. <block 768> Try next block... ................ 1023/1024 (99%) total bad blocks: 3 done! HKVS #
I'm pretty sure, though not 100% as I've never tried this - that the nand read/write test will eliminate all stored data needed for normal operation, including the bootloader. Maybe someone can confirm.
While the bootloader is still running - it would have needed to be re-written to flash to maintain some level of access.
This will be why there are no longer any serial console entries.

To revive the camera, a flash programmer with a valid flash dump for the model of camera would be needed.
 
I installed it in 2014 so it got about 8 years of use. It was still working but I figured I would update the firmware to the newer version without the old firmware's vulnerabilities. The first cam upgraded without incident. The 2nd (this one) went bad. I still have a 3rd with the original V5.2.0 build 140721 firmware that I am considering upgrading even though it might also go bad...
 
I am currently attempting to unbrick a Hikvision NVR DS-7608NI using Python and TFTP script from Scottlamb.
I am getting the below image error relating to Unexpected Bytes.
Can anyone assist?
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    83.1 KB · Views: 19
I am getting the below image error relating to Unexpected Bytes.
That's the NVR probe for 'Arecontvision' devices that it puts out on normal bootup.
It uses a similar handshake to the Hikvision tftp updater - so the tftp updater comments on it.
It's not an error, but it does indicate that the tftp updater handshake has not taken place and the NVR has booted normally.

To figure out why the tftp handshake didn't work, you need to supply more detail of your setup.
What's the model of NVR?
What's the IP address of the PC?
Are both devices connected to a switch? (direct connection can be troublesome)
And you should probably include these command-line arguments :
--filename FILENAME file to serve; used both to read from the local disk
and for the filename to expect from client
--server-ip SERVER_IP
IP address to serve from.
 
Видеорегистратор — DS-7608NI-Pi2.
IP-адрес видеорегистратора: 192.0.0.64.
Сетевой адаптер ПК — 192.0.0.128.
Устройства подключаются через сетевой коммутатор.
[/ЦИТИРОВАТЬ]
 
Hey there guys, can someone help me pls.
My cam is ds-2cd3332-i (chinese) I've taken it from the shelf and updated it to the latest software (5.4.5-170123) from the official Hikvision site so you can guess that now I get "firmware language mismatch: /home/webLib". Google searches led me here and I've tried the this solution. I am stuck at 1st step of using tftp server and unbrick.dav.
My PC has 192.0.0.128 address and I tried both using my current local network (with unmanaged switch it's 192.168.1.... type of network) and when that didn't work I've created a network just for the IPC and my pc with old apple aiport extreme (using lan) I have laying around.
I can connect to IPC using SSH (no telnet though) and SADP also finds IPC. So networking is ok but no matter what I do my tftp server just shows that 1st line of "server 192.0.0.128 initialized" and that's it.

I've tried both CN and EN version (renaming them ofc).
I even gave IPC 192.0.0.64 as last effort and it didn't help also.
How can find why IPC doesn't look for my tftp server on Desktop? Is there a way I can get a log or smth after powercycling my IPC?