Appunti vari per criptocamere disperate. Quale piattaforma supportare? questo e’ il problema

Le foto

in che qualita’ e’ necessario fare le foto?

Canon CHDK (compatte)

Device supportati

Piu’ o meno tutte le canon point-and-shoot (quindi le compatte). Si trovano abbastanza facilmente abbandonate nei cassetti (specie quelle di qualche anno fa), o si comprano a partire dagli 80 pleuri

Scrittura software

un po’ un casino, bisogna fare un hook sulla filewritetask e dovremmo capire come si fa.
Cose interessanti:

Il codice C e’ abbastanza ordinato, sembra anche semplice inserire alcune funzioni computazionalmente costose direttamente in C, e renderle chiamabili da lua.

Prove fatte

A610

Sulla a610 il firmware 1.2 e l’1.3 funzionano senza problemi, usando la revisione 100e (la 100f non funziona).

Per modificare il firmware ci serve preparare un sistema di build.

Toolchain

OK FUNZIONA

sudo debootstrap jessie criptocamera
cat <<EOF >> jessie/root/.bashrc
export PATH="/bin:/sbin:$PATH"
export PATH="/root/build-dir/arm/toolchain/bin:$PATH"
EOF
sudo chroot criptocamera /bin/bash

da dentro, fate:

aptitude install -y build-essential libmpfr-dev zlib1g-dev subversion zip
cd /root
wget 'http://pappp.net/wp-content/uploads/2013/10/chdk-gcc454.sh' -O maketutto.sh
bash maketutto.sh

svn co https://tools.assembla.com/svn/chdk/trunk chdk
make batch-zip

e quello vi fa TUTTI i firmware. Se volete fare prima fate
make PLATFORM=vostromodello PLATFORMSUB=sottocosa clean fir

tipo per me PLATFORM=a610 PLATFORMSUB=100e

Nota che se invece di fare svn checkout fai git clone di un repo equivalente, pare non funzionare un cazzo

Dentro bin/ vi trovate tutti gli zip pronti per essere messi nella vostra fotocamera

Il codice

C’e’ il github github.com/boyska/chdkripto cha fa gia’ qualcosa:

comunque siamo gia’ contenti

Canon MagicLantern (le reflex)

Device supportati

Le canon che finiscono con la D

Scrittura software

C’e’ gia’ qualcosa:

Android

Device supportati

Tutti gli android, incluse le android-camera

AndroidCamere

costano >= 100 neuri e sono paragonabili a delle compatte e sono riflashabili, rootabili, ecc
nikon coolpix s800c

Scrittura software

Piuttosto semplice. Esempi simili:

Fare SD Emulation

Programmarsi un chippino che si “interfacci” come se fosse SD.
A occhio, e’ un delirio vero.

Pro:

SD WiFi

Molte schede che vengono vendute come “sd+wifi” hanno linux all’interno e hanno parecchi modi per essere hackate in modo semplice. Tipicamente se si mette un autorun.sh sulla scheda SD, quello viene eseguito. Si puo’ anche modificare direttamente l’initramfs, tutto senza dover riflashare ne’ rischio di brickare.

link.autistici.org/bookmarks.php/avana/sd

Pro:

Contro:

Modelli

secondo dei tipi sul forum di openwrt la cosa meglio e’ la pqi, ma le microsd che ti danno incluse fanno un po’ rate, quindi poi magari ce ne metti di meglio.

Cose da fare

Accesso in scrittura

Occhio!
In fondo a quest articolo fanno notare che

FAT32 is not a clustered filesystem and is not safe (will loose data integrity) with concurrent access. There may be
some mechanisms being used by the card to solve this, however I have repeatedly corrupted the filesystem when writing to
it from both SD and OS. I can’t be sure that anything I’m doing will be safe any guarantee data integrity – there is a
risk you could corrupt the SD filesystem and loose all your data.

Quindi servono dei trucchetti per salvare le cose dentro la SD.

Il modo in cui il tutto funziona viene mezzo spiegato anche sul solito forum dove spiegano che c’e’ una sorta di switch sul master, la fotocamera ha priorita’, ma comunque il tutto e’ trasparente. Forse partizionare puo’ essere una soluzione? Su un post pazzesco in cui uno mette firefox su sta roba nei commenti c’e’ un tale Charles che dice che lui ha partizionato per evitare di accavallarsi, e gli e’ andato tutto bene.

curve ellittiche

codice di chdk

Si puo’ provare il vecchio tool scritto per chdkripto. Compila (anche statico), in emulazione funziona, pero’ non legge dai file: gli devi dare il messaggio come argomento!!

blobcrypt

Oppure direttamente blobcrypt: github.com/jedisct1/blobcrypt che dovrebbe gestire gli stream di dati assai meglio

chiavi con pochi uni

Idea presa dalla lista hackmeeting

Usare NTRU

Un tipo ad hackmeeting suggeriva ntru

Esperimenti

Cose fatte sul PQi AirCard:

Toolchain

E’ abbastanza comodo creare una toolchain con buildroot (manuale).
si fa cosi’:

e dentro output/host ti trovi la toolchain. A quel punto quando vuoi usarla fai

export PATH=/per/co/rso/output/host/usr/bin:$PATH
export CC=arm-linux-cc

buildroot

oltre a creare toolchain (vedi sopra) buildroot e’ anche in grado di creare interi sistemi host.

C’e’ questo coso github.com/dankrause/kcard-buildroot che funziona ma e’ fatto per le transcend, e boh alla fine non funziona.

Comunque usando la 2015.05 di buildroot mi funziona.
expat non compila, quindi con make menuconfig lo tolgo (si trova in target packages/libraries/json+xml o qualcosa del genere)

Solo che la root cosi’ creata non riesco ancora a farla bootare (vedi sotto)

cambiare firmware

fino ad ora avevo sempre lavorato sul file autorun.sh che e’ bello pero’ e’ un po’ limitante perche’ comunque ti rimane l’OS “normale” ed e’ difficile buildare cose custom, e’ tutto strippato eccetera. Allora volevo cambiare il tutto. La descrizione del sistema e’ su dmitry.gr/index.php?r=05.Projects&proj=15.%20Transcend%20WiFiSD

The bootloader (u-boot, whose sources Transcend did NOT provide) reads the ramdisk into RAM, reads the kernel into ram, and jumps to it. The sizes are hardcoded in u-boot at 0×300000 bytes (exactly 3MB). This size limitation is rather annoying, since the existing ramdisk is already quite close to the limit, and addinig much more to it will push it over. Removing things from it is also dangerous – since my goal was to not open the card physically, if it does not boot and does not get onto WiFi, there is no way to debug it. Compressing the ramdisk using better compression was not an option either. Their kernel was not built with support for bzip2 or LZMA.

We need a way to flash this thing safely and effectively. Turns out that this job is done for us. The bootloader of the card will detect on boot if four files called “image3”, “initramfs3.gz”, “mtd_jffs2.bin” and “program.bin” exist, and, if so, load and run “program.bin”, which just so happens to be a copy of u-boot (did I meantion that they did not ship the sources?). This u-boot flashes the card’s NOR flash with these three pieces: kernel, ramdisk, and the small jffs2 filesystem. The way the card works is rather curious. Almost all of the code is in the ramdisk, but the size limitation must have bit them too. One library is not: “libcrypto.so.0.9.8” – it did not fit. They unpack it (bunzip2) from the jffs2 filesystem at boot into the RAM. The jffs2 filesystem is also where the settings are stored. This actually explains why flashing new firmware erases the settings – the entire NOR flash partition is overwritten with the new image.

Un’altra cosa importante e’ il commento sul post di hackaday: hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/#comment-1061584
che dice:

Place my files on card. wait 1 min. remove card. reinsert card. wait 6 min (very important). remove card. reinsert card. wait till “wifisd” network shows up. connect to it

Quindi su questa roba bisogna metterci QUATTRO file: bootloader (program.bin) kernel (Image3) robo jffs chissa’ che cazzo e’, e initramfs, che poi in realta’ contiene tipo tuto (initramfs3.gz).

I primi 3 ci starebbero bene cosi’ come sono, ma il quarto vorremmo personalizzarlo.

Solo che in realta’ non funziona mica un cazzo. Il primo avvio e’ molto lento e in effetti fa partire la wifi WIFIV1.6 come dice il commento, di cui non so la passphrase. Aspetto molto, stacco, riattacco, e non parte NULLA.

GPG sul cosariello FUNZIONA (ma va lento)

Finalmente funziona. La toolchain usata (arm-unknown-linux-uclibcgnueabi) e’ stata creata da crootool-ng su archlinux. Seguira’, forse, un metodo per riprodurla.

GPG e’ stato compilato senza particolari magie, solo qualche attenzione. Scaricare gnupg 1.4.19 (cioe’ l’ultima della release 1, anche detta “classic”)

#!/bin/bash

export PATH=~/x-tools/arm-unknown-linux-uclibcgnueabi/bin/:$PATH
export CFLAGS=-static
export CXXFLAGS=-static

make clean
./configure --disable-photo-viewers --disable-ldap \
	--disable-cast5 --disable-blowfish \
	--disable-card-support --disable-agent-support \
	--disable-finger --disable-mailto --disable-dns-srv \
	--disable-gnupg-iconv \
	--disable-dev-random \
	--enable-asm \
	--disable-idea \
	--enable-cast5 \
	--disable-blowfish \
	--enable-aes \
	--enable-twofish \
	--enable-sha256 \
	--enable-sha512 \
	--disable-bzip2 \
	--disable-exec \
	--disable-photo-viewers \
	--disable-keyserver-helpers \
	--disable-ldap \
	--disable-hkp \
	--disable-finger \
	--disable-dns-cert \
	--disable-largefile \
	--build $(gcc -dumpmachine) \
	--host arm-unknown-linux-uclibcgnueabi
make -j all

A questo punto basta copiare il binario g10/gpg e tutto dovrebbe andare. Pero’ gpg rosica un po’ perche’ su quel kernel scemo la fcntl non funziona, e questo provoca delle attese infinite col file random_seed. Il trucco e’ dirgli --no-random-seed-file.

Cosi’ facendo tutto funziona MA per cifrare un file grande 1.4MB ci vogliono tipo 30 secondi. Sospettiamo sia roba di entropia, chi lo sa.

Ottimizzazioni possibili

Cose che forse si fanno facile:

Cose che richiedono cambi piu’ grandi:

Una roba minimale con le NaCL

Repository

Ricicciando codice scritto originariamente per chdk, proviamo a vedere quanto va veloce un programma che cifra a chiave pubblica (ma deterministico, quindi non ci sono i dubbi sull’accesso a /dev/random).

Innanzitutto si noti che la “precomputation” non è troppo utile: essa serve soprattutto se bisogna mandare molti messaggi piccoli allo stesso destinatario, e infatti nel caso di molti file piccoli funziona bene. Ma per cifrare uno (o anche molti) file grandi non serve a molto. Comunque l’ho implementata.

Il tempo di cifratura dipende circa linearmente dalla dimensione del file.

Ottimizzazioni gcc

Le ottimizzazioni di gcc contano molto.

Senza ottimizzazioni, un file da 1.1MB richiede 20 secondi per essere cifrato: troppo.
Con -O2 ci mette 6.5 secondi.
Con -O3 ce ne mette 4.0.

CRISTO CI AMA

Il binario thumb (ottenuto con -mthumb) va più lento di quello arm. Se gli dici la tua architettura precisa
(-mtune, -march, --param l1-cache-size eccetera), non c’è alcun vantaggio, a volte va pure più lento.

Librerie

API più rapide

Rimanendo in tema nacl, è da capire come se la cavano le API crypto_stream_* (che pero’ forse non sono fatte per quello che dobbiamo noi, ma per fare una pnf, quindi boh)

NaCL originali

Inoltre bisognerebbe vedere se le ottimizzazioni fatte dalla NaCl vera (e non da tweetnacl, come facciamo ora) sono effettivamente utili alle performance.
Cross-compilare nacl e’ un po’ un bagno di sangue, perche’ lo script ./do assume in molti punti che l’host e il target coincidano (cioe’, vuole eseguire i binari compilati per misurare quale va piu’ veloce).

Libsodium

Allora ho utilizzato le libsodium, che invece si crosscompilano facile:

CFLAGS=-O3 CPPFLAGS=-O3 ./configure --enable-static --enable-asm --host=arm-linux
make

Purtroppo il make check fallisce, ma credo sia perche’ su quella macchina non posso eseguire binari arm. Settando qemu-user-static e binfmt forse si potrebbe, boh.

Passando a libsodium, il guadagno di performance è ENORME: si arriva a 0.75s per il solito file da 1.1MB!

Inoltre le libsodium hanno alcune API più intriganti (ancora da provare) tipo le sealed boxes; le sealedboxes ogni volta generano una chiave effimera, questo potrebbe sembrare lento ma i benchmark mostrano che la generazione di una chiave porta via solo 0.07 secondi, quindi ok.
Quando si passa a libsodium la differenza di performance la fa la compilazione della libreria, dopodiche’ cambiare le ottimizzazioni del programmino nostro non e’ piu’ importante.

Come smanettarci

Per compilare, vedi la parte sulla cross-toolchain detta più in alto. Io uso la toolchain con uclibc, ma in realtà non so perché lo faccio, forse è meglio musl? forse glibc? chi lo sa!

Per come funziona l’accesso alla memoria, è particolarmente noioso mettere i file nuovi sulla memoria. Cioè diciamo che tu sei loggato in telnet, fai una prova e non va. Sul tuo computer trovi il bug, cambi il file, vuoi copiarlo, come fai? Dopo varie prove ho visto che la cosa meglio è che sul mio computer apro un server http, e dalla shell telnet scarico i file importanti.
Ho fatto questo script chiamato getall, che non è nel Repository

#!/bin/bash

baseurl="http://192.168.1.51:8000"

wget "${baseurl}/getall" -O /mnt/sd/getall
wget "${baseurl}/autorun" -O /mnt/sd/crypta-autorun.sh
wget "${baseurl}/detector/processall" -O /mnt/sd/processall
wget "${baseurl}/cryptapult/cryptapult" -O /mnt/sd/catapult-encrypt

dove 192.168.1.151 e’ l’IP del mio computer. Io prima facevo che dal computer copiavo i file con cp, poi smontavo, montavo sul cazzariello, ma sta cosa non funziona bene, per via probabilmente di cache varie, o mille altre noie. Così vado troppo meglio.