Reflash NAS540 via SD card slot? (Recover from probable Hack)

Clay_JF2019

Suspected firmware hack. As detailed below I have no network access beyond opening web login page and occasional pings. But something is still running since ping and initial web page sometimes loads. 

So is there any unofficial way to reflash last firmware using SD card and power on/ reset buttons? Or any serial port/JTAG methods to access the system without network? Just stabbing around here for suggestions of where to start device recovery. Not big Linux system tech guru. But get me a few leads and I can research. 

Web Login won't complete. No SSH or Telnet (connection refused). Ping and Web login start screen are up and down availability (sometimes connection refused on web). Pulled disks after deciding it was not a RAID rebuilt. Disks were often on in odd pairings as often as all on. Reset does not appear to work - even if I hear short 1 beep or long double beep...and beeps do not always occur. Tried reset before and after pulling disks.Power and button booted several times before and after pulling disks. 

Kind of like to recover disk data. But realized it might be trashed or encrypted. But if I can get hardware back into operation I do have originals of most important stuff on other offline disks. Heh I might be asking if about security hardening if I get to things working again. Suspect enabling WebDAV without some work was not wise.

#NAS_Jan_2019

Clay_JF2019

Finally got control of my NAS. 

The answer? I removed my data drives and replaced them with an uninitialized drive. If ever used before, the drive must be zeroed out -- by, for instance, "diskpart" & "clean all" at  Windows command shell. With an uninitialized drive present (and only uninitialized drives),  I could finally re-flash firmware.  Most importantly with only an UNinitialized disk onboard flashing also wiped out the configuration stored in firmware. NAS returned to factory reset condition. Not a full and ideal solution for reasons as detailed below.

Turns out that a big part of the problem was that the reset button was disabled by firmware configuration or firmware changes. Additionally new firmware would not flash either when no disk was detected or when my old data set drives were inserted.   

While hooked to just the motherboard by serial cable all I saw was an endless reboot circle - even with SD card for flash inserted. The boot process would proceed apparently normally for around a minute (did not time it) but then at certain point it would get failures on missing file system mount points and then very quickly start shutdown and restart. No real chance to get control of command line in controlled manner. 

Apparently initialized drives were hooked into the boot process even under SD firmware flash circumstances either (1) allowing a hack to diverting flash attempts or (2) the legitimate flash process makes heavy assumptions about initialized drives being available for backup of configuration and old software.  In fact from the wipe out of configuration after a flash, I bet that configuration is normally restored automatically from disk AFTER legitimate flashing.

Also learned that most the normal boot configuration data (which apps etc are to run etc) and other easily hackable aspects are stored on the first data volume in normally invisible directories starting with dot (e.g. .system .admin   etc).  Yes as expected there is a CRONTAB file and its on the data volume.  The system volume (3 Linux RAID5 volumes: md0 is swap, md1 is system, md2 is your data volume) contains a loop mount root file system but its content is apparently fixed for each firmware update.  That root file system is apparently complete with all the app packages in place. Its the system mount points actually stored on the data volume that make the NAS system "live" and configurable.  At least as near as I can tell without learning how to read on the code in its entire-ity. 

However, in my case simply deleting the system volume contents and the system mount point directories from the data volume did not solve the issue. The system was still way too slow to access and I could not reflash or wipe old basic network-password configuration. Occasionally the login did work and web interface start to appear before web browser timed out (many minutes later). I am fairly sure the compressed root file on system volume and mount points were not recreated during failed reflash attempts.

Obviously anyone else with a similar issue MIGHT want to skip messing with the drive set completely. Once you have control of your NAS you could try reinstalling your drive set "as is" then select the last option in the "first volume creation" wizard instead of ever completing it with uninitialized drives. The last option seems to say mount existing drives.  There is always a chance that all problems were actually only in firmware. Also some parts of system software on disk might get "updated" (i.e. effectively repaired) by what the NAS might see as a normal system upgrade. At worst you end up reflashing with uninitialized drive again...unless you see something that says its going to wipe existing drives (abort if that seems possible).

CONCLUSION:
I was however able to easily mount the old RAID5 data volumes on a Linux file server and the data is fine. I am instead placing a cheap set of uninitialized (4) 2TB drives in the NAS540 to start over. I will periodically backup data to older set of 4x3TB drives when that Linux server is online.

I have decided to leave the older RAID5 volume on a Linux server for a multitude of reasons. But basically because the only way I am sure to get the drives online with the NAS540 operating correctly seems to be to wipe them out first. That initialized RAID5 volume set probably still won't mount and let the NAS boot correctly even after the reflash. Its looking like the stuff I deleted will not be recreated automatically Z (e.g. system volume file with full root file sytsem and volume point directories on data volume).  I am not sure the the worm does not lurk in the boot cylinder. I see nothing to suggest the NAS540 does ANY self-healing/restoration of bad system info or file systems and volumes between flashes - other than the low level RAID5 mechanism. Finally I note that the increase in network access speed to my data was quite embarrassing to the NAS540 - only ameliorated by the large increase in power usage and physical enclosure size. The NAS540 definitely still has its place as constantly online data storage with cloud services - but apparently its wise to have some backup.

SUGGESTION: 
Recovery could be improved if ZyXEL ensured system could boot when only user data was intact on disks.  Then provided a way to trigger a complete system restore that left user data alone but would rewriting all basic system files and disk sectors on on disk volumes.  This would allow system healing regardless of cause without data loss or needing a complete user data restore from backup. Small change to unintialized-first volume creation wizard I would think.

If this is already possible...its not explicitly clear that is what would happen. There is a wizard entry that at least implies a perfectly intact disk set could be remounted.

Mijzelf

I have a recovery script for the 326 here. AFAIK it should also work for the 540, if you provide the right firmware file, as written in the readme, and rename nas3xx_check_file to nas5xx_check_file. But no guarantees.

Clay_JF2019

Sounds good. I have downloaded the firmware file already.
But where is script and readme?  Was it supposed to be linked or pasted in post?
I'll try searching forum for nas3xx_check_file 

Clay_JF2019

Hmmm...is it inside http://zyxel.diskstation.eu/Users/Mijzelf/zypkg-repo/NAS326/ ?   I can probably figure out how to unpack .tgz file fairly easy. But prefer to avoid unpacking and searching irrelevant files. 

Worse  if its in .zpkg I haven't got a clue how to open that.  Sort of assuming metadata is configuration/compiler info or something esoteric though. Sounds like Zyxel tool needed too.

Also possible I do not have access if its in a "need to know" directory.

Mijzelf

Sorry for the confusion. The files is http://downloads.zyxel.nas-central.org/Users/Mijzelf/NAS326/zyxel_support_send_instruction.zip. It should be extracted to an sd card or usb stick.

Clay_JF2019

Just cold power boot NAS540 with media inserted? or do any buttons need to be held down during power up?

Also am I correct that files need to be put on USB stick inserted in back of NAS540 instead of SD card? How should USB stick be formatted - FAT32/FAT16/ext2/etc ?  Using Ubuntu or some other Linux desktop probably recommended if ext2/3/4 formatted I guess especially for copy. But if Windows file copy or some easily found utility works OK I would rather do that.

Eek! Do I need to worry about marking files with Linux execute and user/group/world privileges for this boot procedure? Is there a "proper" use of Linux tar command that will do all that automatically on a USB stick? Again only passingly familiar with Linux. Enough to know I need to ask questions rather than thrash. Especially as NAS540 may have different rules during boot (e.g. FAT16 capable and looking for certain file names regardless of file system rights).

I assume copy all the enclosed file-folder structure from .tgz archive with modifications as described. Including readme.  Will the check file script get executed

Thanks for some reason links did not highlight in Chrome.

Mijzelf

The stick/sd card needs to have a FAT filesystem, and you can use windows to put the files on it. No need for execute flags or owner metadata. FAT doesn't upport that.

Also am I correct that files need to be put on USB stick inserted in back of NAS540 instead of SD card?

Incorrect. The 'back usb thing' is only required for a nsa325, which has an USB3 port on front, which drivers are not yet loaded when the stick is probed. An nas5xx also supports an SD card, for this purpose.

Clay_JF2019

Still missing something. No flash or even reset.

Loaded SD card with files and folder.
Tried simple power off then on.
Long wait for flash (>10 minutes & just power light on steady).
Power reboot.
No joy. Still configured to IP and no access.

Also tried holding reset button 30 seconds while reapplying power. (Common idea for device flashing.)

Understanding is use SD slot - not USB (no USB drivers at boot from what I gather).

Assumed from mount paths that files in folder were supposed to remain in folder when copied to SD.  Is that wrong?

Clay_JF2019

Oops! missed "rename nas3xx_check_file to nas5xx_check_file"

But what about contents of that file?  Is it supposed to be the MD5sum or what?

I'll try it unchanged but I expect that the contents are device or firmware unique. Unless its an authentication password key. But check file sounds SHA1/MD5SUM like.  I suspect for whole or part of ROM -- not for the flash file. After all that has already been entered and checked.

Will be glad if I am wrong about that and flash works with simple renaming of file.

Mijzelf

Understanding is use SD slot - not USB (no USB drivers at boot from what I gather).

It should work both.

Assumed from mount paths that files in folder were supposed to remain in folder when copied to SD.  Is that wrong?

No, that's right.

The script /etc/init.d/rcS is responsible for executing the script on the stick/SD card. You can read here how that works.

Clay_JF2019

Nevermind file content question. 

Renamed everything including paths inside files to reflect nas5xxx instead of nas3xx. Retrying.