Skip to content

Events display

Jump to bottom
Tomasz Klim edited this page Jan 10, 2022 · 28 revisions

Mobile Badger is designed to run in full headless mode (without monitor, and without auto-logging on local console).

However, there is a way to control its activities - it supports various LED/LCD displays:

Device model(s) Installing Notes
Adafruit PiTFT 2.2/2.8 inch LCD manual framebuffer-based
BakeBit NanoHat OLED manual for NanoPi NEO/NEO2, not Raspberry Pi
BlinkStick Strip manual USB instead of GPIO; our recommended device
Pimoroni Blinkt! manual our recommended device
Pimoroni Scroll HAT Mini manual
Uctronics 3.5 inch Touchscreen manual framebuffer-based; avoid it
Waveshare 1.44inch LCD display HAT manual
Waveshare True color RGB LED HAT manual

Here you will find a repository containing the current list of drivers, along with their documentation.

The idea

Data exfiltration takes time, especially when run on relatively slow device, instead on a normal computer. Therefore it is crucial to know, what is actually happening with this device:

  • was the attached target drive properly recognized?
  • was the user drive properly recognized and decrypted?
  • is the exfiltration still running, or already finished?
  • any other important events?

The easiest way to handle this, especially in the field use, is to use simple LED interface, that will show such event using multiple LED colors, eg.:

Slots

While there multiple different display devices supported, where each of them has completely different capatilibies, there is a common idea of slots. Each device needs to display from 8 to 10 slots, counted from 0 to 7/8/9, where each slot is represented as:

  • multi-color LED pixel
  • LED column in a matrix LED display
  • text row on LCD display
  • any other method, that can show at least 6 states (including off)

For all currently supported devices, slot 0 means the first LED pixel or first text row.

Each driver has its own module that translates events generated by Mobile Badger to physical capabilities of the device. For example, for Waveshare True color RGB LED HAT it looks:

$events = array (
    "shutdown"                => array(-1, "off"),
    "ready"                   => array(0, "yellow"),
    "target_ready"            => array(0, "green"),
    "target_disconnected"     => array(0, "yellow"),
    "media_device_detected"   => array(7, "green"),
    "media_device_processed"  => array(7, "off"),
    "operation_started"       => array(-2, "green"),
    "operation_finished"      => array(-2, "off"),
);

Where the color names of particular LED pixels are also translated to color codes:

$colors = array (
    "off"    => array(  0,   0,   0),
    "red"    => array(255,   0,   0),
    "green"  => array(  0, 255,   0),
    "blue"   => array(  0,   0, 255),
    "orange" => array(255,  30,   0),
    "yellow" => array(255,  70,   0),
    "purple" => array(255,   0, 255),
    "white"  => array(255, 255, 255),
);

Global, per-device and per-partition events

There are exactly 8 types of events, from which half of them are global (mapped to slot 0), while the other half are related to exfiltrated devices - where slot number is mapped to device and partition number. Thanks to it, a simple 8 LED display can simultaneously show stages of up to 7 parallel operations.

Global events (slot 0):

  • shutdown - turn of all display, disable all LED pixels etc., depending on device type
  • ready - Mobile Badger device is ready to work after boot
  • target_ready - target drive was connected, recognized and mounted
  • target_disconnected - target drive was disconnected, fallback drive will be used

Per-device events (always last slot):

  • media_device_detected - MTP/PTP device was detected, and its exfiltration is about to start
  • media_device_processed - MTP/PTP exfiltration is done

Per-partition events (slots 1 to 7..9):

  • operation_started - hard drive was detected, and its exfiltration is about to start; each partition gets its own event, eg. /dev/sdb1 is mapped to slot 1, /dev/sdb2 mapped to slot 2 and so on
  • operation_finished - partition exfiltration is done

This way, if you connect a modern Windows drive with many hidden/recovery/reserved partitions, you will always properly see, which operations are done, and which are still in progress.

Technical aspects

Connectors and compatibility

Mobile Badger supports 3 types of connectors:

GPIO for Raspberry Pi:
  • 40-pin connector, placed along the top edge of the board
  • includes 3 different interfaces: I2C, SPI and UART
  • compatible with all Raspberry Pi models since B+, and with various clones (unfortunately except NanoPi)
  • most supported display devices use this connector
  • Raspberry Pi boards are sold in 2 version: with or without soldered GPIO connector (pay attention, which version you're buying)
GPIO for NanoPi NEO/NEO2:
  • 24-pin connector
  • similar idea to GPIO connector for Raspberry Pi, but not compatible
  • compatible only at Python level, using RPi.GPIO library (NanoPi has a dedicated version)
  • currently used only by BakeBit NanoHat OLED device, integrated with recommended NanoPi-NEO2 board
USB:

  • currently supports only BlinkStick Strip devices, but driver can be easily adapted to other BlinkStick models

  • main advantage of USB displays is the possibility of (dis)connecting them during work - so the operator can change display device during exfiltration in progress (eg. from mobile display, to bigger display integrated in car dashboard)

Native and framebuffer-based drivers

Większość wyświetlaczy jest sterowana natywnie, tj. program sterujący bezpośrednio "każe" wyświetlaczowi np. zapalić konkretną diodę LED na konkretną składową kolorów, albo narysować jakąś figurę geometryczną (w tym literę/cyfrę) na wyświetlaczu LCD.

Natomiast niektóre wyświetlacze oparte są na koncepcji bufora ramki obrazu (ang. framebuffer) - innymi słowy, działają jako monitor, pokazujący obraz z wyjścia HDMI. Wyświetlacze takie - zwłaszcza modele obsługujące dodatkowo dotyk, albo chociaż mające dodatkowe przyciski - są świetnym rozwiązaniem dla tzw. kiosków interaktywnych (biletomatów, interfejsów do zamawiania jedzenia w lokalach typu McDonald itp.). Natomiast mają one jedną zasadniczą wadę: system musi działać w trybie graficznym, z automatycznym logowaniem domyślnego użytkownika po starcie systemu i automatycznym startem aplikacji do obsługi kiosku.

Funkcjonariusz Mobilny działa całkiem inaczej: cały system działa w trybie headless, a więc bez żadnego interfejsu graficznego, w maksymalnie okrojonej wersji, a obsługa podłączanych urządzeń odbywa się całkowicie w tle, za pośrednictwem mechanizmu systemd. Przez co wyświetlacze oparte na buforze ramki nie są w stanie normalnie działać.

Dlatego też są obsługiwane w całkiem inny sposób:

  • przy każdej zmianie wyświetlanego obrazu, najpierw odczytywany jest z dysku plik z buforem poprzedniej zawartości
  • zmiana nanoszona jest na ten bufor i ponownie zapisywana do pliku
  • następnie za każdym razem generowany jest nowy obrazek, odwzorowujący całą zawartość ekranu
  • następnie jest on kopiowany z pliku na urządzenie /dev/fb1

Takie podejście jak najbardziej działa, natomiast z oczywistych względów jest mało wydajne i spowalnia działanie Funkcjonariusza Mobilnego. Dlatego raczej odradzamy używanie tego typu wyświetlaczy (jeśli masz do wyboru model natywny).

Co jeśli dysk ma więcej niż 7..9 partycji?

Funkcjonariusz Mobilny obsługuje wyświetlacze mające od 8 do 10 kanałów, z czego kanał 0 jest zarezerwowany dla zdarzeń globalnych - a więc dla zdarzeń per-partycja pozostaje od 7 do 9 kanałów, w tym na ostatnim pokazywane są również zdarzenia związane z urządzeniami MTP i PTP (czyli telefonami, tabletami, aparatami cyfrowymi itp.).

Jeśli podłączony dysk twardy (pen drive itp.) ma więcej niż 7..9 partycji:

  • eksfiltracja wszystkich partycji będzie działać dokładnie tak samo, niezależnie od ich ilości
  • partycje o numerach od 8..10 wzwyż po prostu nie będą w żaden sposób obsługiwane przez wyświetlacz

Co jeśli podłączymy kilka dysków jednocześnie?

Funkcjonariusz Mobilny może eksfiltrować wiele urządzeń typu USB Mass Storage jednocześnie - jedynym ograniczeniem jest fizyczna wydajność urządzenia, do którego są one podłączane.

Natomiast interfejs do obsługi wyświetlaczy obsługuje tylko numery partycji, bez identyfikatorów dysków - więc jeśli podłączysz ich kilka jednocześnie, zdarzenia dotyczące partycji na różnych dyskach "pomieszają się" na wyświetlaczu, co może skutkować wprowadzaniem Cię w błąd co do stanu operacji - np. eksfiltracja partycji 2 na dysku 1 się już zakończyła, więc dioda na kanale 2 zgasła - ale eksfiltracja partycji 2 na dysku 2 nadal trwa i nie jest to w żaden sposób sygnalizowane.

Co jeśli podłączymy kilka urządzeń MTP/PTP jednocześnie?

Funkcjonariusz Mobilny obsługuje wiele jednocześnie podłączonych urządzeń MTP i PTP - przynajmniej teoretycznie, gdyż różne urządzenia w bardzo różny sposób implementują protokoły MTP i PTP, w konsekwencji niektóre urządzenia blokują cały protokół. Niemniej jednak, zawsze możliwe jest jednoczesne podłączenie przynajmniej po jednym urządzeniu obu tych typów.

Natomiast interfejs do obsługi wyświetlaczy obsługuje wszystkie takie urządzenia na jednym (ostatnim dostępnym) kanale - więc jeśli podłączysz ich kilka jednocześnie, zdarzenia dotyczące poszczególnych urządzeń "pomieszają się" na wyświetlaczu, co może skutkować wprowadzaniem Cię w błąd co do stanu operacji.

Podobnie w przypadku jednoczesnej eksfiltracji urządzeń MTP/PTP i dysku twardego mającego od 8..10 partycji wzwyż - zdarzenia "pomieszają się" na wyświetlaczu, natomiast same operacje będą prowadzone bez żadnych komplikacji.

© Copyright 2020-2022 by Tomasz Klim Payload.pl

Clone this wiki locally