Kategorien
Forensik Linux security

CD Laufwerke bremsen

Aktuelle versuche ich ein paar vor mehr als 10 Jahren gebrannte CD- und DVD-Rohlinge zu retten. Die Daten lassen sich bei den meisten zu ca. 80% lesen.

Ich habe die beschädigten CDs und DVDs in 4 verschiedenen, je einem im PC- und einem im Laptop eingebauten DVD Laufwerk und einem „billigen“ USB DVD Laufwerk und meinem neu zu diesem Zweck erworbenen Blue-Ray USB-Laufwerk.
Bei allen Laufwerken erhalte ich das gleiche Ergebniss, es fehlen gut verteilt über den gesammten Datenträget einzelne Blöcke.

Den Rettungversuch habe ich unter UBUNTU 13.10 mit „dvdisaster“ durchgeführt und es lassen sich tatsächlich noch ein paar zusätzliche Prozente mit verringerter Laufwerksgeschwindigkeit aus den alten beschädigten CD- und DVD-Rohlingen holen.

Die Geschwindigkeit lässt sich unter Linux mit dem folgenden Befehl recht einfach, in meinem Besipiel auf „4x“, heruntersetzen.:

# hdparm -E 4 /dev/hdc

Leider lassen sich auch mit dieser Methode zwar mehr, aber nur selten wirklich alle Daten retten.

Die Positiven Punkte an dieser Anpassung?

  • Daten die sonst verloren wären lassen sich doch noch lesen
  • Die Einstellung ist beim Reboot wieder weg (oder mit einer Null an stelle der 4)
  • ein einfacher hdparm Befehl
Kategorien
Linux

squashfs Image einer Linux Distribution über Grub starten

Dies ist eine „Kurzanleitung“, wie ein squashfs Image über Grub zu starten. Ich gehe davon aus, das Grub installiert ist und das du das <LinuxBootCD>.iso Image besitzt.

Um unser Ziel zu erreichen kopieren wir einige Dateien aus dem ISO Image und schaffen einen Grub Eintrag.

$ sudo su
# mkdir /system
# mkdir loopmount
# mount -o loop .iso loopmount
# cp -a loopmount/system/vmlinuz1 /system
# cp -a loopmount/system/initrd1.img /system
# cp -a loopmount/system/filesystem.squashfs /system
# cp -a loopmount/system/filesystem.packages /system
# umount loopmount
# ls /system
filesystem.packages filesystem.squashfs initrd1.img memtest vmlinuz1

Jetzt sind alle benötigten Daten kopiert, es folgt die GRUB Einrichtung.

# vi /etc/grub.d/41_CB_squashfs

#!/bin/sh
exec tail -n +3 $0
menuentry 'Boote das squashfs Linux Image' --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
linux /system/vmlinuz1 boot=live live-media-path=/system splash vga=791 config quiet noprompt
initrd /system/initrd1.img
}

# update-grub

Dies ist bereits der gesammte Prozess. Nach der aktuelisierung der Grub Konfiguration via update-grub ist existiert der neue Boot-Eintrag.

Zeit neu zu booten und im Grub den neuen Boot-Eintrag zu wählen.

Ich mag diese Art der „Installation“, da der Boot-Vorgang dank squashfs sehr schnell und vor ungewollten Veränderungen geschützt ist. 😉

Kategorien
CL-35B2

Dual NAND für die NAS, eine Überlegung…

Die NAND Chips meiner Fantec CL-35B2 sind viel zu klein… aber ersetzten? ich mag eigentlich ein „Rettungs-System“ haben auf das ich zurückschalten kann wenn ich mist gebaut habe. 😉

Hier mein Entwurf zum NAND-Umschalter!

Dual NAND für die Fantec NAS

Details und Fotos werden folgen.

Kategorien
CL-35B2

NAND-Flash Schreibschutzschalter

Um für das NAND-Flash meiner CL-35B2 einen Schreibschutz zu realisieren recht es WP nach „Low“ (Vss) zu ziehen. (Pin 19 nach 13 schließen!)
Dies ist ein Hardware-Schreibschutzschalter wie er bei älteren USB Sticks manchmal umgesetzt wurde.
Es können bei geschlossener Verbindung zwischen WP (Pin 19) und Vss (Pin 13) keine Schreibvorgänge auf dem NAND-Flash ausgelöst werden, der Inhalt des Speichers ist nicht mehr veränderbar.

In der Standartkonfiguration stürzt die fantec CL-25B2 einfach ab, da der Logfiles geschrieben werden sollen. Diesem Absturz kann vorgebeugt werden, indem das Log Verzeichnis als tmpfs in der /etc/fstab konfiguriert wird.
WPschematic

IO0-7 Data Input / Output
CLE Command latch enable 16
ALE Address latch enable 17
CE Chip Enable 9
RE Read Enable 8
WE Write Enable 18
WP Write Protect 19
R/B Ready / Busy 7
Vcc Power Supply 12
Vss Ground 13
NC No Connection

Eine Weitere Anleitung, für einen NAND-Flash Umschalter habe ich hier hinterlegt.

Kategorien
Forensik Linux

Mod-Rewrite Funktionstest

mod_rewrite will manchmal nicht das tun was ich von ihm verlange. Manchmal habe ich auch eine mir unverständliche .htaccess Datei mit mod_rewrite Regeln die ich beim besten willen nicht nachvollziehen kann und auch wieder einfach nicht das tun was die READ.ME oder der Eigentümer der Datei behauptet.

Um in einer solchen Situation feststellen zu können ob das mod_rewrite auf dem Webserver funktionsfähig ist muss ich das irgendwie testen können.

Um einen solchen Test durchzuführen benötige ich drei  Dateien.
Eine .htaccess Datei und zwei HTML Dateien.
Wenn ich dann versuche nach dem Anlegen der Dateien diese aufzurufen.

Meine .htaccess Datei erhält den folgenden Inhalt:

RewriteEngine on
RewriteBase /
RewriteRule ^testing.php$ modrewrite.php

In der ersten Zeile starte ich, so vorghanden, das mod_rewrite, so das die beiden folgenden Zeilen, RewriteBase und RewriteRule, für den Apache eine Bedeutung erhalten. In der Zweiten Zeile lege ich die Basis der Umschreibe Regel fest. In der finalen dritten Zeile der .htaccess-Datei lege ich fest das alle Aufrufe welche die Datei testing.php erreichen sollen anstelle dieser die Datei modrewrite.php erreichen.
Wenn diese Regeln greifen ist es durch diese nicht möglich den Inhalt von „testing.php“ zu erhalten.

Meine beiden PHP Dateien erhalten den folgenden Inhalt:
modrewrite.php

<?php echo "mod_rewrite und PHP ".phpversion()." sind OK"; ?>

testing.php

<?php echo "mod_rewrite ist nicht funktionsfaehig"; ?>

Nach dem Anlegen der Dateien kann im Browser versucht werden die Internetseite http://domain.tld/testing.php auszurufen. Nur wenn im Browser der Text „mod_rewrite und PHP X.Y sind OK“ erscheint funktioniert mod_rewrite. Wenn etwas anderes angezeigt wird, „mod_rewrite ist nicht funktionsfaehig“, „echo „mod_rewrite ist nicht funktionsfaehig“;“ oder sogar „Fehler 500: Internal Server Error“, ist der Webserver nicht entsprechend eingerichtet und mod_rewrite kann leider nicht genutzt werden.

Kategorien
Linux security

OpenSSH Schützen…

OpenSSH abschalten

Auf vielen Systemen wird kein SSH Server benötigt, da der sicherste Dienst ist der ist, der nicht läuft schalten wir start des SSH Servers auf solchen Systemen am besten ab.
unter Fedora via:

chkconfig sshd off

unter Debian und Ubuntu via:

sudo update-rc.d -f ssh remove

Ausschließlich SSH Protocol Version 2 verwenden

in der Konfigurationsdatei /etc/ssh/sshd_config sollte die Verwendung des SSH Protokolls 2 erzwungen werden. Die Version 1 ist stark veraltet und sollte aus Sicherheitsgründen deaktiviert werden.

Protocol 2

SSH nur bestimmten Benutzern erlauben

Zur Übersichtlichkeit sollte immer via AllowUsers direktive in der Konfigurationsdatei /etc/ssh/sshd_config aufgezählt werden wer zugriff erhält. Ausschließlich bei zu vielen Benutzern oder sehr häufigen wechseln sollte mit der DenyUsers direktive eine Liste mit verbotenen Benutzern angegeben werden.

AllowUsers root vivek jerry

Idle Log Out Timeout festlegen

SSH Sitzungen von Benutzern die längere Zeit inaktiv sind sollten aus der SSH Sitzung geworfen werden. So kann keine SSH Sitzung missbraucht werden weil sie vergessen wurde.

ClientAliveInterval 300
ClientAliveCountMax 0

.rhosts Dateien der Benutzer ignorieren.

SSH kann den veralteten rsh Befehl emulieren, dies sollte, da es selten verwendet und häufig misbraucht wird, unterbunden werden.

IgnoreRhosts yes

Host basierende Authentifizierung abschalten

HostbasedAuthentication no

root-Login abschalten

Der root-Login sollte verboten werden, da automatische Passwort such Scripte zumeist Passwörter für den Benutzer root suchen.

PermitRootLogin no

Ein Banner einbinden

Ein Banner ist kein direkter Schutz Ihres SSH Servers. Das Banner zeigt einem eventuellen Angreifern das dies ein Konfigurierter SSH Server ist, es also vermutlich nicht lohnt es überhaupt zu versuchen.
Hierzu wird in der SSH Konfigurationsdatei /etc/ssh/sshd_config ein Banner angegeben.

Banner /etc/issue

Die Datei /etc/issue enthält das Banner, welches vor dem Login angezeigt werden soll.

Ändere den SSH Port und

Lege in der SSH Konfiguration, unter /etc/ssh/sshd_config, fest auf welche IP-Adressen SSH hört und unter welchen Port der SSH Server erreichbar sein soll.

Port 300
ListenAddress 192.168.1.5
ListenAddress 202.54.1.5

Nutze die Public Key basierte Authentifizierung

SSH Key erstellen

ssh-keygen -t rsa

zum erstellen eines SSH Schlüssels verwenden.

SSH Public Key übertragen

mit dem folgendem Befehl den Public-Key auf den Server übertragen:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

wenn ssh-copy-id nicht verfügbar ist kann der Public-Key

cat ~/.ssh/id_rsa.pub | ssh user@server 'umask 077; cat >> .ssh/authorized_keys'

SSH-Server konfigurieren

In der Konfiguration /etc/ssh/sshd_config, die Publick-Key Authentifizierung aktivieren.

PubkeyAuthentication yes

Key automatisch laden

Auf den Clients, den Computer die sich via SSH zum Server verbinden sollen ist es schön, wenn die Keys beim Laden schon im RAM sind. Hierzu gibt es je nach Betriebssystem verschiedene Tools.:

  • unter Windows: Pageant
  • unter Linux: ssh-agent
  • unter MacOS: ssh-agent (seit Version 10.5 Leopard teil des Systems)

Unter Linux kann in der ~/.bashrc mit einem kurzen Script der ssh-agent beim Login geladen werden.:

test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login"

Chroot SSHD

In der Konfiguration /etc/ssh/sshd_config kann seit SSH 4.8p1 die Funktion chroot() zum Einrichten eines Changeroot Gefängnisses verwendet werden. Der Benutzer wird nach dem Login in sein Heimatverzeichnis einzusperren.

Subsystem sftp internal-sftp

Match group sftponly
   ChrootDirectory /home/%u
   X11Forwarding no
   AllowTcpForwarding no
   ForceCommand internal-sftp

Das Verzeichnis in das via chroot() gewechselt werden soll muss dem Benutzer root gehören. Nach dem chroot() Aufruf wechselt die SSH Sitzung in ein Verzeichnis relativ zum neuen root-Verzeichnis, aus diesem Grund wechseln wir das Heimatverzeichnis auf „/“.

# chown root:root /home/user
# usermod -d / user
# adduser user sftponly
Kategorien
CL-35B2

FANTEC CL-35B2 Zeitzonen korrigieren

Die voreingestellte Zeitzone auf der NAS CL-35B2 von fantec ist MST, die US Mountain Standard Time (-8 MEZ). Da mich alles was nicht meiner Lokalen, Berliner, Zeit entspricht irritiert habe ich auch im Fedora Core 12 des CL-35B2 die Berliner Zeit konfiguriert.

Um die Zeit zu konfigurieren bin ich entsprechend meiner folgenden Dokumentation vorgegangen.:

Zuerst den NTP Client stoppen:

/etc/init.d/ntpd stop

Die Zonen-Datei für Berlin nach /etc/localtime kopieren:

cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Zeit mit dem Server der Physikalisch-Technische Bundesanstalt abgleichen.

ntpdate ptbtime1.ptb.de

Zeit in die Hardwareuhr schreiben.

/sbin/hwclock --systohc

Konfiguration für den NTP Dienst schreiben:

echo "server ptbtime1.ptb.de" > /etc/ntp.conf
echo "server ptbtime2.ptb.de" >> /etc/ntp.conf
echo "server ptbtime3.ptb.de" >> /etc/ntp.conf
echo "restrict default ignore" >> /etc/ntp.conf

und den NTP Dienst neu starten:

/etc/init.d/ntpd start
Kategorien
Linux ViewPad 7e

ViewPad 7e Rettung

Da die Rettung der CLOUD NAS CL-35B2 funktioniert hat, werde ich als nächstes versuchen ein „altes“ ViewPad 7e der STRATO AG (das gab es als giveaway zu HiDrive Verträgen dazu) mit einem Linux Kernel und fedora 12 zu betreiben. 🙂

als erstes, die Dokumentation des ViewPad 7e:
Die Harware:

  • CPU
    • Samsung S5PC111 Exynos 3110
  • RAM
    • 512 MiB
  • NAND
    • 4 GiB
  • Display
    • TFT 600 x 800 Pixel 143 ppi
  • Akku
    • Li-Polymer 3300 mAh
  • Bluetooth
    • 2.1, EDR
  • Wi-Fi
    • 802.11 b, g, n

Die U-Boot Parameter von einem Funktionsfähigen ViewPad 7e:
bootcmd=run bootcmd_android
mtdpart=80000 400000 3000000
bootdelay=1
baudrate=115200
ethaddr=00:40:5c:26:0a:5b
ipaddr=192.168.0.20
serverip=192.168.0.10
gatewayip=192.168.0.1
netmask=255.255.255.0
filesize=0
uboot_addr=30000000
kernel_addr=30008000
kernel_start=30008040
ramdisk_addr=31000000
recovery_addr=31000000
logo_addr=32000000
temp_addr=32200000
charlib_addr=32200300
clear=setenv filesize 0
_prg_bl=fuse uboot1 ${uboot_addr} ${filesize};fuse uboot2 ${uboot_addr} ${filesize}; run clear
_prg_kn=fuse kernel1 ${kernel_addr} ${filesize};fuse kernel2 ${kernel_addr} ${filesize}; run clear
_prg_ramdisk=fuse ramdisk1 ${ramdisk_addr} ${filesize};fuse ramdisk2 ${ramdisk_addr} ${filesize}; run clear
_prg_recovery=fuse recovery1 ${recovery_addr} ${filesize};fuse recovery2 ${recovery_addr} ${filesize};run clear
_prg_logo1=fuse logo1 ${logo_addr} ${filesize}; run clear
_prg_logo2=fuse logo2 ${logo_addr} ${filesize}; run clear
_prg_logo3=fuse logo3 ${logo_addr} ${filesize}; run clear
load_uboot_sd=movi 1 init; fatload mmc 1:1 ${uboot_addr} u-boot.bin
load_bsp_sd=movi 1 init; fatload mmc 1:1 ${temp_addr} bspfuse
load_char_sd=fatload mmc 1:1 ${charlib_addr} char.bin
load_uboot_dnw=dnw ${uboot_addr}
load_uboot=load uboot ${uboot_addr}
load_kernel_sd=movi 1 init; fatload mmc 1:1 ${kernel_addr} uImage
load_kernel_dnw=dnw ${kernel_addr}
load_kernel=load kernel ${kernel_addr}
load_ramdisk_sd=movi 1 init; fatload mmc 1:1 ${ramdisk_addr} ramdisk-uboot.img
load_ramdisk_dnw=dnw ${ramdisk_addr}
load_ramdisk=load ramdisk ${ramdisk_addr}
load_recovery_sd=movi 1 init; fatload mmc 1:1 ${recovery_addr} ramdisk-recovery-uboot.img
load_recovery_dnw=dnw ${recovery_addr}
load_recovery=load recovery ${recovery_addr}
load_logo_sd=movi 1 init; fatload mmc 1:1 ${logo1_addr} logo1.img
load_logo_dnw=dnw ${logo_addr}
prg_uboot_sd=run load_uboot_sd; run _prg_bl
prg_uboot_dnw=run load_uboot_dnw; run _prg_bl
prg_kernel_sd=run load_kernel_sd; run _prg_kn
prg_kernel_dnw=run load_kernel_dnw; run _prg_kn
prg_ramdisk_sd=run load_ramdisk_sd; run _prg_ramdisk
prg_ramdisk_dnw=run load_ramdisk_dnw; run _prg_ramdisk
prg_recovery_sd=movi 1 init; fatload mmc 1:1 ${recovery_addr} ramdisk-recovery-uboot.img; run _prg_recovery
prg_recovery_dnw=dnw ${recovery_addr}; run _prg_recovery
prg_logo1_sd=movi 1 init; fatload mmc 1:1 ${logo_addr} logo1.img; run _prg_logo1
prg_logo2_sd=movi 1 init; fatload mmc 1:1 ${logo_addr} logo2.img; run _prg_logo2
prg_logo3_sd=movi 1 init; fatload mmc 1:1 ${logo_addr} logo3.img; run _prg_logo3
prg_logo_sd=run prg_logo1_sd; fatload mmc 1:1 ${logo_addr} logo2.img; run _prg_logo2;fatload mmc 1:1 ${logo_addr} logo3.img; run _prg_logo3
prg_logo1_dnw=dnw ${logo_addr}; run _prg_logo1
format_inand=fatformat mmc 0:1; ext3format mmc 0:2; ext3format mmc 0:3; ext3format mmc 0:4
bootcmd_smt=movi 1 init; movi 0 init; run prg_uboot_sd; run prg_logo1_sd; run prg_kernel_sd; run prg_recovery_sd; reset
bootcmd_recovery=run bootargs_android; run load_kernel; run load_recovery; bootm ${kernel_start} ${recovery_addr}
bootcmd_android=run bootargs_android; run load_kernel; run load_ramdisk; bootm ${kernel_start} ${ramdisk_addr}
bootargs_android=setenv bootargs console=ttySAC2,115200 root=/dev/ram0 rw ramdisk=4608 init=/init androidboot.serialno=SWV113700001

Bei einem Defekten ViewPad 7e versucht Windows einen Treiber für die Hardware „SEC S5PC110 Text B/D“ zu installieren.

Die Ausgabe via TTL:
SD checksum Error

SD Init Error
ªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªª
Uart negotiation Error

Insert an OTG cable into the connector!

Laut Dokumentation des SOC S5PC111 kann dieser von einer SD Karte, via TTL und vom NAND booten, leider sind auf anhieb kein entsprechendes UBoot Image im Internet zu finden.

Die TTL-Pads sind abgebrochen, die Hardware ist somit nicht mehr der Rettung wert…

Kategorien
CL-35B2 Linux

CL-35B2 Rettungssystem (final)

Dieser Artikel enthält meine lange versprochene Anleitung wie ein Rettungssystem für die fantec CL-35B2 erstellt werden kann. In dieser Anleitung zeige ich wie „auf die Schnelle“ ein bereits fertiges Rettungssystem für die fantec CL-35B2 auf eine Festplatte geschrieben wird um die NAS von dieser Festplatte zu starten. ☺

Leider enthält das Rettungssystem aktuell noch keine Unterstützung für die Netzwerkhardware der NAS. Dies bedeutet das Du dieses Rettungssystem über das TTL Interface der CL-35B2 bedienen musst!
(Alternativ versuche eine USB-Netzwerkkarte, von dem verwendeten Linux Kernel werden einige USB Netzwerkkarten unterstützt.)

Für die Verwendung dieses Rettungssystems benötigst Du eine SATA-Festplatte. Alle Daten auf dieser Festplatte gehen bei der Installation des Rettungssystems verloren.

In der folgenden Download Datei ist ein Installations-Script enthalten, das die beim Aufruf angegebene Festplatte überschreibt. Die auf der Festplatte gespeicherten Daten gehen durch diesen Vorgang unwiederruflich verloren. Im Anschluss wird das RescueSystem für die fantec CL-35B2 auf dieser Festplatte hinterlegt.

Download: fantec Rescue-System

Der Download ist sowohl über den Obenstehenden Link als auch via wget möglich.:

wget https://loteks.de/wp-content/uploads/2013/06/fantec_CL-35B2_rescue.tar.gz

Die im Download enthaltene Datei fantec_CL-35B2_rescue.tar.gz kann mit dem Befehl tar, mit den Optionen „xzf“, entpackt werden.

tar xzf fantec_CL-35B2_rescue.tar.gz

Das Script wird nach dem entpacken via ./install.sh /dev/sdx aufgerufen, wobei /dev/sdx die Festplatte ist auf welche das Rettungssystem geschrieben werden soll.
(☠Alle auf der Festplatte gespeicherten Daten gehen unwiederruflich verloren!☠)

Ich habe das Linux Image aus den gleichen „Fedora ARM 12″[1] Quellen zusammengestellt, welche von fantec verwendet wurden um das System der fantec CL-35B2 zusammen zu stellen.
In der Distribution, so wie sie im .tar.gz Archive enthalten ist, ist „unnötiger weise“ Samba, SSH und ddclient enthalten da ich dieses Image für Experimente mit einer meiner CL-35B2 verwendet habe.

[1]http://ftp.linux.org.uk/pub/linux/arm/fedora/pub/fedora/linux/releases/12/Everything/arm/os/Packages/

Kategorien
CL-35B2 Linux

Boot CL-35B2 from SATA

Ich habe einen ersten Erfolg erzielt, die CL-35B2 von einer SATA Festplatte zu starten. In der Dokumentation des SOC ist ein folgend erklärter Bootcode angegeben der auf die SATA Festplatte geschrieben werden muss um von der Festplatte zu starten.

Erstellen der Festplatte:
– Welche Festplatte soll überschrieben werden

export disk=/dev/sdc

– Festplatte leeren

dd if=/dev/zero of=$disk bs=512

– Bootcode auf die Platte schreiben (Perl Magic 🙂

perl < print "\x00" x 0x1a4;
print "\x00\x5f\x01\x00";
print "\x00\xdf\x00\x00";
print "\x00\x80\x00\x00";
print "\x00" x (0x1b0 -0x1a4 -12 );
print "\x22\x80\x00\x00";
print "\x22\x00\x00\x00";
print "\x00\x80\x00\x00";
EOF

– Bootblock auf die Platte schreiben

dd if=./resource/stage1.wrapped of="$disk" bs=512 seek=34

– das U-Boot auf die Festplatte schreiben (Quellcode folgt!)

dd if=./resource/u-boot.wrapped_from-ox820source of="$disk" bs=512 seek=154

Wenn die Festplatte in slot 1 der CL-35B2 eingebaut wird bootet die NAS den U-Boot Bootloader von der Festplatte.
UBoot Dateien