Bricked SV3C IP 1080P Firmware help

[RubberDinero]

Near the very beginning of this thread, you were able to extract files from the firmware, how did you do that? how were you able to extract rootfs.squash?

 

[alastairstevenson]

how were you able to extract rootfs.squash?

As a first stab at looking at a firmware file, the utility binwalk is pretty good at giving some clues as to how a composite file is organised.
It's also possible to use it to extract components that are recognised by the built-in signatures, though this usually needs to be taken with a slight pinch of salt and validated.
For the firmware file in question, I did simply take the auto-extracted squashfs image, though it has the jffs2 block (assumed to be the system configuration, it's a r/w file system) tacked on to the end. But at only 64k it should do no harm.

Here is one way to do the extract :

alastair@PC-I5 ~/cctv/other/SV3C $ ll *.ov
-rw-r--r-- 1 alastair alastair 7667980 May  8  2017 UPG_ipc8700_f8-M20-snx660_f8-20170508_100042.ov
alastair@PC-I5 ~/cctv/other/SV3C $ binwalk *.ov

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
69713         0x11051         Certificate in DER format (x509 v3), header length: 4, sequence length: 3
203312        0x31A30         CRC32 polynomial table, little endian
220710        0x35E26         Unix path: /factory-1/kernel/rootfs-r/rootfs-rw/user-1/u-logo
221522        0x36152         Unix path: /factory/kernel/rootfs-r/rootfs-rw/user/u-logo
243964        0x3B8FC         CRC32 polynomial table, little endian
327952        0x50110         uImage header, header size: 64 bytes, header CRC: 0x21E2, created: 2016-07-01 12:27:21, image size: 1294032 bytes, Data Address: 0x8000, Entry Point: 0x8040, data CRC: 0xBD5B, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-2.6.35.12"
1638668       0x19010C        Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 5946111 bytes, 637 inodes, blocksize: 65536 bytes, created: 2017-05-08 02:00:43
7602444       0x74010C        JFFS2 filesystem, little endian

alastair@PC-I5 ~/cctv/other/SV3C $ tail -c +1638669 *.ov | head -c $((7602444-1638668)) > rootfs.squashfs
alastair@PC-I5 ~/cctv/other/SV3C $ file rootf*
rootfs.squashfs: Squashfs filesystem, little endian, version 4.0, 5946111 bytes, 637 inodes, blocksize: 65536 bytes, created: Mon May  8 02:00:43 2017
alastair@PC-I5 ~/cctv/other/SV3C $

For a bigger set of embedded components in the firmware file, I'd slice it up using 'dd' which is a simple but very versatile tool.

 

[chris666uk1]

hi i am the other person who has same problem been in contact with s3vc and upto now they have sent me this .img .ov file in a rar

i am still trying to get commands from them

 

[alastairstevenson]

been in contact with s3vc and upto now they have sent me this .img .ov file

That's interesting.
The .img file looks to me like a full firmware image - the sections within are a 1:1 match with the flash layout as shown on the serial console logs.
If I was fixing up my own bricked camera, I'd take a slight chance with the bootloader update command with one one of the firmware parameters.
The concern would be though about possibly impacting the bootloader with an incorrect parameter.

But something like
tftp firmware firmware.img
update firmware 0x1000000 0x800000 1

or
tftp firmware-f firmware.img
update firmware 0x1000000 0x800000 1

**edit** Oops - got the commands above wrong, sorry.
Should be
tftp firmware.img 0x1000000
update firmware 0x1000000 0x800000 1

tftp firmware.img 0x1000000
update firmware-f 0x1000000 0x800000 1


But it would be good to get the command-line validated.
@chris666uk1 - would it be possible to senv S3VC the 2 options above and ask which is the one to use with the firmware they supplied?

 

[chris666uk1]

i will ask them about the options they take about a day to get back to me

 

[alastairstevenson]

Before you do - check above - I mistyped the proposed commands, sorry.

 

[RubberDinero]

Before you do - check above - I mistyped the proposed commands, sorry.

well, it appears my journey has ended. i ran the upgrade command and since it wasn't doing anything, i unplugged it (like i had done many times before) and u-boot is gone. now i only have 2 chevrons with no help command

 

[alastairstevenson]

Do you have the transcript of that last session?
Does it echo what you type?

 

[alastairstevenson]

well, it appears my journey has ended.

Certainly hit a big barrier. That's a pity.

But if you want to spend even more time on the topic - as the flash chip is SPI-based, there is a fair chance it could be easily programmed in-situ.
Can you provide a screenshot of the board that would provide enough detail to see the components.
Of interest would be any SOP-8 chips and their markings.

 

[RubberDinero]

Do you have the transcript of that last session?
Does it echo what you type?

For the most part yes, it echos. But multiline echo.

 

[RubberDinero]

Certainly hit a big barrier. That's a pity.

But if you want to spend even more time on the topic - as the flash chip is SPI-based, there is a fair chance it could be easily programmed in-situ.
Can you provide a screenshot of the board that would provide enough detail to see the components.
Of interest would be any SOP-8 chips and their markings.

 

[alastairstevenson]

The 8-pin chip at the top left is the flash memory chip.
There is a pretty good chance ( But I've not checked the supported devices list) that it could be programmed in-situ with something like the CH341A eeprom programmer, with a suitable 8 pin test clip to connect up. CH341A STC FLASH 24 25 EEPROM BIOS Writer USB Programmer SPI USB to TTL 833972787927 | eBay

I've done this with a few cameras, it's worked OK, but you do need a full flash image, though this can be read from another device.

 

[RubberDinero]

The 8-pin chip at the top left is the flash memory chip.
There is a pretty good chance ( But I've not checked the supported devices list) that it could be programmed in-situ with something like the CH341A eeprom programmer, with a suitable 8 pin test clip to connect up. CH341A STC FLASH 24 25 EEPROM BIOS Writer USB Programmer SPI USB to TTL 833972787927 | eBay

I've done this with a few cameras, it's worked OK, but you do need a full flash image, though this can be read from another device.

I'm all for it! I'll have to order it. I'm not a very good solder-er, is there a way to read from it without desoldering?

 

[alastairstevenson]

is there a way to read from it without desoldering?

In-situ has worked for me on several devices.
In other words, with no power on the camera, just hook up the programmer to the chip still on the board, see if it reads OK, then write the image and verify.

 

[RubberDinero]

In-situ has worked for me on several devices.
In other words, with no power on the camera, just hook up the programmer to the chip still on the board, see if it reads OK, then write the image and verify.

I've seen these devices, but i have not seen how they use it without taking the chip off. I've always seem them take it off

 

[RubberDinero]

Here is a picture of the other side because all the info i found on that 8-pin led to a 16kb memory chip. the MX25L6436F chip seems like the main memory.

 

[alastairstevenson]

This is my CH341A with SOIC8 test clip.
The test clip goes directly on to the chip on the camera board.
It's a while since I used this.
Hikvision tend not to use SPI flash memory, makes it less practical to mess with a parallel bus device as opposed to a serial bus.

 

[alastairstevenson]

Here is a picture of the other side because all the info i found on that 8-pin led to a 16kb memory chip. the MX25L6436F chip seems like the main memory.

Interesting - You are quite right, that's an SPI flash chip, 64Mb.
The FT24C16A is also a serial flash chip - but only 16KB. I didn't take the time to read the datasheet properly, and made an assumption.
But the idea still remains.

By the way - best to leave the IR-cut lens mount on, to protect the sensor from dust or accidental contact.

 

[RubberDinero]

Interesting - You are quite right, that's an SPI flash chip, 64Mb.
The FT24C16A is also a serial flash chip - but only 16KB. I didn't take the time to read the datasheet properly, and made an assumption.
But the idea still remains.

By the way - best to leave the IR-cut lens mount on, to protect the sensor from dust or accidental contact.

On the way tuesday. I've definitely put the lens back on. But during reading and flashing I'll have to remove it. hopefully no dust falls in.
I know it's cheaper on ebay, but I've had better experience with Amazon and shipping is usually faster.

If this works, I'll post the complete dump just in case someone else needs this dump.
Maybe it'll help someone else.

 

[RubberDinero]

In all honesty, I could have just purchased another $40 camera instead of all these flashing equipment and thrown the camera in the trash. But I am enjoying this, great learning experience. Also, I'll be able to help friends if they ever have the need to flash a chip.