EZViz Camera: CS-CV110-A1, photos, passwords...

I'm guessing 128mb is a bit too big to post here. Any idea where would be a good spot?
It will probably compress down quite well.
Do you have a serial console log / dmesg that shows the partition boundaries?
If so, drop it on to Google Drive etc and I'll look at splitting it for you.
 
@alastairstevenson here ya go!

I did 4 reads; none match (hah!) but I've got enough data to complete the 'right' file. That's not what's in this dump, though, as I hadn't gotten around to doing it yet.

I'm wondering why they were bad- doesn't appear to be OOB errors, but... it's the first time I ever used this software package.
 
I did 4 reads; none match (hah!) but I've got enough data to complete the 'right' file.
I looked at the flash dump - and the partition layout from the dmesg.
Unfortunately the boundaries between the partitions don't match the data in the dump. There appears to be more data in the dump than there should be.

How did you read the data?
I'm speculating that maybe there is raw OOB data included, spread though.

I'm wondering why they were bad- doesn't appear to be OOB errors
dmesg does show that there are several flipped / stuck / unstable bits :
Code:
[    7.194285] ambarella-nand e0001000.nand: BCH correct [1]bit in block[334]
[    7.269292] ambarella-nand e0001000.nand: BCH correct [1]bit in block[394]
[    7.331698] ambarella-nand e0001000.nand: BCH correct [1]bit in block[404]
[    7.371163] ambarella-nand e0001000.nand: BCH correct [1]bit in block[411]
[    7.599527] ambarella-nand e0001000.nand: BCH correct [1]bit in block[463]
[    7.828453] ambarella-nand e0001000.nand: BCH correct [1]bit in block[470]
[    7.830953] ambarella-nand e0001000.nand: BCH correct [1]bit in block[472]
 
I looked at the flash dump - and the partition layout from the dmesg.
Unfortunately the boundaries between the partitions don't match the data in the dump. There appears to be more data in the dump than there should be.

How did you read the data?
I'm speculating that maybe there is raw OOB data included, spread though.


dmesg does show that there are several flipped / stuck / unstable bits :
Code:
[    7.194285] ambarella-nand e0001000.nand: BCH correct [1]bit in block[334]
[    7.269292] ambarella-nand e0001000.nand: BCH correct [1]bit in block[394]
[    7.331698] ambarella-nand e0001000.nand: BCH correct [1]bit in block[404]
[    7.371163] ambarella-nand e0001000.nand: BCH correct [1]bit in block[411]
[    7.599527] ambarella-nand e0001000.nand: BCH correct [1]bit in block[463]
[    7.828453] ambarella-nand e0001000.nand: BCH correct [1]bit in block[470]
[    7.830953] ambarella-nand e0001000.nand: BCH correct [1]bit in block[472]

I read out the data using my official XGecu TL866II dumper (you know how hard it is to buy legit products some time?? Sheesh) and the software. Was one of the first dumps I made with the unit. And it appears you're right- I missed reading that, so I must have grabbed the OOB data as well. Darnit.

I wonder if there's an easy way to separate them or if I've got to go dump it again. No big deal, chip isn't soldered back to the board yet. But yeah that would explain the issues.
 
Hey, was just curious if you guys were able to make any further progress on this? Great work so far!

Also, somewhat related question... when you took apart the camera, was there a desiccant pack inside already? I remember reading some post saying that we should add one in there which makes me wonder if that person teared down the camera and knew the insides already or are just guessing...

Also, what tools did you use to open the camera? I guess just small Philip screwdrivers?
 
Last edited:
Hey, was just curious if you guys were able to make any further progress on this? Great work so far!

Also, somewhat related question... when you took apart the camera, was there a desiccant pack inside already? I remember reading some post saying that we should add one in there which makes me wonder if that person teared down the camera and knew the insides already or are just guessing...

Also, what tools did you use to open the camera? I guess just small Philip screwdrivers?

I'll look when I get home. I honestly have 3 cameras in pieces right now and I can't remember, but I'd be shocked if there wasn't one. All of them have a tiny bag of what appears to be zeolite desiccant (as opposed to silica gel). The camera was regular screws or allen wrench, and there's a tiny rubber seal on the inside between the two pieces. I'll probably lubricate it with some sort of secondary sealant to ensure a good fit and probably purge the inside with gas to get rid of moisture.

I need to redo the chip dump or figure out where the oob data was stored as I had been using a chip reader for the first time. I got several ECC errors and was able to do multiple reads to determine what was good and bad, but I still hadn't ordered replacement chips.

I really do want to get a flex pcb to attach and be able to reprogram at will, but that doesn't exist apparently (or at least I haven't found it).
 
Re-read the chip with the OOB/spare area disabled. Quick look in the hex editor shows the file at least lining up where I'd expect.

Somewhat oddly, I haven't received an error for any of the reads and verifies. So it appears that these reads are good...



New file.
 
  • Like
Reactions: watchful_ip
Interesting.

Does indeed have recovery partition which has a G1 type update minisys. (the md5sum of the davinci programs are even the same)

I wonder if you could use the upf command to TFTP the G1 minisys rearranger posted a while back for a TFTP update that doesn't check RSA sig.

BUT look into this first - comparing other files between the 2 minisys seems to show significant differences and I've not had more than a quick look into them. Not least /bin/upgrade which seems loads different so perhaps my earlier suggestion isn't a good one....

Might be best to use your minisys. and change it to bypass /bin/psh, permit SSH, and disable RSA check in /bin/update
 
Last edited:
Well the chip is of the board. So I can program to my heart's content. What I can't find is a flex of of the board to a socket to program. I know they exist... At least I hope they weren't custom when I used them before. Would make life so much easier.
 
It's been a bit frustrating but here is the EZViz camera that is causing me so much grief.

First, unless you read the FAQ, buried way in the back is the statement "No Web- secure only" and "Only compatible with the ezviz NVR". What that means is there is NO webservices, no SSH, no nothing (well, SSH is running, but disabled).
Camera in question:
ezviz 8-Channel 4K UHD NVR with 2TB HDD & 4 4K Outdoor Night Vision Bullet Cameras

Using the trojan-camera routine previously talked about (Alternative way of recovering HikVision NVR password )- and even though the NVR would NOT support the g0 camera, I was able to find the EZViz's camera password. That meant I could at least now use it with anything that took an ONVIF stream.

So I naturally disassembled everything. Photos are here:- actually I'll put it in separate boxes.

I also own 4 of these cameras, labeled Ezviz CS-CV110 (A1-68R)(X)(v2). I'm interested in your password recovery/reset experience. I read through the thread you linked but it was not clear enough for me attempt password recovery. Camera firmware is v5.5.3 build 180122
  • Is there an equivalent Hikvision camera model on the Hikvision firmware site? Searched for DS-2CDVT but that model number does not exist on their site.
  • If not, where can i get an old (vulnerable) version of the firmware as well as current firmware to restore?
  • The firmware flashing process? Was TFTP used?
Thanks for any direction.
 
Hi all, I just received a CS-C1C-D0-1D2WFR as a gift so I don't have an invoice to request local support. The camera is not working, it seems reset button is not working. Someone at local support informed about a firmware issue and he said the best option is to restore the firmware using the sd card (but unfortunatelly without the invoice, they are not going to help). Do you guys know where can I get the firmware to try to restore the device and get it to work, without having to go to the sopport service.
 
Hi all, I just received a CS-C1C-D0-1D2WFR as a gift so I don't have an invoice to request local support. The camera is not working, it seems reset button is not working. Someone at local support informed about a firmware issue and he said the best option is to restore the firmware using the sd card (but unfortunatelly without the invoice, they are not going to help). Do you guys know where can I get the firmware to try to restore the device and get it to work, without having to go to the sopport service.
I don't have SD cards in any of these cameras... nor did I ever find a firmware file update for them, but I did get a new chip to solder onto the board so I may give it another go (with all my free time)
 
Wondering if any progress was made on this project? I have 4 of these set up that I'd like to run on a new Lorex Fusion NVR, but they are not detected when plugged directly into the new NVR.

Any tips for a noob?
 
Hi all, I'm curious if anything else came of this? I picked up a set of 8 cameras and NVR, model CS-CV110 A1-54R.

My goal was to use these with Frigate through Home Assistant without the ezviz NVR since Frigate replaces the NVR. After reading this thread, I'm realizing this may not be possible. Any input on this?

Thanks