openssl x509 -inform DER -in portswigger.cer -out portswigger.pem

Per intercettare con Burp, le richieste Flutter/Dart da un App Android

Il formato DER, del certificato esportato da Burp, è stato sviluppato prima del formato PEM e è ancora utilizzato in alcuni contesti, specialmente quando è necessario rappresentare i dati in forma binaria in modo efficiente, come nei certificati digitali. Tuttavia, il formato PEM è diventato più popolare grazie alla sua leggibilità e alla sua capacità di memorizzare più tipi di dati in un formato più flessibile e interoperabile.

openssl x509 -inform PEM -subject_hash_old -in portswigger.pem | head -1
mv portswigger.pem 9a5ba575.0

Il comando OpenSSL viene utilizzato per ottenere l'hash del nome del certificato e poi il certificato stesso viene rinominato in modo specifico e spostato nella cartella di sistema del dispositivo Android per garantire che venga correttamente riconosciuto e utilizzato dal sistema operativo.

./adb remount
./adb push 9a5ba575.0 /system/etc/security/cacerts/
./adb shell chmod 664 /system/etc/security/cacerts/9a5ba575.0
./adb shell settings put global http_proxy 127.0.0.1:3333
./adb shell settings put global https_proxy 127.0.0.1:3333

Vengono settati i proxy globali del dispositivo Android sul loopback porta 3333 del dispositivo.

./adb reverse tcp:3333 tcp:8080

La sintassi ./adb reverse tcp:3333 tcp:8080 è utilizzata con Android Debug Bridge (ADB) per mappare una porta del dispositivo (guest) su una porta del computer host (ospitante). In particolare:

tcp:3333 si riferisce alla porta sul dispositivo Android.
tcp:8080 si riferisce alla porta sul computer host.

Quindi, quando esegui questo comando, stai istruendo ADB a instradare il traffico dalla porta 3333 del dispositivo Android alla porta 8080 del computer host-

./adb shell
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:3333
iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:3333

questi comandi sono utilizzati per redirigere il traffico HTTP (porta 80) e HTTPS (porta 443) proveniente dal sistema locale (o da un'applicazione sul sistema) verso una porta specifica (nel caso specifico la porta 3333 sul loopback).

andiamo ad impostare firmware_dir nel file firmadyne.config per puntare alla directory di questo repository.

scarichiamo un'immagine del firmware, ad esempio v2.0.3 per netgear wnap320.

wget www.downloads.netgear.com/files/GDC...ion%202.0.3.zip

utilizziamo l'estrattore per recuperare solo il filesystem, senza il kernel (-nk), senza operazioni parallele (-np), popolando la tabella delle immagini nel server sql 127.0.0.1 (-sql) con il marchio netgear (-b), e memorizziamo il tarball in images.

./sources/extractor/extractor.py -b netgear -sql 127.0.0.1 -np -nk "wnap320 firmware version 2.0.3.zip" images

identifichiamo l'architettura del firmware 1 e memorizziamo il risultato nella tabella delle immagini del database.

./scripts/getarch.sh ./images/1.tar.gz

carichiamo i contenuti del filesystem per il firmware 1 nel database, popolando le tabelle object e object_to_image.

./scripts/tar2db.py -i 1 -f ./images/1.tar.gz

creiamo l'immagine disco qemu per il firmware 1.

sudo ./scripts/makeimage.sh 1

inferiamo la configurazione di rete per il firmware 1. i messaggi del kernel vengono loggati in

./scratch/1/qemu.initial.serial.log.
./scripts/infernetwork.sh 1

emuliamo il firmware 1 con la configurazione di rete inferita. questo modificherà la configurazione del sistema host creando un dispositivo tap e aggiungendo una route.

./scratch/1/run.sh

il sistema dovrebbe essere disponibile sulla rete ed essere pronto per l'analisi. i messaggi del kernel vengono loggati in

./scratch/1/qemu.final.serial.log.

il filesystem per il firmware 1 può essere montato e smontato da scratch/1/image con

./scripts/mount.sh 1 e ./scripts/umount.sh 1

./analyses/snmpwalk.sh 192.168.0.100
./analyses/webaccess.py 1 192.168.0.100 log.txt
mkdir exploits; ./analyses/runexploits.py -t 192.168.0.100 -o exploits/exploit -e x (richiede metasploit framework)
sudo nmap -o -sv 192.168.0.10

MashUp: Bz Akira Santjago
Music: HCF (Bz Akira Santjago)

Questo MashUp videomusicale, nasce dal tentativo di Mashuppare la mia parte Hacker (maschile) con la mia parte Artista (femminile), il Reverse Engineer con il Mashupper/Compositore. É più che un tentativo, è uno dei MashUp più importanti della mia vita.

A chi non apprezza quello che creo e non apprezza la mia musica e ci tiene tanto a farmelo sapere, ricordo che non cerco applausi. Come direbbe Dario Fo, il mio clima psicologico è sempre stato ed è, rimane.. il gioco, l'esplorazione. Riguardo gli applausi, citerei Mogol/Battisti, in Nessun Dolore (canzone che dovrei dedicare a tante persone/troppe, anche rimanendo solo nell'ambito della semplice amicizia). La citazione comunque è questa:

"L'applauso per sentirsi importante
Senza domandarsi per quale gente"

"Immagina di essere all'interno di una gabbia: essa può essere enorme, immensa, di miliardi di chilometri quadrati, oppure stretta pochi metri. Ma il tuo potere su te stesso resta identicamente assoluto: solo tu puoi decidere cosa fare o non fare, non importa quanto larga, o stretta, sia la tua gabbia. Se poi inserisci le interazioni nel quadro, ecco che ciò che decidi di essere e fare influenza inevitabilmente tutto ciò che hai intorno. Come esempio pratico: nei lager c'erano prigionieri che diventavano ostili e approfittatori verso altri prigionieri, peggiorando la loro condizioni di vita. Altri prigionieri invece si aiutavano a vicenda, pur nei margini minimi di cui erano capaci. Gli uni e gli altri creavano, attorno a sé, diversi contesti con diverse probabilità di sopravvivenza. Persino in una condizione miserevole come quella, creavano condizioni di vita per se stessi migliori o peggiori" Stefano Re

Halt and Catch Fire, indicato con la sigla mnemonica di HCF, è un'istruzione fittizia del linguaggio assembly - intesa prevalentemente come uno scherzo - che è stata usata per definire istruzioni solitamente non documentate che portano la CPU in uno stato da cui può essere fatta uscire solo con un reset.

Solitamente con la sigla HCF si descrive una o più istruzioni non documentate presenti in molte architetture e utilizzate per poter effettuare agevolmente particolari test durante lo sviluppo dei prodotti, ma che non sono da utilizzarsi nella normale operatività.

Analisi Statica e Comandi Generici

?: mostra l'help, può essere usato dopo un comando qualsiasi, esempio : dc?
?*...: tutti i comandi
s: stampa l'indirizzo corrente
s addr/funzione: si posiziona all'indirizzo o alla funzione specificati
pdf: disassembla la funzione corrente
pdfs: disassembla la funzione corrente e produce un sommario
ie: mostra gli entry point possibili
iS: lista delle sezioni
aa/aaa/aaaa: analizza le funzioni con diversi livelli di dettaglio
afl: lista le funzioni (ha bisogno che venga prima eseguito il comando aa)
iz/izz: lista delle stringhe nelle sezioni dati (la sezione .rodata per esempio) e nell'intero binario rispettivamente (izz produce molto rumore)
ii: lista delle funzioni importate dalle librerie
is: lista dei simboli
/, /w, /w, /a: cerca una stringa specifica, una wide string, stringa esadecimale, espressione regolare, assembly opcode, rispettivamente
dr: mostra i registri e il loro contenuto o lo modifica
px o pd: stampa hexdump o disassembla, rispettivamente, per esempio pd 5 @eip stampa 5 linee di disassemblato a partire dal program counter corrente

Visula Mode

?: help
V: entra in modalità visuale
!: Panel mode
p/P: passa avanti e indietro tra i diversi print mode (hex, disasm, debug..)
/: evidenzia visivamente uno specifico valore
:: permette di inserire uno specifico comando
1-9: segue le call o le jmp con i corrispondenti shortcut number in un commento
.: si posiziona sul program counter corrente (istruzione corrente)
c: abilita e disabilita il cursor mode, che permette una navigazione più dettagliata. Nel debug print mode è possibile muovere il cursore tra le finestre usando il tasto Tab
o: cambia la visualizzazione dell'assembler
g: cerca per uno specifico offset
u/U: cancella la ricerca o cerca di nuovo
b: mostra un menù con tutta una serie di entries tipo funzioni, simboli, commenti, xrefs, flags e ti permette di visualizzare le informazioni in base all'entry scelta

binwalk, uno strumento utilizzato per l'analisi e l'estrazione di dati da file binari, come immagini di firmware, archivi, file eseguibili, ecc. Ecco cosa fa questo comando in particolare:

binwalk -eM firmware.img

-e: Questa opzione indica a binwalk di estrarre i dati rilevati. Quando binwalk trova dati incorporati all'interno del file, li estrae in una directory separata.

-M, --matryoshka: Questa opzione permette di scansionare in modo ricorsivo i file estratti. Quando viene utilizzata insieme all'opzione -e, binwalk non si ferma alla prima estrazione dei dati, ma esegue una scansione ricorsiva su tutti i file estratti, cercando ulteriori dati incorporati o nascosti all'interno di essi. Questo può essere utile nel caso in cui i dati estratti contengano ulteriori informazioni o risorse da esaminare.

Quindi, l'utilizzo del comando binwalk -eM nomefile.img con l'opzione -M abilitata consentirebbe a binwalk di estrarre i dati dal file immagine e poi esaminare in modo ricorsivo i dati estratti per ulteriori informazioni.

Quando binwalk rileva un filesystem squashfs all'interno di un file immagine, di solito estrae il filesystem squashfs in una directory chiamata "squashfs-root". Questo è un comportamento comune per binwalk quando si tratta di file immagine che contengono un filesystem squashfs.

Quindi, se il file immagine contiene un filesystem squashfs, dopo l'esecuzione del comando binwalk -e nomefile.img, binwalk estrarrà il filesystem squashfs nella directory "squashfs-root" all'interno della directory corrente, e al suo interno troverai tutti i file e le directory presenti nel filesystem squashfs. Questo ti permetterà di esaminare e lavorare con il contenuto del filesystem squashfs. Il comando:

./firmwalker.sh ./squashfs-root

lo script "firmwalker.sh" e lo esegue sulla directory "squashfs-root", utilizzando il contenuto di questa directory come input per l'analisi o le operazioni definite nello script.

È uno script sviluppato per l'analisi dei firmware, in particolare per eseguire una serie di controlli di sicurezza e per individuare potenziali vulnerabilità o problemi di sicurezza nei firmware. Firmwalker esegue una serie di controlli automatici su file, directory e metadati all'interno di un firmware al fine di identificare possibili rischi per la sicurezza.

Ecco alcuni dei controlli che firmwalker può eseguire:

Analisi dei permessi dei file: Verifica i permessi dei file all'interno del firmware per identificare possibili problemi di sicurezza.

Ricerca di parole chiave e stringhe sensibili: Cerca parole chiave o stringhe sensibili all'interno dei file per individ...

Read the whole post...

Sottostante all'interfaccia utente di un artefatto o di un programma si trova la conoscenza di coloro che lo hanno creato. La forma esterna, il guscio, che ostacola il nostro accesso diretto agli ingranaggi meccanici ed elettronici, non è quindi solo uno strato protettivo. Costituisce anche una barriera di protezione da occhi indiscreti: il funzionamento interno dell'artefatto non dovrebbe essere affare nostro. Quando la tecnologia ci è nascosta, manifestandosi solo come "design" o come un insieme di controlli, siamo mantenuti a distanza. Siamo esclusi dalla conoscenza arcana degli ingegneri e programmatori che pulsa all'interno dell'artefatto. E quando sono necessarie riparazioni o modifiche, siamo relegati al servizio clienti e agli specialisti. Solo loro hanno il legittimo diritto di aprire, controllare e riparare i nostri strumenti, gadget e apparecchi. Nella misura in cui non siamo in grado di comprendere il funzionamento interno dei nostri strumenti, siamo anche dipendenti: dagli strumenti stessi e dalla struttura eteronoma che è stata eretta per la loro manutenzione.

Il contrario è espresso dal "Reverse Engineering": è la richiesta, la pretesa degli utenti di poter aprire, esplorare, modificare secondo i propri requisiti, espandere e sviluppare nuove caratteristiche e adattare ogni cosa al sempre mutabile quadro tecnologico. Solo in questo modo non siamo più confrontati con i nostri mezzi di produzione e riproduzione come sistemi completi e chiusi (segregati). Acquisiamo e ci appropriamo così della tecnologia con cui (dobbiamo) vivere e lavorare, a cui siamo riferiti, che plasma la nostra vita quotidiana e che ci costituisce come esseri che possiamo essere nell'ambito delle nostre possibilità tecnologiche.

Questo MashUp VideoMusicale contiene Pubblicità Occulta;

Akira smonta le cose;

La natura aveva maledetto Akira Pepper (Dr. Pepper), regalandogli una curiosità incontenibile, che sembrava crescere in modo esponenziale col passare degli anni. Tuttavia quel dono/maledizione era stato almeno mitigato dalla benedizione di due mani e una mente abili abbastanza da soddisfare la sua ossessione, il più delle volte.

Akira, soprannominato Peperu, viveva per capire il modo in cui le cose funzionavano e per fare questo c'era solo un sistema: smontarle. Non c'era stato un solo oggetto veramente al sicuro dal giovane Akira e della sua cassetta degli attrezzi. Erano arrivati gli strumenti elettronici e per anni le sue prede erano state stereo, registratori, cassette, computer e infine codici. Li aveva smontati e li aveva rimessi insieme.

Ben presto la sua curiosità aveva ripreso ad agitarsi come un leone in gabbia. Era stato allora che aveva scoperto come smontare le astrazioni e rimetterle insieme incastrandole su basi musicali da lui composte per creare così nuove astrazioni. Un vero paradiso per un hacker dell'astrazione.

Il "Reverse Engineering" è l'esigenza, la pretesa da parte degli utenti di poter aprire, esplorare, modificare la tecnologia (e non solo), secondo le proprie esigenze, ampliare e quindi sviluppare nuove caratteristiche per adattare ogni cosa al quadro tecnologico, che è sempre in evoluzione. È esplorazione in tempo reale oltre le possibilità ordinarie; è REBOP!

Il Reverse Engineering è la base dell'Hacking.