« Back to all recent discussions

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

Clay_JF2019Clay_JF2019 Posts: 25  Junior Member
edited January 7 in Questions
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.


Best Answer

  • Clay_JF2019Clay_JF2019 Posts: 25  Junior Member
    edited March 28 Accepted Answer
    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).

    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.

    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.


  • MijzelfMijzelf Posts: 572  Heroic Warrior Member
    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_JF2019Clay_JF2019 Posts: 25  Junior Member
    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_JF2019Clay_JF2019 Posts: 25  Junior Member
    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.

  • MijzelfMijzelf Posts: 572  Heroic Warrior Member
    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_JF2019Clay_JF2019 Posts: 25  Junior Member
    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.
  • MijzelfMijzelf Posts: 572  Heroic Warrior Member
    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_JF2019Clay_JF2019 Posts: 25  Junior Member
    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_JF2019Clay_JF2019 Posts: 25  Junior Member
    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.
  • MijzelfMijzelf Posts: 572  Heroic Warrior Member
    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_JF2019Clay_JF2019 Posts: 25  Junior Member
    Nevermind file content question. 

    Renamed everything including paths inside files to reflect nas5xxx instead of nas3xx. Retrying.
  • Clay_JF2019Clay_JF2019 Posts: 25  Junior Member
    Used notepad to edit file content. Including 2 references in script.  Seem to remember that is OK.

    Anyways updated to cover if NAS540 uboot expects folder named nas5xx_fw instead of nas3xx_fw

  • Clay_JF2019Clay_JF2019 Posts: 25  Junior Member

    unpacked .zip from http://downloads.zyxel.nas-central.org/Users/Mijzelf/NAS326/zyxel_support_send_instruction.zip

    copied unpacked contents to

    FAT formatted SD card (old FAT16 not FAT32 or other extended FAT)

    edited file and folder names and file content from nas3xx to nas5xx including paths and shell script references using Notepad for internal file editing.

    changed MD5sum in nas3xx_md5sum to match NAS540 firmware being flashed using Notepad
      (will recheck this. Not sure now that MD5sum was for unpacked firmware or whole download)
      (will also recheck this path)

    renamed firmware to ras.bin and placed it inside renamed nas5xx_fw folder

    Placed SD card in NAS540 slot

    unplugged power from NAS540 
    reapplied power
    waited until NAS Seeker found NAS540
    No Joy

    repeated procedure but held reset power down as power was restored for 30 seconds
    No joy

    I will recheck nas5xx_md5sum for correct info & if incorrect I will report results after correction

  • Clay_JF2019Clay_JF2019 Posts: 25  Junior Member
    Hmmm...It would be good to know if the reflash might have been successful but not a problem solver.

    Could a successful reflash leave a hostile configuration or addons in place with a disabled reset button? 

    I have been making the assumption that the NAS540 will be reset as part of firmware flash.
    Or that reflash will at least restore function to the reset button. And that any corrupt add-on routines will get flushed from onboard memory. Is this a bad assumption?

    The point of my reflash is to regain control by removing any changes to firmware and stored configuration including addons not stored on disks.

  • Clay_JF2019Clay_JF2019 Posts: 25  Junior Member
    MD5sum was wrong.  I had copied M5sum for whole firmware .zip.   

    Applied new MD5sum for just the ras.bin firmware 639d3e791d222f65377a612cf0cb582c in this case. 

    IDK if its different results or not.
    NAS starter seems unable to detect. But had some detection issues before.

    Possibly firmware download got corrupted
    Will probably need to download firmware again. Confirm .zip MD5sum matches.
    Plug in new firmware MD5sum and copy new ras.bin
    Try yet again.

    P. S. still do not know if I need to do more than 

    remove power
    insert SD
    restore power
    wait x minutes
    run NAS Starter

    IDK if there should be any buttons pushed/held down or specific lights sequence to wait on 

  • Clay_JF2019Clay_JF2019 Posts: 25  Junior Member
    Seem to have flashed something. Because NAS Starter no longer can probe NAS540 out.

    Not good. But assuming it can still be recovered.

    Is the uboot.bin really the same for NAS540 as NAS320? 
    I can see how it might be. But I am looking for factors that might have caused bad flash.
    Ones that I can correct.

Sign In or Register to comment.