Hacking old DVR's to remove passwords?

[LooseJunkHater]

I have two DVR's dated from 2014, both of which have passwords (no longer set to default). I found them both from an eWaste bin and I'd love to be able to use one of them. Sadly both PCB's lack an actual "reset" switch. I've tried removing the CMOS battery from both units, but with no success to remove the password.

1. Honeywell HRGX161 (PCB DS-80103 Rev2.2) (extracted firmware here)
2. Lorex (FLIR) LHV210800 (with pics included, since this model seems obscure) (extracted firmware here)

I have 3 different ideas on what to do, but I'm unsure which one I should focus the most attention into.

a. Decrypt the flash memory (maybe use Ghidra? I'm not familiar with it at all though) to find the password. Hyperlinked above are the BIN's for both firmwares (as I've already extracted the memory). 
b. Attempt to locate a UART connection on the PCB and see if that can help
c. Download the stock firmware and flash it directly to the flash memory

(Note: Only recently have I started learning about UART, and this is my first experience messing with .bin files and firmware extractions)

______________________________________________________________________

What I've tried: I've extracted the firmware and tried browsing through it for both devices, looking for the asci of "password", "pass", "admin", "Admin", "Administrator", "administrator", but was unsuccessful (the default username is either admin or Admin). Deleting the flash for the Lorex device causes it to not boot, so I assume the entire firmware is loaded within the flash memory. I'm assuming the same to be the case for the Honeywell device, as removing the flash again prevented the device from booting.

Possibly a coincidence, but the Lorex firmware file starts with "GM8210", and I did find this Linux firmware from a Taiwan DVR website (originally in this manual), so I wonder whether this may be the actual OEM software, with Lorex modifying the firmware slightly to fit their needs.

Ideas?

[MrAl]

Hi,

I can't offer much help here, but you must be right about the flash memory holding the password, as that would have to be able to be changed yet stored for a long period of time even if the power is removed.

Unfortunately, which flash memory is it stored in.  When I designed a security device about 10 years ago, I programmed it so that the password was stored in the EEPROM of the microcontroller itself, not a separate flash memory chip.  The firmware was stored in the main flash memory.

[LooseJunkHater]

Unfortunately, which flash memory is it stored in.  When I designed a security device about 10 years ago, I programmed it so that the password was stored in the EEPROM of the microcontroller itself, not a separate flash memory chip.  The firmware was stored in the main flash memory.

Shit, I never thought about the password actually being stored internally in the MCU. I was just thinking that if they're using external memory to store the firmware, that everything is being stored in the flash memory.

I guess it now makes me wonder whether the flash memory could have portions that are encrypted, so that ASCI text cannot be easily discerned, but other parts are unencrypted? Dang, this may be harder to do than I initially was hoping.

[fzabkar]

The HDD password would be stored in the HDD firmware in a reserved system area (SA) on the platters. Which HDD models do you have?

Note that some DVRs have customised HDD firmware, so that's an added complication.

If you are talking about an Admin password, then that is something else.

[ME]

are there any jtag pins/connectors on the pcb?.

[LooseJunkHater]

If you are talking about an Admin password, then that is something else.

Correct, I don't care about the data on the drives; it's the admin password for configuring the actual DVR.

are there any jtag pins/connectors on the pcb?.

Is JTAG the same as UART? I did see a few 4 and 5 pin header spots on the PCB that I was planning on exploring, but haven't done it yet, in case anyone knows of an easier way to remove the admin password or decrypt it.

[fzabkar]

The Lorex dump has 3 SquashFS file systems.

Code: [Select]

  80000 -  db5fff sqsh
1340000 - 14b7fff sqsh
1800000 - 1800fff sqsh
If you carve out these areas with a hex editor, you can view and extract the files with 7Zip. There are several password files, but I don't know if they are what you need.

https://mh-nexus.de/en/hxd/ (free Windows hex editor)

https://7-zip.org/download.html

Edit:

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

Squashfs is a compressed read-only file system for Linux.

I guess this means that a user defined password cannot be stored in those Squashfs regions.

[LooseJunkHater]

The Lorex dump has 3 SquashFS file systems.

Code: [Select]

  80000 -  db5fff sqsh
1340000 - 14b7fff sqsh
1800000 - 1800fff sqsh
If you carve out these areas with a hex editor, you can view and extract the files with 7Zip. There are several password files, but I don't know if they are what you need.

https://mh-nexus.de/en/hxd/ (free Windows hex editor)

https://7-zip.org/download.html

Edit:

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

Squashfs is a compressed read-only file system for Linux.

I guess this means that a user defined password cannot be stored in those Squashfs regions.

HOW DID YOU DO THIS? I assumed you used Ghidra? Are there any YouTube guides that you'd recommend? Additionally, did you happen to do the same for the Honeywell device? I'm thinking the Honeywell device will likely be harder to get the password for.

[fzabkar]

Is JTAG the same as UART?

No, JTAG is a test protocol that accesses specific registers for debugging purposes.

[fzabkar]

HOW DID YOU DO THIS? I assumed you used Ghidra?

I didn't use any tool other than a hex editor. I saw that there were "hsqs" signatures at the beginning of several blocks of data and I assumed these were little-endian "sqsh" signatures for SquashFS. I guessed that the size of the FS was stored somewhere in the header and that indeed turned out to be the case.

Code: [Select]

Offset(h) 00       04       08       0C

01340000  68737173 BE000000 751B1B5D 00000200  hsqs¾...u..]....
01340010  15000000 02001100 C0000200 04000000  ........À.......
01340020  C8170000 00000000 F7771700 00000000  È.......÷w......
                            ^^^^^^^^
                            size of FS = 0x1777f7

01340030  EF771700 00000000 FFFFFFFF FFFFFFFF  ïw......ÿÿÿÿÿÿÿÿ
01340040  60691700 00000000 826E1700 00000000  `i......‚n......
01340050  33761700 00000000 DD771700 00000000  3v......Ýw......
01340060  5D000002 00000002 00000000 00002696  ].............&–

[fzabkar]

Additionally, did you happen to do the same for the Honeywell device? I'm thinking the Honeywell device will likely be harder to get the password for.

The first region seems to span 0 - 0xbffff. Thereafter there are 0x10000-byte regions which either begin with "85190300 0C000000 B1B01EE4" or "85190320 0C000000 B1B01EE4". The first contain data while the second are empty (filled with 0xff). When I try to compress these regions with 7Zip, I find that they are incompressible. This means that they are already compressed (or encrypted?).

Some searching suggests that the file system is JFFS2.

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

I cut off the first 0xC0000 bytes and then saved the resulting dump as JFFS2.img. I tried to open this image file with 7Zip, but encountered a CRC error after the first 41KB.

Attached is the result of the partial extraction by 7Zip.

Code: [Select]

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  64 76 72 43 6D 64 2F 00 00 00 00 00 00 00 00 00  dvrCmd/.........
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000060  00 00 00 00 30 30 30 30 37 37 35 00 30 30 31 30  ....0000775.0010
00000070  30 32 37 00 30 30 31 30 30 33 30 00 30 30 30 30  027.0010030.0000
00000080  30 30 30 30 30 30 30 00 31 32 34 34 31 37 32 36  0000000.12441726
00000090  35 33 37 00 30 31 33 36 33 34 00 20 35 00 00 00  537.013634. 5...
000000A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000100  00 75 73 74 61 72 20 20 00 63 68 61 69 79 61 6E  .ustar  .chaiyan
00000110  67 6C 69 6E 00 00 00 00 00 00 00 00 00 00 00 00  glin............
00000120  00 00 00 00 00 00 00 00 00 63 68 61 69 79 61 6E  .........chaiyan
00000130  67 6C 69 6E 00 00 00 00 00 00 00 00 00 00 00 00  glin............
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000200  64 76 72 43 6D 64 2F 65 6E 61 62 6C 65 48 42 00  dvrCmd/enableHB.
00000210  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000220  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000250  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000260  00 00 00 00 30 30 30 30 37 37 37 00 30 30 30 30  ....0000777.0000
00000270  30 30 30 00 30 30 30 30 30 30 30 00 30 30 30 30  000.0000000.0000
00000280  30 30 30 30 30 30 30 00 31 32 34 34 31 37 32 36  0000000.12441726
00000290  35 33 36 00 30 31 34 31 36 34 00 20 32 64 76 72  536.014164. 2dvr
000002A0  74 6F 6F 6C 73 00 00 00 00 00 00 00 00 00 00 00  tools...........
000002B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000300  00 75 73 74 61 72 20 20 00 72 6F 6F 74 00 00 00  .ustar  .root...
00000310  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000320  00 00 00 00 00 00 00 00 00 72 6F 6F 74 00 00 00  .........root...
00000330  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000340  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000350  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000360  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000370  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000380  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000390  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000400  64 76 72 43 6D 64 2F 72 65 63 6F 72 64 65 72 46  dvrCmd/recorderF
00000410  69 6C 65 4B 65 79 46 72 61 6D 65 00 00 00 00 00  ileKeyFrame.....
00000420  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000430  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000440  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000450  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000460  00 00 00 00 30 30 30 30 37 37 37 00 30 30 30 30  ....0000777.0000
00000470  30 30 30 00 30 30 30 30 30 30 30 00 30 30 30 30  000.0000000.0000
00000480  30 30 30 30 30 30 30 00 31 32 34 34 31 37 32 36  0000000.12441726
00000490  35 33 37 00 30 31 36 35 35 36 00 20 32 64 76 72  537.016556. 2dvr
000004A0  74 6F 6F 6C 73 00 00 00 00 00 00 00 00 00 00 00  tools...........
Each 0x200-byte section appears to correspond to a file or directory.

FWIW, I noticed this:

Code: [Select]

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00003C00  64 76 72 43 6D 64 2F 72 65 73 65 74 50 61 73 73  dvrCmd/resetPass
00003C10  77 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00  wd..............

[xvr]

Attached is the result of the partial extraction by 7Zip.

Looks like TAR archive

[xvr]

Yes, it's tar archive (truncated unfortunately)
It contains one directory drvCmd with utility drvtools (executable ELF file for ARM architecture) and a lot of links to it under different names:

Code: [Select]

decStat
disableHB
disableWatchdog
dspStatus
dvrtools
enableHB
enableWatchdog
errputClose
errputOpen
getDbgCtrl
getGateway
getPort
guiChkCfg
helpm
loadModules
miscCmd
outputClose
outputOpen
partRecDetails
pthreadInfo
rebootDev
recorderChanInfo
recorderFileInfo
recorderFileKeyFrame
recorderMediaInfo
recorderPAllocFile
recorderParam
recorderSegExtraInfo
recorderStatus
resetPasswd
setGateway
setPort
setVoutIdx
t1
t2
drvtools also truncated

[fzabkar]

Thanks for that.

I found a similar JFFS2 file system in the Lorex dump at 0x16c0000 - 0x17fffff. However, 7Zip doesn't recognise it.

Perhaps the embedded computing experts might be able to help?

https://www.eevblog.com/forum/embedded-computing/

[fzabkar]

This section of the Lorex dump appears to define the blocks:

Code: [Select]

Offset(h) 00       04       08       0C       10       14       18       1C

00042E60  626F6F74 00000000 00000000 00000000 00000000 00000600 00000000 00000000  boot............................
00042E80  726F6F74 66730000 00000000 00000000 00000600 0000C800 00000000 00000000  rootfs................È.........
00042EA0  77656200 00000000 00000000 00000000 0000CE00 00001800 00000000 00000000  web...............Î.............
00042EC0  63757374 6F6D0000 00000000 00000000 0000E600 00000200 00000000 00000000  custom............æ.............
00042EE0  6C6F676F 00000000 00000000 00000000 0000E800 00000400 00000000 00000000  logo..............è.............
00042F00  636F6E66 69670000 00000000 00000000 0000EC00 00001400 00000000 00000000  config............ì.............
00042F20  414C4C00 00000000 00000000 00000000 00000000 00000001 00000000 00000000  ALL.............................
00042F40  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ................................
........
00043040  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ................................
00043060  626F6F74 00000000 00000000 00000000 00000000 00000800 00000000 00000000  boot............................
00043080  726F6F74 66730000 00000000 00000000 00000800 00002C01 00000000 00000000  rootfs................,.........
000430A0  77656200 00000000 00000000 00000000 00003401 00002000 00000000 00000000  web...............4... .........
000430C0  63757374 6F6D0000 00000000 00000000 00005401 00001400 00000000 00000000  custom............T.............
000430E0  6C6F676F 00000000 00000000 00000000 00006801 00000400 00000000 00000000  logo..............h.............
00043100  636F6E66 69670000 00000000 00000000 00006C01 00001400 00000000 00000000  config............l.............
00043120  65787465 6E640000 00000000 00000000 00008001 00008000 00000000 00000000  extend............€...€.........
00043140  414C4C00 00000000 00000000 00000000 00000000 00000002 00000000 00000000  ALL.............................
            name                               offset    size
The second group appears to be the active setup. The 32-byte records define the name, offset and size of each block (little-endian).

Code: [Select]

      0 -   7ffff  boot
  80000 - 12bffff  rootfs
1340000 - 153ffff  web
1540000 - 167ffff  custom
1680000 - 16bffff  logo
16c0000 - 17fffff  config
1800000 - 1ffffff  extend
My initial examination of the dump found the following components (there could be errors):

Code: [Select]

      0 -      ff  GM8210  UBOOT
   1000 -    4fff  boot code
   5000 -   4a553  OS
  70000 -   77fff  configuration parameters
  78000 -   7bfff  configuration parameters - same as 7c000 - 7ffff
  7c000 -   7ffff  configuration parameters - same as 78000 - 7bfff
  80000 -  db5fff  squashfs - Linux OS - read-only
1340000 - 14b7fff  squashfs - Lorex UI - read-only
14c0000 - 14fdfff    incompressible
14fe000 - 14fffff  "linux" and "hsqs" in header, then compressed or encrypted data
1500000 - 167ffff    empty 0xFF
1680000 - 16bffff  "Compressed ROMFS" + "BMP logo" text in header
16c0000 - 17fffff  JFFS2
1800000 - 1800fff  squashfs - empty - read-only
1810000 - 184ffff    incompressible
1850000 - 1928fff    incompressible
1929000 - 1ffffff    empty 0xFF

[LooseJunkHater]

I've been trying to follow along, fzabkar and xvr, but I honestly don't know what I should do, and you've both been really deep-diving into those .bin files.

Is there anything I can maybe help with, or maybe have a resource for how I can learn about what you're both talking about? lol

[fzabkar]

The easiest way to locate the password would be to compare the flash before and after a password change. However, this is not an option for us, so we need to determine the structure of the flash and eliminate the implausible regions. JFFS2 is a read/write file system, so that is one possible candidate. Unfortunately, I haven't been able to extract the files from JFFS2. That's why I suggested that the experts at the Embedded forum might be in a better position to help you.

That said, the password may be stored as a cryptographic hash rather than plain text.

I'll park the user manuals here.

Instruction Manual LHV2000 Series:
https://www.lorextechnology.com/downloads/security-dvr/LHV2000/LHV2000_SERIES_MANUAL_EN_R2.pdf

HRGX Performance Series 4/8/16-Channel Embedded DVR User Manual:
https://jmacfiles.s3.amazonaws.com/HRGX161-InstallationManual.pdf

This Linux tool looks useful:

https://github.com/vamanea/mtd-utils/blob/master/jffs2dump.c

Code: [Select]

printf("Usage: %s [OPTION]... INPUTFILE\n"
       "Dump the contents of a binary JFFS2 image.\n\n"
       "     --help                   display this help and exit\n"
       "     --version                display version information and exit\n"
       " -b, --bigendian              image is big endian\n"
       " -l, --littleendian           image is little endian\n"
       " -c, --content                dump image contents\n"
       " -e, --endianconvert=FNAME    convert image endianness, output to file fname\n"
       " -r, --recalccrc              recalc name and data crc on endian conversion\n"
       " -d, --datsize=LEN            size of data chunks, when oob data in binary image (NAND only)\n"
       " -o, --oobsize=LEN            size of oob data chunk in binary image (NAND only)\n"
       " -v, --verbose                verbose output\n",
Another "JFFS2 filesystem extraction tool":

https://github.com/onekey-sec/jefferson/

[fzabkar]

I managed to extract the files from the Lorex JFFS2 image using Jefferson. The "Config\passwd" file is attached.

These appear to be the admin, default and cloud passwords.

Code: [Select]

#id:name:passwd

1:admin:Rst52X4l

2:default:OxhlwSG8

3:cloud:jaIDl8m8

[MrAl]

Unfortunately, which flash memory is it stored in.  When I designed a security device about 10 years ago, I programmed it so that the password was stored in the EEPROM of the microcontroller itself, not a separate flash memory chip.  The firmware was stored in the main flash memory.

Shit, I never thought about the password actually being stored internally in the MCU. I was just thinking that if they're using external memory to store the firmware, that everything is being stored in the flash memory.

I guess it now makes me wonder whether the flash memory could have portions that are encrypted, so that ASCI text cannot be easily discerned, but other parts are unencrypted? Dang, this may be harder to do than I initially was hoping.

Well, please keep in mind that was just a possibility.  The password is a special part of the system so it may be handled differently than the regular data and firmware.  Then again, they may do it the same way.  It depends on who programmed it and how they believed it should work.
Since these systems are so varied I can imagine almost anything is possible.  You might have to find someone that has intimate knowledge of this particular system.

I haven't priced DVR's recently maybe I'll take a look at new ones see what is going on with them these days.
I had a security system DVR but the password could not have been stored on the hard drive it must have been in some memory chip or the microcontroller.  You could change out the HD, still same password.  Are they all like that ... I don't know.

[LooseJunkHater]

I managed to extract the files from the Lorex JFFS2 image using Jefferson. The "Config\passwd" file is attached.

These appear to be the admin, default and cloud passwords.

Code: [Select]

#id:name:passwd

1:admin:Rst52X4l

2:default:OxhlwSG8

3:cloud:jaIDl8m8

So i think I may have messed up, but after erasing the Lorex chip, I tried to reflash the same firmware again, but the device refuses to boot.

Would this be because somehow, the original firmware vs the re-flashed firmware would be programmed differently into memory, or what?

[fzabkar]

So i think I may have messed up, but after erasing the Lorex chip, I tried to reflash the same firmware again, but the device refuses to boot.

Would this be because somehow, the original firmware vs the re-flashed firmware would be programmed differently into memory, or what?

Why did you do this? Did you verify after writing?

What is the part number of the flash chip?

Edit:

I see that the chip is a W25Q256FV. It has several protection features.

[LooseJunkHater]

So i think I may have messed up, but after erasing the Lorex chip, I tried to reflash the same firmware again, but the device refuses to boot.

Would this be because somehow, the original firmware vs the re-flashed firmware would be programmed differently into memory, or what?

Why did you do this? Did you verify after writing?

What is the part number of the flash chip?

I did it right at the start of the thread, stating "Deleting the flash for the Lorex device causes it to not boot, so I assume the entire firmware is loaded within the flash memory.".

I don't recall if I used "verify" after writing to the chip. I'll try to reflow the area near the chip to see if I somehow dislodged a component. If unsuccessful, I'll try to re-write to the chip and use "verify". My programmer is the xgecu T48. The part number of the chip is the Winbond 25Q256FVEG, in the WSON8 package, which is supported by the XGecu T48.

The Honeywell device uses a similar Winbond chip, except it's a SOP16 25Q128FVFG . It boots without issue; I never used the "erase" function on the chip. I had only removed the chip, extracted the flash memory, tried booting the device without the flash (it did not boot), and resoldered the flash memory back on.

I'll try to fix this later today and try the passwords that you've provided.

[LooseJunkHater]

Edit:

I see that the chip is a W25Q256FV. It has several protection features.

If I was able to read and write back to the chip, I assume that those protection features probably aren't being used?

[LooseJunkHater]

Maybe before I try to reflash the memory, I should confirm whether these are the correct settings to use with the XGPro software? I've attached an image; all the settings are the defaults.

Thank you!

[fzabkar]

If I understand correctly, the status registers are indicating that the device is configured for Quad I/O and there are no security settings that protect any part of the chip. Therefore, I can't understand why you are having difficulty reprogramming the chip.

Are you reprogramming the IC in-circuit? If so, is the /Hold pin hard-wired to Vcc? That would prevent Quad I/O from working. In such a case you could use dual I/O.