Acti ENR-130 NVR, cannot find the firmware IC

[Tim88]

I have an NVR that will not boot anymore. I compared voltages on the board coils to ones on a working board and all seems good. Only thing I can come up with is a corrupt firmware. I cannot seem to find the memory chip on this board. I thought it was the one by the small battery but google says it is a timer IC. Its marked ANW SOCA-8. That is the only IC that looks like it could be a memory chip. Does anything else on this board look like it could be it? Any other thoughts welcome.

[fzabkar]

Isn't there a TSOP-48 NAND flash IC just below the SoC?

ANW = ISL1208IU8Z = I2C Real Time Clock/Calendar, Low Power RTC with Battery Backed SRAM

http://markingcodes.com/search/c/ANW

[Tim88]

Yep, it's a SK Hynix H27U2G8F2CTR 2Gb NAND FLASH. Unfortunately, my reader/programmer is only a 40 pin ...

[Tim88]

After a little digging, my programmer does have a TSOP48 adapter so I can, theoretically reprogram the chip. I have a copy of the latest firmware but it is a .upg file and need a .bin file.  I renamed the file to a .bin and opened it with a hex editor and it seems to be a valid file?

[fzabkar]

I tried to download the firmware, but the site wants me to log in. If you can upload it somewhere and send me a PM with the link, I could have a look for you. IME, firmware packages often come with a header that precedes the payload, so this header may be missing from the flash dump.

https://www.acti.com/product/ENR-130?tab=resources

[fzabkar]

The .bin file seems to be some kind of file system image. 7Zip seems to understand how to extract the individual files.

Code: [Select]

0x0 - 0x1FF -- enr_fw/ directory sector

0x200 - 0x3FF -- enr_fw/UPG.xml directory sector
0x400 - 0x5FF -- enr_fw/UPG.xml file data

0x600 - 0x7FF -- enr_fw/uldr_common.bin directory sector
0x800 - 0x107FF -- enr_fw/uldr_common.bin file data

0x10800 - 0x109FF -- enr_fw/rootfs.arm.jffs2.nand.summarized directory sector
0x10A00 - 0x3FE3BFF -- enr_fw/rootfs.arm.jffs2.nand.summarized file data

0x3FE3C00 - 0x3FE3DFF -- enr_fw/enr-config.arm.jffs2.nand.summarized directory sector
0x3FE3E00 - 0x3FE63FF -- enr_fw/enr-config.arm.jffs2.nand.summarized file data

0x3FE6400 - 0x3FE65FF -- enr_fw/u-boot.bin directory sector
0x3FE6600 - 0x403D5FF -- enr_fw/u-boot.bin file data

0x403D600 - 0x403D7FF -- enr_fw/nandboot_enr.scr directory sector
0x403D800 - 0x403E5FF -- enr_fw/nandboot_enr.scr file data

0x403E600 - 0x403E7FF -- enr_fw/vmlinux.ub.lzma directory sector
0x403E800 - 0x423F5FF -- enr_fw/vmlinux.ub.lzma file data

0x423F600 - 0x423F7FF -- enr_fw/upgrade_option.xml directory sector
0x423F800 - 0x423FBFF -- enr_fw/upgrade_option.xml file data

[Tim88]

Ok, interesting... Had no idea & Zip was so handy. Anyway, I opened the original .upg file and this is what is listed.



So, question is, can I reprogram the chip and how to do it??? Am just a novice at this...

[fzabkar]

I think it will only start to make sense after you dump the NAND IC and compare its component sections.

[Tim88]

Roger that, just ordered the adapter for the programmer. Man, if I pull this repair off, it will be sensational...

On a sidebar, when that stuff gets corrupted, is the chip usually still good or is chip failure usually the issue, if anyone knows...?

[fzabkar]

The date code on the PCB appears to be 2046 (week 46 of 2020).  I suppose one or more cells may have leaked their charge, in which case the corresponding bits would have flipped from 0 to 1.

[fzabkar]

If you can short the NAND's Ready/Busy* pin to ground during power-on, the NAND will stay busy and the SoC may revert to some kind of "safe mode" or "factory mode". If so, you should see something on the local monitor on the HDMI port, I would think. You can release the short as soon as you see some signs of life.

Note that shorting R/B* to ground is safe because the signal is an open drain output from the NAND. It will be pulled up to Vccq via a resistor.

[Tim88]

Just wanna make sure we got the correct pin and don't brick this thing, pin 7?

[fzabkar]

Yes, that's it. In fact, this is the same technique that is used to get some SanDisk SSDs to start up in "safe mode".

[amyk]

Given that it's NAND flash and the firmware found above appears to be a filesystem image, I expect there to be an FTL of some sort, and thus you won't be able to just write the image to NAND directly.

[fzabkar]

I'm hoping that the R/B* trick will cause the SoC to power up in factory mode. That is, I'm hoping that the unit will be waiting for a firmware download, just as it would be if the NAND were blank. Hopefully the UPG file is in the correct format ...

[Tim88]

Well, the ground pin 7 trick did not work  . I did check that it is indeed getting 3.3V. Any other tips?

[fzabkar]

The row of 6 pads below the NAND could be a JTAG or UART port, but that would require more tools (and knowledge).

I was hoping that the R/B* trick would at least prove that the SoC has basic sanity, but now this is inconclusive. I don't know how to proceed, other than dumping the flash. If you have a scope, look for some signs of activity on the address and data lines.

[Tim88]

I scoped some of the data and address pins and there is dc voltage of around 3V but no wave of any sort. I ohmed out those 6 pins and only the left 2 pins were connected to the IC, I believe its the 3.3V and ground. Interesting stuff and learning stuff i did not know  . If you have the time to walk me through any further, will do my best to crack this case...

[Tim88]

Check that, those other pins do connect to the ic but through resistance, Had the ohm meter on beep figgered they were 0 ohm connections.

[fzabkar]

I don't have any other ideas. Sorry.

[amyk]

Remove the heatsink to find out what the SoC is.

[Tim88]

Made by Entrop but nothing on the interweb for a EN7531...

[wasedadoc]

https://en.wikipedia.org/wiki/Entropic_Communications

[fzabkar]

FWIW, Xvision's ELITENVR4, ELITENVR16 and ELITENVR32 NVRs use the same SoC.

[Tim88]

Spent most of the past couple days researching this stuff, I guess I am too stubborn to give up, yet. Anyway, am thinking those 6 holes are UART connectors as you speculated before. Watched some videos of hacking a security camera using a UART USB CABLE with the exact same Hynix IC I have. He then desoldered the IC and read the firmware. He mentioned you could then write this to another chip but someone here mentioned FTL is a problem with that? If you are copying the chip exactly, isn’t that like cloning a hard drive?

Hacking the Arlo Q Security Camera: Failed Promises and Data Security
Hacking the Arlo Q Security Camera: Firmware Extraction
Hacking the Arlo Q Security Camera: Bootloader Reverse Engineering