martedì 29 gennaio 2013

Hackerato il sito dell'aeroporto di lamezia terme

Il sito dell'aeroporto di Lamezia Terme è stato appena defacciato da un gruppo di hacker iracheni. Ovviamente hanno prontamente reso offline il sito (www.sacal.it) e che tutt'ora resta offline. Ho salvato un screenshoot per voi, eccolo:

mercoledì 1 agosto 2012

CANON EOS 1100D, UFRAW E ARCHLINUX: "You must have automake-1.5 or higher"

Salve gente, oggi vi parlo di ufraw. Da poco mi hanno regalato una Canon EOS 1100D. Visto che attualmente sto utilizzando ArchLinux mi sono posto il problema di leggere il classico formato raw prodotto dalla mia macchina. Ho installato gimp e poi il plugin ufraw, ma mi sono accorto, leggendo le news di ufraw, che attualmente non c'è il supporto per la canon 1100D a meno di installare la versione cvs. Così ho scaricato il pacchetto da AUR e ho lanciato la compilazione, ma dopo poco ecco l'errore:
You must have automake-1.5 or higher
La soluzione al problema è molto semplice basta aprire il PKGBUILD e sostituire le stringhe:
automake-1.11 automake-1.10 aclocal-1.11 aclocal-1.10
con:
automake automake aclocal acloca
Lanciate di nuovo il comando:
makepkg -si
ed ecco che la compilazione andrà a buon fine. Per quelli più pigri allego sia il PKGBUILD modificato che il pacchetto finale che è per 64 bit (mi dispiace per quelli a 32 bit ma il mio sistema è 64 bit, comunque potete sempre scaricare il PKGBUILD e lanciare makepkg -si) Ora potete finalmente leggere il formato RAW della canon EOS 1100D anche su linux. Alla prossima... Ecco il PKGBUILD: http://minus.com/lFDB4l1hUNvAV Ecco il pacchetto: http://minus.com/lbbclgUOAanpEw P.S.: Se i link vanno offline e vi servono contattatemi, invierò tramite email... fino a quando non verrà aggiornato su archlinux oppure sarà aggiornato ufraw...

venerdì 16 settembre 2011

TOMTOM ALLA RIBALTA........

Chi ha comprato recentemente un dispositivo tomtom (tipo il via 115) ha scoperto che non è più possibile collegare il tomtom normalmente al pc e vedere cosa c'è al suo interno come se fosse un disco usb. Fin ora tutti i dispositivi tomtom avevano un sistema operativo proprietario ed era possibile leggere il tomtom come un disco fisso usb. Da ora, invece la tomtom ha deciso di montare sui propri dispositivi un sistema operativo Linux e quindi di fatto ha abbandonato il filesystem fat32. Oggi ho avuto tra le mani un dispositivo del genere e non ho potuto fare a meno di incuriosirmi. La domanda che mi sono fatto è: "Come fa la tomtom ad aggiornare i dati sul dispositivo?". Così ho collegato il dispositivo al pc con il cavo usb in dotazione e sullo screen del tomtom mi è comparso un avviso che mi diceva di collegarmi al sito tomtom per aggiornare il dispositivo. Io ovviamente sono andato a leggere il log del mio sistema Linux ed ho visto che il dispositivo veniva letto come periferica di rete. Ho dato un lsusb -v ed ho notato che effettivamente il sistema operativo sul pc era proprio Linux. Così ho dato il comando:
ifconfig -a

ed ho notato che è comparso un nuovo dispositivo di rete denominato usb0. Allora mi sono chiesto forse il dispositivo funzionerà come server http. Così ho dato il comando:
dhcpcd usb0

ed ecco che mi è stato assegnato l'ip dal server 169.254.255.1 che appunto è il mio dispositivo tomtom. Il prossimo passo è stato quello di scoprire quale porte erano attive sul fantomatico server e quindi ho dato il comando:
nmap 169.254.255.1

E qui la scoperat di due porte aperte una http e un'altra ssh. Ovviamente ho provato la strada più facile ed ho aperto il browser facendolo puntare all'indirizzo 169.254.255.1 e da qui l'errore, in pratica il web server mi nega le pagine disponibili (me lo aspettavo, sarebbe stato troppo facile). Allora indago ancora e provo la connessione ssh da terminale dando il comando:
ssh root@169.254.255.1

e da qui l'amara sorpresa che blocca ogni altra strada:
Permission denied (publickey).

Quindi è chiaro che la tomtom aggiorna il proprio dispositivo attraverso il protocollo ssh. L'unica cosa che rimane da fare per ottenere qualcos'altro e sniffare il traffico di connessione ssh tra tomtom e il pc...ma questa è un'altra storia....a presto!

mercoledì 22 giugno 2011

T.A.R.: Tutorial Arduino Relè

Oggi vi presento un tutorial che vi permetterà di utilizzare attraverso un piccolo circuito un relè con arduino, visto che in giro non ho trovato nulla in lingua italiana che lo spiegasse davvero bene.

MATERIALE NECESSARIO:
- Arduino (in questo tutorial utilizzeremo Arduino UNO ma va bene uno qualsiasi);
- Un transistore (in questo tutorial utilizzeremo un BC547B npn ma va bene un qualsiasi transistore npn basta calcolare l'oppurtuna resistenza poi vedremo come);
- Un resistore (in questo tutorial ne utilizzo 3 per ottenere la resistenza desiderata);
- Un diodo (in questo tutorial utilizzo 1N4007 ma si può utilizzare un 1N4004 oppure un qualsiasi altro diodo a secondo della vostra necessità);
- Un relè (in questo tutorial utilizzo un relè a 5V dc in maniera da alimentarlo con arduino, la sigla del relè è HFD41);
- Un buzzer (opzionale l'utilizzo per far emettere un suono quando il relè si eccita)

DESCRIZIONE:
Utilizzando un uscita digitale di arduino andiamo ad alimentare attravjavascript:void(0)erso la base il transistore BC547B. Il BC547B (transistore, da ora in poi lo chiamo bjt) deve essere utilizzato come interruttore il che vuol dire che deve funzionare in regione di saturazione. Al collettore del bjt va collegato il relè e l'emettitore deve andare a massa. Infine all'altro capo del relè mettiamo l'alimentazione di 5V che preveleremo comunque da arduino. Infine per cortocircuitare la corrente derivante dalla tensione di induzione nel momento di spegnimento del relè usiamo un diodo in parallelo al relè. Lo schema che ho appena descritto è questo:



ANALISI FUNZIONAMENTO:
Il funzionamento di questo circuito è davvero semplice. Quando il bjt è in regione di interdizione e cioè il pin 13 di arduino è nello stato LOW allora un terminale del relè si troverà a VCC=5V e l'altro sarà appeso perché il bjt è off quindi il relè non varierà il suo stato (quindi non chiuderà il contatto e quindi il buzzer sarà aperto e non emetterà suoni). Appena il pin 13 di arduino viene impostato a HIGH allora il bjt andrà in regione di saturazione e quindi lo possiamo assumere come un circuito chiuso e quindi un terminale del relè sarà a VCC=5V (prelevabile da arduino) mentre un altro sarà a massa allora in questo caso il relè varierà il suo stato (cioè chiuderà il contatto facendo emettere un suono al buzzer);

CALCOLO DEI PARAMETRI:
Ora non ci resta che calcolare i parametri del circuito. Visto la semplicità del circuito dobbiamo calcolare semplicemente la resistenza sulla base del bjt. Per fare ciò applichiamo la legge di Kirchhoff per la tensione alla maglia perccorsa dal pin 13 dell'arduino verso massa passando dalla base-emettitore del bjt (e sapendo che il pin 13 di arduino quando si trova sullo stato di high emette una tensione di circa 5V), quindi guardando la figura possiamo scrivere:

PIN13-Vr-Vbe=0

dove:
- PIN13 è la tensione sul pin 13 dell'arduino quando è HIGH cioè 5 V
- Vr è la tensione sul resistore che possiamo anche scrivere come R*I e I la conosciamo perché è la corrente che scorre nella base e leggendo dal datasheet del BC547B ci accorgiamo che la corrente di base affinchè il bjt sia in saturazione deve essere 0,0005 Ampere e quindi I=0,0005 Ampere
- Vbe è la tensione base-emettitore del transistore, leggendo il datasheet del BC547B capiamo che il bjt in regione di saturazione ha una Vbe=0,7 Volt

quindi riscrivendo possiamo affermare che:
R*I=PIN13-Vbe

e quindi calcoliamo la resistenza come:
R=(PIN13-Vbe)/I=(5-0,7)/0,0005=8600 Ohm

Quindi ora siccome personalmente non ho una resistenza da 8600 Ohm combino tre resistenze una da 10KOhm in parallelo con quella da 4,7KOhm e tutto in serie con una da 4,7KOhm che mi da una resistenza finale di circa 7,8KOhm. Ora anche se è più bassa di 8,6KOhm di circa un MegaOhm comunque mi assicura una corrente nella base leggermente superiore a 0,5mAmpere e quindi sono sicuro che sarà in saturazione.

COLLEGAMENTO DEL RELÈ:
Non potevo non descrivere il funzionamento del relè. Il mio relè è un HFD41 a 5 V DC. Prendendo il datasheet possiamo osservare come è fatto internamente il nostro relè:



Questa è una vista da sotto come possiamo capire dalla scritta. Quindi vediamo che il relè presenta un contatto normalmente aperto e che va a chiudere quando è eccitato. Quindi i terminali centrali vanno collegati rispettivamente uno al collettore del bjt e uno all'alimentazione di 5V mentre uno qualsiasi dei terminali a sinistra guardando la foto va collegato al pin 12 dell'arduino e l'altro terminale in alto a destra guardando la foto va collegato al positivo del buzzer. Infine giusto per completezza il negativo del buzzer va collegato a massa (questo lo si può vedere dallo schema circuitale postato a inizio pagina).

CODICE ARDUINO:
Infine per concludere eccovi lo sketch che deve andare caricato su arduino:
void setup(){
pinMode(13,OUTPUT); // viene settato il pin 13 come uscita
pinMode(0,OUTPUT); // viene settato il pin 0 come uscita
digitalWrite(0,HIGH); // viene posto il pin 0 a livello alto perché deve far suonare il buzzer
}

void loop(){
digitalWrite(13,HIGH); // mette il pin 13 a livello alto facendo andare il bjt in saturazione
// ed eccitando il relè e facendo suonare il buzzer
delay(100); // attende 1 millisecondo
digitalWrite(13,LOW); // pone il pin 13 a livello basso spegnendo il bjt e spegnendo il relè
delay(5000); // attende 5 secondi e poi il ciclo si ripete
}


Eccovi alcune foto che riguardano il montaggio dei componenti sulla breadboard:





Ecco un video del funzionamento, purtroppo senza audio (accontentatevi...):


Infine ecco il link ai datasheet:
relè HFD41
BC547

Con questo è tutto, ci sentiamo alla prossima!
Se avete qualche domanda non esitate!

venerdì 17 dicembre 2010

Password e disassemblatori

Vediamo oggi come disassemblare un programma e trovare le informazioni che ci interessano. Per lo scopo potremmo utilizzare un qualsiasi software commerciale ma per ovvie ragioni legali, decido di realizzare un piccolo programma in c. Quindi realizzeremo un programma in c che richieda una password e poi cercheremo di scoprire quest'utlima attraverso la via del reversing. Il sorgente del nostro programma sarà il seguente:

#include <stdio.h>
#include <stdlib.h>

int main(int argc,char *argv[]){
char password[11]={"3fs8dr12JW"},pwd[11];
int i=0,comp=-1;
do{
printf("Per accedere al programma devi inserire una password:\n");
gets(pwd);
comp=strcmp(password,pwd);
if(comp==0){
printf("PASSWORD CORRETTA\n");
}else{
printf("PASSWORD SBAGLIATA\n");
}
i++;
}while(i<3 && comp!=0);
if(comp!=0)
printf("Password sbagliata per tre volte di seguito! Uscita forzata!");
else
printf("Accesso consentito!");
system("PAUSE");
return 0;
}

Il programma chiede una password per avviarsi che può essere sbagliata per massimo 3 volte dopodichè esce. Ora vediamo come ottenere la password di questo programma utilizzando un'altra strada. Innanzitutto abbiamo bisogno di uno strumento importantissimo: il debugger. Il debugger che utilizzerò in questo esempio è ollydbg. Apriamo questo programma e apriamo il nostro file eseguibile:

Come vedete siamo fermi sul cosidetto entry point (cioè da dove parte il programma) con indirizzo 00401220. Ora se scorriamo un pò più giu il nostro programma notiamo qualcosa di veramente interessante, infatti:

sulla riga con indirizzo 004012BA troviamo la nostra password salvata in chiaro. E quindi come avete visto abbiamo scoperto la password! Analizziamo innanzitutto qual è stata la negligenza del programmatore. In questo caso abbiamo salvato la password in chiaro in una variabile di nome password che altro non era che un vettore di char, ovviamente un programmatore serio non l'avrebbe mai fatto, perché tutte le variabili vengono salvate in una zona della memoria direttamente accessibile in fase d'esecuzione. Ovviamente questo piccolo articolo non è esaustivo e completo (anche perché manca una bella parte teorica, che ho volutamente scordato per farvi entrare nell'immediatezza del processo) perché si potrebbe parlare per ore sul cracking. Però è sconvolgente notare che una miriade di programmi rilasciati come trial seguono questa procedura e quindi è veramente facile individuare il seriale...a voi le belle cose...
Concludo postando due programmi uno uguale a quello che abbiamo visto e un altro un pò più difficile, aspetto che mi mandiate le password tramite email...vediamo chi ci riesce.... :D Ciao a tutti...

P.S.:
Per quanto riguarda il primo è del tutto simile a quello che abbiamo visto. Per il secondo per scoprire la password dovrete faticare un pò, dovete eseguire il programma attraverso ollydbg (tasto f9) ma priva dovete porre un breakpoint sul punto giusto. Un breakpoint altro non è che un interruzione del programma, attraverso esso potete vedere i valori delle variabili correnti e motlo di più...Per mettere un breakpoint posizionatevi su di un indirizzo (riga) e premete F2 vedrete che la parte sinistra si colora di rosso, questo sta ad indicare che avete messo un breakpoint e quando il programma arrivera su quel punto si metterà in pausa. Ecco i programmi:

Programma semplice

Programma un pò più difficile

domenica 14 novembre 2010

Driver rtl8187 new release

Non installate i driver di aircrack-ng! Il produttore e cioè realtek ha deciso di rilasciare i driver rtl8187. Li ho trovati sul sito del produttore e le cose sono davvero cambiate ora la scheda è paragonabile ad una atheros o simili, i driver di realtek sono proprio una bomba!! Ora è tardi per postare una guida ma al più presto mi farò vivo per il momento l'unica cosa che vi posso dire è di non installare niente e di aspettare...
Saluti...

Driver rtl8187

Vediamo come compilare e installare i driver patchati di aircrack-ng per abilitare l'injection e migliorare la comunicazione sulla scheda wifi con chipset rtl8187. Un pò di tempo fa ho comprato un antenna wifi esterna usb con chipset rtl8187. Un ottima antenna non c'è che dire! Ha solo una pecca, i driver per linux non sono efficienti come quelli di windows. Inserisco l'usb e vedo che in realtà con linux la scheda viene riconosciuta, quindi penso di non dover far altro che dare i comandi per la connessione. Avvio il terminale e mi connetto alla mia rete wifi (da premettere che precedentemente la scheda wifi interna del mio notebook non vede proprio la rete mentre la scheda esterna mi da una percentuale del 75% quindi un buon guadagno!) Nei primi cinque minuti la connessione è una bomba quindi penso veramente di aver risolto il problema, ma.....ad un certo punto il computer si rallenta e a stento riesco a muovere la freccia del mouse. Allora termino il programma wpa_supplicant e il computer si riprende. Capisco che il malfunzionamento è da attribuire ai driver della mia scheda! Allora comincio a navigare e finisco sulla pagina di aircrack-ng il quale afferma di aver patchato i driver rtl8187 e quindi penso che installandoli non solo migliorerei i driver ma anche l'injection (cercate su internet per chi non sa cosa significa). Quindi prendo la decisione di compilare i driver di aircrack. Leggendo dal sito vedo che la suite aircrack-ng comprende un tool che si chiama aridriver-ng che dovrebbe compilare e installare i driver automaticamente, quindi scarico dal repository l'ultima versione di aircrack-ng e l'installo. A questo punto cerco compilare i driver con il comando
airdriver-ng compile 35

Quel 35 si riferisce ad una lista di aircrack dove 35 sta per Realtek rtl8187. A questo punto questo comando scarica dal sito i sorgenti dei driver applica qualche patch e comincia a compilare. Dopo neanche un secondo dalla scritta
Compiling the source...

ottengo un errore e per capire di che errore si tratta vado a leggere il log in /var/log/airdriver. Da qui vedo che l'errore è dovuto ad una voce che nei nuovi kernel da 2.6.31 è cambiata di nome, cercando su internet e per evitare di sostituire la stringa a mano in ogni file riesco a trovare una patch (non ricordo il sito, ma chiunque ne ha bisogno può contattarmi gilela fornirò via mail!) che fa il lavoro sporco per me. Copio questa patch nella cartella /usr/src/drivers se non esiste createla! Ora però ho il problema di come applicare la patch. Scopro che il file airdriver-ng in realtà è uno script bash. Allora apro la shell e do il comando:
vim /usr/sbin/airdriver-ng

mi studio un pò lo script e riesco a capire in quale punto andare a modificare. Mi posiziono sulla riga 2424 (dovrebbe esserci un fi) e inserisco una nuova linea in cui scrivo:
cd /usr/src/drivers/rtl8187_linux_26.1010.0622.2006/
patch -p1 < /usr/src/drivers/rtl8187-ng-2.6.31.patch
cd -

Salvo il file chiudo e ridò il comando "airdriver-ng compile 35" ed ecco di nuovo un altro errore, rileggo il log e capisco che l'errore è dovuto alle voci
#include asm/io.h
#include asm/semaphore.h

Questi file ovviamente non sono presenti nella cartella asm! Allora riapro il file airdriver-ng e aggiungo ancora altre righe tra le prime due righe che ho inserito prima e il comando "cd-". Il file finale avrà queste righe aggiunte in prossimità della riga 2425 dopo del "fi":
cd /usr/src/drivers/rtl8187_linux_26.1010.0622.2006/
patch -p1 < /usr/src/drivers/rtl8187-ng-2.6.31.patch
sed -s 's/asm\/io.h/linux\/io.h/' beta-8187/r8187.h > beta-8187/r8187mod
sed -s 's/asm\/semaphore.h/linux\/semaphore.h/' beta-8187/r8187mod > beta-8187/r8187mod2
rm -rf beta-8187/r8187.h beta-8187/r8187mod
mv beta-8187/r8187mod2 beta-8187/r8187.h
cd -

Salvo il file e chiudo! ridò il comando:
airdriver-ng compile 35

e finalmente vedo il mio driver compilato!!!
Allora contento di ciò do il comando finale:
airdriver-ng install 35

E il modulo mi viene installato, l'utlimo passo per utilizzare il driver di aircrack è rimuovere il driver di default del kernel, che verrà caricato comunque ad ogni riavvio del pinguino, e caricare il driver patchato di aircrack-ng tramite i comandi:
modprobe -r rtl8187
modprobe r8187

Se vedete che la vostra scheda va meglio, balcklistate il driver rtl8187 così ad ogni riavvio non sarà caricato! Spero che questo post sia comprensibile!
Ciao a tutti...alla prossima!