The device is advertised as follows: "Whether you're a beginner or an experienced coder, HackyPi from SB Components is a versatile and accessible platform for expanding your knowledge and skills in the exciting world of cybersecurity and coding." I am curious to see if this dream comes true.

I've ordered HackyPi on kickstarter.com and I've received it in May 2023. You can buy HackyPi on sb-components.co.uk.

There is another project called Hacky Pi which is completely different and based on a standard Raspberry Pi.

If you have already used Raspberry Pi Pico (RP2040) and CircuitPython, it's very easy to program. But if it's your first time it's important to get familiar with two different ways to edit your scripts.

If you connect the HackyPi to a USB port then a volume named HACKYPI is mounted by default. And if you use a text editor and save code.py then it will be reloaded immediately. You could change this behavior by setting supervisor.disable_autoreload().

CircuitPython and the computer are accessing the same filesystem simultaneously. Thats why it's best to use either one or the other. I recommend using the latest version of Thonny which is able to manage the files directly in CircuitPython over the USB serial connection. There are instructions available how to setup HackyPi.

You can disable mounting of HACKYPI if you don't need to access it from your computer. First boot.py is executed and then code.py. You only need to enter following to boot.py:

import storage
storage.disable_usb_drive()

Verify code.py that there is no storage.enable_usb_drive() which would mount HACKYPI again.

Normally you can repair filesystem errors without any issues but when it's unsuccessful then you may need to re-flash CircuitPython. Be sure to get the firmware from the CircuitPython Website as the firmware.u2f from github.com/sbcshop is outdated and doesn't work. Warning: This will erase all scripts and other files which were saved on your HackyPi! After flashing do not forget to copy the lib folder (and all subdirs and files) to HACKYPI. Always keep a backup somewhere else.

Pros

• Raspberry Pi Pico RP2040 with a 240x135px TFT display in a nice a 3D printed black enclosure.
• It only costs ~USD 20
• Example payloads for Windows and MacOS are available.
• A display is much better suited to indicate the current program status than an led which lights green or flashes red.

Cons

• I couldn't find any community to share experiences and payloads with other users. You can find answers or ask new questions at issues on github.com (which seems to be unmaintained Update: It seems to be updated very infrequently by the maker) or ask SB Components for help.
• Most of the examples are poorly documented.
• Why there are no examples provided for Linux? For Gnome use Alt-F2 and open gnome-terminal. Use keyboard_layout.write("\n") instead of keyboard.send(Keycode.ENTER), e.g.

  # open gnome-terminal on linux
  keyboard.send(Keycode.ALT, Keycode.F2)
  time.sleep(1)
  keyboard_layout.write("gnome-terminal\n")
  time.sleep(1)
  
  # list ip addresses
  keyboard_layout.write("ip address list\n")
  
  # close terminal after 3 seconds
  time.sleep(3)
  keyboard_layout.write("exit\n")

• The Display_Images_from_SDCard example should be replaced by some other script which makes more sense. It takes almost 3 minutes to load a full screen image. I've tried different SD cards but the speed was equally slow and I just spent unnecessary time debugging. The internal storage is much faster: Display_Images_FromHackyPi requires only ~4 seconds for a full screen image. Update: This issue has been fixed by not rotating the image. But keep in mind that only ~1004kB are allocated for the internal storage. The lib directory is 70kB and each image requires ~100kB so there is not much space left.
• HackyPi is for software hackers only. Unfortunately there is nothing you can really do as a hardware hacker, but to be fair it was never intended for this purpose. On the PCB there are no pads with GPIO pins to solder additional components like switches or sensors.
• The only button which is available is BOOT, and it's reserved for flashing and is normally not accessible from CircuitPython. It would have been nice to select the OS and payload by pressing a button. Following hack might work but I haven't tested it yet: Reading RP2040 BOOTSEL pin from code. With some additional buttons this would be much easier to implement.
• No WiFi connectivity
• No USB-C connector or adapter included

FAQ

• How to prevent autoreload when files are copied to the USB mass storage device?

  supervisor.disable_autoreload()

• How to disable USB mass storage device?

  import storage
  storage.disable_usb_drive()

• How to change the name of the USB mass storage device?
  Try the new example rename_device_script.py with the default label:

  ''' 
  This script rename you device from default circuitpython to your favorite name,
  Just save this script as code.py in HackyPi, then remove and re-insert.
  '''
  import storage
  storage.remount("/", readonly=False)
  m = storage.getmount("/")
  m.label = "HACKYPI"    # replace name which you are interested for your device
  storage.remount("/", readonly=True)
  storage.enable_usb_drive()

• Is keystroke reflection possible like with the USB Rubber Ducky?
  No, probably not yet. It might be possible in future CircuitPython versions.
• Is it possible to display images from the computer on the HackyPi?
  Yes, I think its possible to run some code on the computer and send the scaled bmp images over the USB serial connection but I assume it will be very slow.
• I can see messages that the images are loaded correctly but the display stays black, why?
  Check if the backlight is turned on:

  # turn on backlight
  tft_bl = board.GP13
  led = digitalio.DigitalInOut(tft_bl)
  led.direction = digitalio.Direction.OUTPUT
  led.value=True

Conclusion

The LCD screen is a good replacement for status LEDs and clearly shows the program state but otherwise HackyPi is not very beginner friendly. The examples aren't very useful and often not documented. The hardware has many limitations: No additional buttons and the SD card speed is very slow. Unfortunately, nobody seems to use this device which means you only have a few examples from SB Components to start with. Some examples are broken and do not work. The issues are not getting fixed which makes it even worse. Update: Two days after posting my review some issues have been resolved but I haven't tested them yet. I've still haven't found a community to share experiences and payloads. That's why I can't recommend HackyPi for beginners.

Alternatives

I you're really interested in USB security I would rather buy a USB Rubber Ducky, O.MG Cable or Bash Bunny which is better documented has many more features and lots of examples to explore.

If you want a similar device like the HackyPi with a LCD screen then a LILYGO® T-Display seems to be the better choice. It costs ~USD 18, shipping and case included. There is no SD card slot but it has three additional buttons (one of them is the reset button) and a red LED. It's very similar but in my opinion it's more versatile than the HackyPi and is suitable for both software and hardware hackers. Some GPIOs for the LCD are different but it's easy to run most of the HackyPi examples on a LILYGO® T-Display by modifying only a few lines and adding some code to drive the PWR_EN pin (I assume to conserve power when a LiPo battery is connected for standalone operation which doesn't make sense as a HackyPi replacement). Otherwise the LCD stays dark:

# LILYGO(R) T-Display - same ST7789 1.14" lcd, but on different GPIO
tft_clk = board.GP2 # must be a SPI CLK
tft_mosi= board.GP3 # must be a SPI TX
tft_rst = board.GP0
tft_dc  = board.GP1
tft_cs  = board.GP5
tft_bl  = board.GP4

# PWR_EN to enable 3.3V for the peripherals
pwr_en  = board.GP22 # PWR_EN

#define PWR_EN pin to enable 3.3V
power = digitalio.DigitalInOut(pwr_en)
power.direction = digitalio.Direction.OUTPUT
power.value=True

You need a passive USB-C(m) to USB-A(m) cable to connect the board with the computer which is not included. To connect it to a computer having an USB-C port you need an additional USB-A(f) to USB-C(m) adapter. A standard USB-C(m) to USB-C(m) cable doesn't work as it contains active components for USB PD protocol which is unsupported on the LILYGO® T-Display. But I've found a USB Type C Plug to Plug Adapter which works great to connect the board to a USB-C(f) port. And the USB-A Plug to USB-C Plug Adapter seems to be the ideal adapter for a USB-A(f) port.

Be sure to install CircuitPython for RP2040 and not for the "T-Display RP2040 by LILYGO" which uses a different module to drive the LCD and is incompatible whith the code provided for HackyPi.

Ich hatte noch einen alten Lightify Gateway rumliegen, und ich wollte ihn im September 2021 nach der Abschaltung der Lightify-Server noch ein letztes Mal updaten.



Folgendes wurde in der App unter Updates angezeigt:



Gateway Wi-Fi

Current Version: 1.7.15.0

New Version: 1.8.3.0

What's New



Gateway ZigBee

Current Version: 1.2.0.68

Update Details



Jedes Mal nach dem starten der App nervte mich die Update-Meldung. Aber auch wenn ich das Update gestartet habe, flackerte die LED ca. 20-30s orange (=Flashvorgang?), und wechselte danach wieder auf grün, aber die App reagierte nicht mehr, und nach dem Neustart der App blieb die Version unverändert. Ein Gateway-Reset und Wifi neu konfigurieren half auch nicht, und eine Antwort vom Support blieb aus.



Im Packet Capture sah ich kurz nach dem Start des Updates eine unverschlüsselte HTTP-Verbindung nach:

http://s3-eu-west-1.amazonaws.com/lightify-osram-firmware/firmware/release/Cloud/GW/zigbeegw_MC200_V1.8.3.0.bin

Download der URL ist problemlos im Browser möglich. Gemäss Info unter "What's New" waren frühere Versionen 1.8.2.0, 1.7.17.0 und 1.7.15.0, und letztere war installiert. Und auch diese Versionen waren alle verfügbar, z.B.

http://s3-eu-west-1.amazonaws.com/lightify-osram-firmware/firmware/release/Cloud/GW/zigbeegw_MC200_V1.8.2.0.bin



Was passiert, wenn ich dem Gateway eine andere Version liefere als angefordert? Webserver eingerichtet, Pfad /lightify-osram-firmware/firmware/release/Cloud/GW/ erstellt, zigbeegw_MC200_V1.8.2.0.bin als zigbeegw_MC200_V1.8.3.0.bin darin gespeichert und auf dem Router statischen DNS-Eintrag für s3-eu-west-1.amazonaws.com erstellt mit der IP meines Werbervers.



Update gestartet, aber keinen Unterschied zu vorher festgestellt. App beendet und neu gestartet, und siehe da: Current Version: 1.8.2.0, Update erfolgreich!



Dann hab ich den statischen DNS entfernt und das Update nochmals gestartet - Meldung, dass das Update erfolgreich war, und Current Version: 1.8.3.0

Nach einem BIOS-Update (Version 1.11.0, 1.11.0, Release Date: 19 Aug 2020) konnte der Akku nicht mehr geladen werden, wenn ich das Netzteil an einer der zwei USB-C / Thunderbolt Ports auf der linken Seite angeschlossen habe. An diesen zwei Port wurden auch keine USB-Geräte mehr erkannt. Der USB-C Port auf der rechten Seite funktionierte hingegen einwandfrei.

Im BIOS sah ich im Event Log, dass ein Update fehlgeschagen ist mit der Message: "Alert! Firmware Update is failed", ohne weitere Angaben zur betroffenen Firmware.  Da ich während des BIOS Updates keine Fehler festgestellt habe, ging ich von einem fehlenden Update einer anderen Komponente aus. Da ich Debian 10 verwende und einige Updates (u.a. auch das Firmware-Update des Thunderbird-Controllers) trotz vorinstalliertem Ubuntu offenbar nur für Windows 10 angeboten werden, habe ich Windows mit Hilfe von Rufus auf einem schnellen USB-Stick installiert. Nach der Installation der "Dell Update Application" (Version: 3.1.3, A00, Release Date: 04 Aug 2020) und des "Intel Thunderbolt Firmware Updates" (Version 4.44.101.072, A01, Release Date: 05 Feb 2020) funktionierten die Ports jedoch immer noch nicht. Erst durch ein BIOS-Reset auf die Werkeinstellungen und einer erneuten Installation des selben BIOS Updates wurde der "Main USB PD Controller 1" nicht wie alle andern bereits installieren Updates übersprungen, sondern diesmal erfolgreich installiert. Seitdem funktionieren die zwei betroffenen USB-C Ports wieder einwandfrei. Vielleicht hilft es, das BIOS Update (ohne die Installation der neuesten Thunderbolt-Firmware oder BIOS-Reset) nochmals einzuspielen und den Output zu überwachen.

Die Anmeldung im Dell Community Forum scheint unter Linux mit Firefox und Google Chrome nicht zu funtionieren (Fehler: HTTP Status 401, Stand: 02 Nov 2020), und da auch nach erfolgreicher Anmeldung unter Windows scheinbar keine Kommentare zu älteren Beiträgen oder solchen mit einer bereits vorhandenen Lösung möglich sind, findet ihr meine Lösung hier

This error message is misleading and is displayed when APN settings have not yet been saved.

Continue reading "Android: "Access Point Name settings are not available for this user""

The best result I've had with Qubes 3.0 (stable). I've choosed KDE only installation. For beginners I do not recommend installing Qubes-R3.1-rc1 yet as it has some bugs (e.g. it must be installed with "user' as username to avoid errors in installation) and networking doesn't work out of the box.

1) Download Qubes-R3.0-x86_64-DVD.iso and copy ISO to 8GB USB stick (Change /dev/sdX to your USB stick):

umount /dev/sdX; dd if=/path/to/Qubes-R3.0-x86_64-DVD.iso of=/dev/sdX bs=16M; sync

2) Boot and install Qubes from USB stick. Press F10 for Boot Menu or F2 for BIOS. If selectable choose the boot device without UEFI.

3) To avoid an unbootable system do not press the reboot button after installation is finished! Change to console with Ctrl-Alt-F1 and reinstall Grub first:

grub2-install --modules=part_msdos --boot-directory=/mnt/sysimage/boot /dev/nvme0n1

If you already rebooted you can also boot again from USB Stick and choose Troubleshooting - Rescue Qubes System and reinstall Grub from there.

4) After updating x11 drivers on Librem 13 I've had freezes at the lock screen so do not update as recommended [3]. Just connect to Internet & update dom0:

sudo qubes-dom0-update --releasever=3.1 xorg-x11-drivers xorg-x11-drv-intel
sudo qubes-dom0-update

5) Update all Template and Standalone VM's in Qubes VM Manager. Do not forget to shutdown the Template VM (e.g. fedora-21) and restart the depending VM's.

1) Multiarch aktivieren:

sudo dpkg --add-architecture i386
sudo apt-get update

2) Download Citrix Receiver for Linux 64bit: http://www.citrix.com/downloads/citrix-receiver/linux

3) Pakete installieren, Zertifikate kopieren (nspluginwrapper wird nicht benoetigt):

sudo dpkg -i icaclient_13.1.0.285639_amd64.deb
sudo apt-get -f install
sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts

4) Test: Wenn beim Ausfuehren von /opt/Citrix/ICAClient/wfica ein Fenster mit der Meldung "Corrupt ICA file" erscheint, ist die Installation erfolgreich.

5) Firefox neu starten, Plugin aktivieren unter Menu: Add-ons - Plugins - "Citrix Receicer for Linux" - "Always activate".


Optional - Installation USB Support Package

1) Download USB Support Package for Linux 64bit: http://www.citrix.com/downloads/citrix-receiver/linux

2) Pakete installieren:

sudo apt-get install libcap2:i386
sudo dpkg -i ctxusb_2.4.285639_amd64.deb
sudo apt-get -f install

3) Falls der Daemon nicht gestartet werden kann, Abhaengigkeiten pruefen mit /opt/Citrix/ICAClient/util/hdxcheck.sh, noetigenfalls weitere Pakete installieren und anschliesend Daemon neu starten:

sudo service ctxusbd restart


Quellen:
http://superuser.com/questions/714375/how-do-i-install-citrix-ica-client-receiver-13-on-debian-64-bit-linux
https://help.ubuntu.com/community/CitrixICAClientHowTo

Problem:
Ich verwende OpenWRT als Router mit VDSL-Bridge.
Mein Provider stellt mir eine dynamische IP und ein statisches /29-Netz zur Verfuegung.
Die dynamische WAN-IP moechte ich fuer meine Rechner im LAN und das statische /29-Netz fuer Server in der DMZ nutzen.
Im Web-Interface (LuCI) laesst sich NAT jedoch nicht deaktivieren.

LAN (VLAN 2, eth0.2) --> WAN: NAT, SRC-IP: dynamische IP
DMZ (VLAN3, eth0.3) --> WAN: Forwarding ohne NAT

Loesung:

1) LuCI: Network - Firewall - dmz - Forwarded Traffic Default Policy: accept

2) /etc/firewall.postrun erstellen:

# vorher: pruefen mit iptables -t nat -L -n -v --line-numbers
#
#Chain zone_dmz_nat (0 references)
#num   pkts bytes target     prot opt in     out     source               destination
#1        0     0 MASQUERADE  all  --        eth0.3  0.0.0.0/0            0.0.0.0/0
#
#Chain zone_wan_nat (1 references)
#num   pkts bytes target     prot opt in     out     source               destination
#1      103  6148 MASQUERADE  all  --        ppp0    0.0.0.0/0            0.0.0.0/0

# alle masquerade rules in table:nat, chain:zone_dmz_nat loeschen
MASQDMZ=`iptables -t nat -L zone_dmz_nat -n -v --line-numbers|grep MASQUERADE|cut -d' ' -f1`
for RULENUM in $MASQDMZ; do
  iptables -t nat -D zone_dmz_nat $RULENUM
done

# alle masquerade rules in table:nat, chain:zone_wan_nat mit MASQUERADE und ppp0 ersetzen
MASQWANPPP=`iptables -t nat -L zone_wan_nat -n -v --line-numbers|grep MASQUERADE|grep "ppp0"|cut -d' ' -f1`
NOMASQSRC=208.77.188.160/29
for RULENUM in $MASQWANPPP; do                                                       
  iptables -t nat -R zone_wan_nat $RULENUM -o ppp0 ! -s $NOMASQSRC -j MASQUERADE     
done
                        
# debugging zone_wan_nat
# herausgefunden, dass man nicht nach dem src interface filtern kann (IN= OUT=ppp0)
#
#iptables -t nat -I zone_wan_nat -o ppp0 -j LOG
#iptables -t nat -D zone_wan_nat 1
                                                             
# nachher: pruefen mit iptables -t nat -L -n -v --line-numbers
#
# Chain zone_dmz_nat (0 references)                                            
# pkts bytes target     prot opt in     out     source               destination
#                                
# Chain zone_wan_nat (1 references)                                            
# pkts bytes target     prot opt in     out     source               destination
#   10  1251 MASQUERADE  all  --  *      ppp0   ! 208.77.188.160/29      0.0.0.0/0

3) /lib/firewall/uci_firewall.sh editieren:
fw_init() {
        (...)
        for interface in $INTERFACES; do
                fw_event ifup "$interface"
        done

        #jke/20101128
        echo "Loading include /etc/firewall.postrun"
        [ -e /etc/firewall.postrun ] && . /etc/firewall.postrun
}

Neue Anleitung mit Standard Image und konfiguration mehrheitlich mit LuCI

• Nachfolger heisst alix2d2 und ist bei www.pcengines.ch erhaeltlich. AC adapter, Pigtail cable, Antenna und Enclosure, Compact Flash und Null modem cable nicht vergessen!
• Image auf CF schreiben. Achtung: Device darf nicht gemountet sein!

$ wget http://backfire.openwrt.org/10.03/x86/openwrt-x86-squashfs.image
$ sudo dd if=openwrt-x86-squashfs.image of=/dev/<Devicename der CF-Karte, z.B. sdd> bs=16k

• Karte in alix2c0 einstecken, LAN (neben der Strombuchse) und ADSL/VDSL-Modem (neben der seriellen Schnittstelle) anschliessen und alix2c0 booten
  Notfalls serielles Kabel anschliessen, Terminal-Programm mit 38400 8N1 starten, mit "vi /etc/config/network" die IP anpassen und mit "/etc/init.d/network restart" das Netzwerk neu starten
• http://192.168.1.1 User: root Password: <leer lassen>
• Passwort setzen unter: System - Admin Password, Submit
• Rechts oben auf Administration klicken fuer erweiterte Optionen
• Unter System - Software auf "Update package lists" klicken und folgende Pakete installieren: ip6tables radvd kmod-ath5k hostapd
  Mit opkg update; opkg install <paketnamen> im Terminal geht das bedeutend schneller
• Unter Network - Interfaces - LAN die IP anpassen, unter Additional Field "IPv6-Address" hinzufuegen und das eigene IPv6-Netz eintragen (z.B. 2001:DB8:C001:AD51::1/64), Save
• Unter Network - Interfaces - WAN hinzufuegen, User und Password eingeben, "Replace default route", "Use peer DNS und "Enable IPv6 on PPP link" aktivieren.
  Unter Additional Field "Keep-Alive" hinzufuegen und 10 eintragen, Save & Apply
• Falls unter Status - Interfaces - Bridge br-lan keine IPv6-Adresse anzeigt wird, eine Zeile in /etc/ppp/options hinzufuegen:

# vi /etc/ppp/options
+ipv6

• IPv6-Optionen konfigurieren in /etc/sysctrl.conf

# vi /etc/sysctrl.conf

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.autoconf=0                                                                                                     
net.ipv6.conf.all.accept_ra=0                                                                                                    
net.ipv6.conf.default.autoconf=0

• radvd
  konfigurieren (IPv6-Adresse des Gateways im LAN
  announcen)

# vi /etc/config/radvd

config interface
	#option ignore          1

config prefix
	option prefix	'<IPv6-Netz, z.B. 2001:DB8:C001:AD51::/64>'
	#option ignore          1

• radvd aktivieren

# /etc/init.d/radvd enable; /etc/init.d/radvd start

• IPv6-Firewall-Script
  erstellen und konfigurieren

# cd /etc/init.d
# wget http://blog.h2o.ch/files/firewall6

# vi /etc/firewall6.user

#wan interface
UPLINK="ppp0"

#allowed services from wan to lan
TCPSERVICES="22 80"
UDPSERVICES=""

• Firewall
  aktivieren und pruefen

# /etc/init.d/firewall6 enable; /etc/init.d/firewall6 start
# ip6tables -L

• Neu starten unter: System - Reboot und anschliessend pruefen, ob die Clients per IPv4 und IPv6 aufs Netz zugreifen koennen
• Network - Wifi - RADIO0 - Device radio0 - Mode auf 802.11g setzen, unter Additional Field "Country Code" hinzufuegen und den Laendercode (z.B. CH) eintragen.
  Unter Interfaces ESSID waehlen, Network: lan, Mode: Access Point, Encrzyption: WPA2-PSK und unter Key eine Passphrase eintragen, Save & Apply

Wifi einrichten: LuCI - Network - Wifi - Mode: Join (Client) und andere Einstellungen vornehmen

LuCI - Network - General - "Local Network" konfigurieren

/etc/config/wireless

config 'wifi-iface'

option 'network' 'lan'

reboot

opkg install kmod-usb-uhci-iv kmod-usb2 usbutils kmod-usb-printer p910nd

vi /etc/config/p910nd

option device /dev/usb/lp0

/etc/init.d/p910nd start; /etc/init.d/p910nd enable

reboot

http://oldwiki.openwrt.org/OpenWrtDocs%282f%29Kamikaze%282f%29Printers.html

Ich habe bisher den Grafik-Modus nicht zum laufen gebracht. Deshalb beim installieren von Debian bei der Paketauswahl "Desktop Environment" nicht auswaehlen. Auf Debian 6 (Squeeze) am besten mit einer anderen Grafikkarte die Installation durchfuehren und vor dem Austausch der Grafikkarte folgende Anweisungen befolgen:

1) Einloggen, dann su -
2) In /etc/default/console-setup die Variablen FONTFACE und FONTSIZE leeren:
FONTFACE=""
FONTSIZE=""

3) In /etc/default/grub die Variable GRUB_TERMINAL aktivieren (vorangestelltes # entfernen):
GRUB_TERMINAL=console

4) update-grub ausfuehren, um die neuen Grub-Einstellungen zu aktivieren
5) Reboot


Mit Debian 5 (Lenny) konnte man noch mit der Video7-Grafikkarte die Installation durchfuehren, aber spaetestens beim booten des frisch installierten Systems kam es zu Grafikfehlern. Dies kann wie folgt behoben werden:

a) Reboot, dann Grub starten mit Option init=/bin/sh (und vga=0x0f01 fuer 43 Zeilen)
b) Einloggen, dann su -
c) read/write-mounten: mount --> Device von / ermitteln und einbinden mit:  mount -o remount <device> /
d) weiterfahren mit Punkt 2

Das kann von Nutzen sein, wenn der übers Netzwerk per SSH ausgeführte Prozess weiterlauften soll, auch wenn die Verbindung (und damit auch die ausführende Shell) abbricht:

Prozess läuft schon im Vordergrund
1) Ein beliebiger Prozess läuft in der Shell (z.B. "xscreensaver" oder "find / -mtime -1 >/tmp/changedlast24h")
2) Prozess mit [Ctrl]-[z] anhalten
3) Mit "bg" den Prozess in den Hintergrund bringen (als sei der Prozess mit einem angehängten & ausgeführt worden)
4) Mit "disown" wird der Prozess eigenständig und beendet sich auch nach dem schliessen der Shell nicht mehr

Neuer Prozess wird gestartet
1) Shell öffnen und einen beliebigen Prozess im Hintergrund starten (z.B. "xscreensaver &" oder "find / -mtime -1 >/tmp/changedlast24h &")
2) Mit "disown" wird der Prozess eigenständig und beendet sich auch nach dem schliessen der Shell nicht mehr

In beiden Fällen kann man leider den Output der Prozesse nicht anschauen und interagieren ist ebenfalls nicht möglich. Darum ist es besser, nach erfolgreicher SSH-Verbindung mit "screen" eine unabhaengige Shell zu öffnen:

Einsatz von Screen
1) "screen -S test" dem Screen einen Namen geben
2) Prozess starten (z.B. "xscreensaver" oder "find / -mtime -1 >/tmp/changedlast24h")
3) [Ctrl]-[a], d lässt sich die Shell jederzeit disconnecten
4) Shell schliessen, neue Shell (mit dem gleichen User, welcher screen gestartet hat) öffnen
5) Per "screen -r test" wieder reconnecten

Wifi mit Socket Rugged CF 10/100 Card

Treiber entfernen: ipkg remove kernel-module-pcnet-cs

Treiber installieren: kernel-module-axnet-cs für Kernel 2.6.24

Wireless Konfig

vi /etc/network/interfaces

iface wlan0 inet dhcp
    wpa-conf /etc/wpa_supplicant.conf
    wpa-driver hostap

vi /etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
fast_reauth=1
network={
    ssid="meine-ssid"
    proto=WPA2
    pairwise=TKIP
    psk="mein-passwort"
    priority=1

GPRS Config

ipkg update; ipkg install gpe-bluetooth

vi /etc/bluetooth/rfcomm.conf (nokia telefon hinzufügen)

rfcomm0 {
    # Automatically bind the device at startup
    bind yes;

    # Bluetooth address of the device
    device nokias-bt-adresse;

    # RFCOMM channel for the connection
    channel    1;

    # Description of the connection
    comment "nokia";
}

diverse pppd-konfigurationsdateien und gprs-startscript speichern

nokia mit zaurus paaren:

passkey-agent --default mein-PIN

anschliessend im gui-tool beide geräte paaren und dabei mein-PIN eingeben.

GPRS mit startgprs_nokia.sh starten, Verbindung beenden mit "killall pppd".

USB Serial Adapter

Treiber installieren: kernel-module-mct-u232 für Kernel 2.6.24

echo >/etc/modules/ohci-hcd "ohci-hcd"; update-modules

vi /etc/default/usb-gadget

USB_MODE="host-mode"

Reboot & z.B. minicom installieren und /dev/ttyUSB0 nutzen

Socket Cordless Serial Adapter

vi /etc/bluetooth/rfcomm.conf (serial adapter hinzufügen)

rfcomm1 {
    # Automatically bind the device at startup
    bind no;

    # Bluetooth address of the device
    device serial-adapters-bt-adresse;

    # RFCOMM channel for the connection
    channel    1;

    # Description of the connection
    comment "socket cordless serial adapter";
}

z.B. minicom installieren und /dev/ttyUSB0 nutzen

1a) Kompilierumgebung erstellen

#!/bin/sh

# file: /data/OE-install

# http://www.angstrom-distribution.org/building-angstrom

# http://developer.berlios.de/projects/bitbake/

# http://oe.linuxtogo.org/snapshots/

mkdir -p /data/OE/build

cd /data/OE

wget http://download.berlios.de/bitbake/bitbake-1.8.10.tar.gz

wget http://wiki.openembedded.net/snapshots/OE.mtn.bz2

tar zxf /data/OE/bitbake-1.8.10.tar.gz 

bunzip2 /data/OE/OE.mtn.bz2 

mtn --db=/data/OE/OE.mtn pull monotone.openembedded.org org.openembedded.{stable,dev}

mtn --db=/data/OE/OE.mtn checkout --branch=org.openembedded.stable

 

 

 

1b) Kompilierumgebung aktualisieren

#!/bin/sh

# file: /data/OE-update

# update oe metadata

cd /data/OE/org.openembedded.stable

mtn pull monotone.openembedded.org org.openembedded.{stable,dev}

mtn update

 

 

 

2) Environment vorbereiten

#!/bin/sh

# file: /data/OE-setupenv

 BBPATH=/data/OE/:/data/OE/build/:/data/OE/org.openembedded.stable/

 PKGDIR=/data/OE/build/ 

 DL_DIR=/data/OE/downloads

 echo Setting up dev env for ??ngstr??m

 if [ -z ${ORG_PATH} ]

 then

  ORG_PATH=${PATH}

   export ORG_PATH

   fi

  if [ -z ${ORG_LD_LIBRARY_PATH} ]

  then

   ORG_LD_LIBRARY_PATH=${LD_LIBRARY_PATH}

    export ORG_LD_LIBRARY_PATH

        fi

        PATH=/data/OE/bitbake-1.8.10/bin:${ORG_PATH}

        cd $PKGDIR

        LD_LIBRARY_PATH=

        export PATH LD_LIBRARY_PATH BBPATH

        export LANG=C

        echo "Altered environment for OE Development"

 

 

 

3) Konfiguration

# file: /data/OE/org.openembedded.stable/conf/local.conf

#

# OpenEmbedded local configuration file (sample)

#

# Please visit the Wiki at http://openembedded.org/ for more info.

#

#

# Be SURE to read this file in its entirety and the GettingStarted page on the

# wiki before proceeding.

#

# Once you have done that, remove the line at the end of this

# file and build away.

# 

# WARNING: lines starting with a space (' ') will result in parse failures.

# Remove '# ' from commented lines to activate them.

#

# NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you.  If you

# must have paths relative to your homedir use ${HOME} (note the {}'s there

# you MUST have them for the variable expansion to be done by BitBake).  Your

# paths should all be absolute paths (They should all start with a / after

# expansion.  Stuff like starting with ${HOME} or ${TOPDIR} is ok).



# Use this to specify where BitBake should place the downloaded sources into

DL_DIR = "/data/OE/sources"



# Delete the line below. Then specify which .bb files to consider for

# your build. Typically this will be something like BBFILES = "/path/to/openembedded/packages/*/.bb"

BBFILES := "/data/OE/org.openembedded.stable/packages/*/.bb"



# Use the BBMASK below to instruct BitBake to NOT consider some .bb files

# This is a regulary expression, so be sure to get your parenthesis balanced.

BBMASK = ""



# Uncomment this if you want to use a prebuilt toolchain. You will need to

# provide packages for toolchain and additional libraries yourself. You also

# have to set PATH in your environment to make sure BitBake finds additional binaries.

# Note: You will definitely need to say:

#     ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95"

# to build any of two Linux 2.4 Embedix kernels,

# i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget

# to rename the binaries as instructed in the Wiki.

# ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc"



# Select between multiple alternative providers, if more than one is eligible.

PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"

PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"

PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"

PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"

PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"



# Uncomment this to specify where BitBake should create its temporary files.

# Note that a full build of everything in OpenEmbedded will take GigaBytes of hard

# disk space, so make sure to free enough space. The default TMPDIR is

# <build directory>/tmp

# Don't use symlinks in in the path to avoid problems

# TMPDIR = /usr/local/projects/oetmp



# Uncomment this to specify a machine to build for. See the conf directory

# for machines currently known to OpenEmbedded. This will automatically take care

# of TARGET_ARCH

MACHINE = "akita"



# Use this to specify the target architecture. Note that this is only

# needed when building for a machine not known to OpenEmbedded. Better use

# the MACHINE attribute (see above)

# TARGET_ARCH = "arm"



# Use this to specify the target operating system.  The default is "linux",

# for a normal linux system with glibc. Set this to "linux-uclibc" if you want

# to build a uclibc based system.

# Normally the DISTRO of your choosing will take care of this 

# TARGET_OS = "linux"

# TARGET_OS = "linux-uclibc"



# Uncomment this to select a distribution policy. See the conf directory

# for distributions currently known to OpenEmbedded.

# Although it no longer contain version number in the (file-)name

# openzaurus-unstable is a so called "versioned"  distro, i.e. they 

# explicitely select specific versions of various packages.

# Stay away from unversioned distros unless you really know what you are doing

#DISTRO = "angstrom-2007.1"

DISTRO = "angstrom-2007.12-r18"



# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION

# to generate binary locale packages at build time using qemu-native and

# thereby guarantee i18n support on all devices. If your build breaks on 

# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that

# this breaks i18n on devices with less than 128MB RAM) or installing

# a working third-party qemu (e.g. provided by your distribution) and

# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party

# qemus lack patches needed to work with various OE targets.

# ENABLE_BINARY_LOCALE_GENERATION = "0"

# ASSUME_PROVIDED += "qemu-native"



# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales

# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge

# time-savior for developmental builds. Format: list of locale.encoding pairs

# with spaces as separators.

# GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8"



# Uncomment this to select a particular major kernel version if the MACHINE setting

# supports more than one major kernel version. Currently this is suported by the

# following MACHINE types: poodle, tosa and simpad.

# MACHINE_KERNEL_VERSION = "2.6"



# Uncomment one of these to build packages during the build process.

# This is done automatically if you set DISTRO (see above)

# INHERIT = "package_ipk"

# INHERIT = "package_tar"



# Add the required image file system types below. Valid are 

# jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz)

# squashfs, squashfs-lzma

IMAGE_FSTYPES = "jffs2 tar.gz"



# Uncomment this to disable the parse cache (not recommended).

# CACHE = ""



# Uncomment this if you want BitBake to emit debugging output

# BBDEBUG = "yes"



# Uncomment these two if you want BitBake to build images useful for debugging. 

# Note that INHIBIT_PACKAGE_STRIP needs a package format to be defined.

# Also note that OE now produces -dbg packages which contain debugging symbols.

# DEBUG_BUILD = "1"

# INHIBIT_PACKAGE_STRIP = "1"



# Uncomment these to build a package such that you can use gprof to profile it.

# NOTE: This will only work with 'linux' targets, not

# 'linux-uclibc', as uClibc doesn't provide the necessary

# object files.  Also, don't build glibc itself with these

# flags, or it'll fail to build.

#

# PROFILE_OPTIMIZATION = "-pg"

# SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}"

# LDFLAGS =+ "-pg"



# Uncomment this to enable parallel make.

# This allows make to spawn mutliple processes to take advantage of multiple 

# processors. Useful on SMP machines. This may break some packages - we're

# in the process of marking these so let us know if you find any.

# PARALLEL_MAKE = "-j 4"



# Uncomment this if you want BitBake to emit the log if a build fails.

BBINCLUDELOGS = "yes"



# Specifies a location to search for pre-generated tarballs when fetching

# a cvs:// URI. Outcomment this, if you always want to pull directly from CVS.

#CVS_TARBALL_STASH = ""



# EDIT THIS FILE and then remove the line below before using!

#REMOVE_THIS_LINE:="${@bb.fatal('Read the comments in your conf/local.conf')}"

4) axnet-Treiber patchen
cd /data/OE/org.openembedded.stable/packages/linux/linux-rp-2.6.24/

wget http://blog.h2o.ch/files/axnet_cs.patch
vi /data/OE/org.openembedded.stable/packages/linux/linux-rp_2.6.24.bb (zeile hinzufügen)
"file://axnet_cs.patch;patch=1;status=hack "
5) Kompilieren
#!/bin/sh

# file: /data/OE-build

source /OE-setupenv

cd /data/OE/org.openembedded.stable

mtn pull ; mtn update

# bitbake x11-image 

cd /data/OE/org.openembedded.stable/tmp/deploy/glibc/images/akita/

#cd /data/OE/org.openembedded.stable/tmp/deploy/glibc/ipk/akita/kernel-module-axnet-cs_2.6.24-r9_akita.ipk

Dateien sicher löschen

Beim überschreiben von Daten können (z.B. durch ungenaue Schreibkopf-Positionierung) alte Daten in den Randbereichen zwischen den Tracks zurückbleiben. Dadurch, dass nicht überall alte Daten zurückbleiben und weil in diesen Randbereichen die Fehlerrate hoch ist, wird man dort keine oder nur geringe Datenmengen retten können. Solche Datenrettungsversuche sind sehr aufwändig und koennen auch nicht durch Spezialfirmen in nützlicher Zeit durchgeführt werden. Das einmalige Überschreiben mit echten Zufallsdaten sollte also in den meisten Fällen ausreichen. Wer mehr Sicherheit wünscht, kann das Überschreiben beliebig oft wiederholen. Die Gutmann-Methode [1], welche 35 Mal mit bestimmten Mustern überschreibt, halte ich für übertrieben und durch den hohen Zeitaufwand nicht praktikabel. Eine Datei ein Mal komplett mit Zufallsdaten zu überschreiben geht z.B. mit: srm -vll <Datei>

Bei Filesystemen mit Journaling reicht es eventuell nicht, eine Datei zu überschreiben. In diesem Fall ist es besser, die Datei normal zu löschen und anschliessend den freien Speicher auf der Festplatte komplett zu überschreiben. Den freien Speicher ein Mal zufällig überschreiben geht z.B. mit: sfill -vll <Pfad>

Unter Debian/Ubuntu sind srm und sfill im Paket secure-delete zu finden.

Wie komplex Festplatten heutzutage aufgebaut sind, wie die Daten aufbereitet und auf die Disks geschrieben werden und welche Möglichkeiten zur Datenrettung bestehen, kann man unter [2] nachlesen.


Daten auf Festplatten sicher entsorgen / löschen

Wer sicher gehen will, dass die Daten auf einer Festplatte unwiderruflich vernichtet werden, sollte die Festplatte physikalisch beschädigen: Die Festplatte öffnen, alle Plattenoberflächen zerkratzen und die Platten verbiegen oder noch sicherer: Die Platten mit geeignetem Gerät zerkleinern. Wem dies zu aufwändig ist, kann von oben Löscher in die ungeöffnete Festplatte bohren, wo sich die Platten befinden.

Das entfernen der Steuerplatine reicht nicht, da die Datenrettung durch den Austausch der Steuerplatine aus der selben Serie zum Erfolg führen kann. Jede Festplatte weist unterschiedliche Parameter auf, aber sie werden beim Burn-In ermittelt und mit der Firmware auf die Platte geschrieben.

Wer die Festplatte weiterverwenden und nur löschen will, sollte die Festplatte mit einem geeigneten Programm überschreiben, z.B. mit DBAN [3].


Quellen:
[1] http://www.nber.org/sys-admin/overwritten-data-guttman.html
[2] http://www.actionfront.com/whitepaper/Drive-Independent%20Data%20Recovery%20Ver14Alrs.pdf
[3] http://www.dban.org/

Die Parameter muessen gesetzt werden, nachdem das IPv6-Modul geladen ist, aber bevor das Interface gestartet wird. Dies kann man so bewerkstelligen:

• In /etc/network/interfaces :

iface eth0 inet6 static
  pre-up modprobe ipv6
  up echo 0 > /proc/sys/net/ipv6/conf/eth0/autoconf
  (...)