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?
Bricked SV3C IP 1080P Firmware help
- Thread starter RubberDinero
- Start date
alastairstevenson
Staff member
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 :
Code:
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.
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
i am still trying to get commands from them
alastairstevenson
Staff member
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?
Last edited:
alastairstevenson
Staff member
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
Staff member
alastairstevenson
Staff member
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
Staff member
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.
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.
As an eBay Associate IPCamTalk earns from qualifying purchases.
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?
As an eBay Associate IPCamTalk earns from qualifying purchases.
alastairstevenson
Staff member
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
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
Staff member
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.
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
Staff member
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.
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.