Fabio Ruini's blog

Anche i bulgari hanno un anima

Fabio Ruini — Wed, 16 May 2012 16:37:44 +0000

Ho praticamente passato le ultime due settimane della vita ripercorrendo, pagina per pagina, paragrafo per paragrafo, tutte le correzioni che il mio external examiner bulgaro (di nazionalità, nonché di fatto) aveva “suggerito” (eufemismo, ricordiamoci che e’ bulgaro) di apportare alla mia tesi di PhD. Sono arrivato finalmente agli ultimi paragrafetti. E qui, dopo 300 pagine di cazziatoni più o meno giusti e/o sensati, scopro che, si’. Anche un external examiner bulgaro, in fondo in fondo, può avere un’anima. Di più. Puo’ persino avere uno sprizzo di brillantezza. E lasciarmi, mentre parlavo della difficoltà del condurre esperimenti di obstacle avoidance con fixed-wing MAVs nel mondo reale, con una battuta. Umorismo da bulgaro trapiantato in UK, sia inteso. Ma pur sempre una battuta. Accompagnata da una faccina sorridente, qualora non si fosse colto quel pizzico di ironia insito nel gesto.

Mi sono quasi commosso, lo ammetto.

Patient HM: Behind the Brain

Fabio Ruini — Mon, 14 May 2012 22:05:11 +0000

Al Drum Theatre, costola “interna” del Theatre Royal plymouthiano, e’ stato programmato per il prossimo venerdi’ 18 maggio un interessante evento dal titolo Patient HM: Behind the Brain. Il riferimento e’ naturalmente al celebre paziente H.M., al secolo lo statunitense Henry Gustav Molaison, al quale da ragazzo vennero asportati ippocampo, giro paraippocampale ed amigdala con l’intento di guarirlo da una forte forma di epilessia. L’intervento riusci’ alla perfezione e ad Henry l’epilessia scomparve completamente. In compenso sviluppo’ dei disturbi della memoria molto particolari che finirono per catalizzare per decenni l’interesse di psicologi e neuroscienziati. HM era diventato (prendete questa definizione con le pinze) incapace di sviluppare nuove memorie.

A Plymouth andra’ in scena, a partire da domani e per tutta la settimana, 2401 Objects, una rappresentazione teatrale che trae ispirazione proprio dalla storia di HM. E’ in questo contesto che va ad inserirsi l’evento che ho introdotto in apertura di post, il quale consiste in una sessione di Q&A della durata di due ore alla presenza di diversi neuroscienziati britannici, tra cui i nostri del CRNS. Special guest, seppur in collegamento telematico, e’ Jacopo Annese, direttore del The Brain Observatory presso la University of California, San Diego. Lui e’ l’uomo alla guida del team che nel dicembre 2009 seziono’ il cervello di HM, morto un anno prima, ricavandone 2,401 micro-strati ora gelosemente conservati negli archivi del laboratorio e sui quali ancora molti studi verranno effettuati in futuro.

Wireless packet sniffing con Wireshark: un piccolo tutorial per immagini

Fabio Ruini — Tue, 08 May 2012 01:01:32 +0000

Devo ammettere che sono rimasto abbastanza basito dalla scoperta. Sapevo, per sentito dire, che le reti wireless non fossero esattamente il non plus ultra della sicurezza. Ma che fosse così facile intercettare i dati trasmessi via etere, proprio non lo sospettavo. E invece e’ proprio così. Sfogliando la prima quarantina di pagine di BackTrack 5 Wireless Penetration Testing, libro che vi avevo introdotto in un post di qualche giorno fa, ho scoperto che e’ sufficiente un computer equipaggiato con una semplice scheda di rete (ed ovviamente un po’ di software apposito, rigorosamente open source) per intercettare tutto quanto passi attraverso le reti wireless presenti nel range della propria scheda wi-fi. Rimane, ovviamente, il problema relativo al crittaggio dei dati. E’ raro, oggigiorno, ma non impossibile, trovare reti che trasmettano dati in chiaro. Quindi, nella maggior parte dei casi, ciò che si può intercettare con facilita’ sono solo pacchetti crittati. Il che pero’ non allevia particolarmente la gravita’ della situazione, considerato quanti modi ci sono (tratteremo questi in seguito, quando anche il sottoscritto maturerà maggiore esperienza a riguardo) per recuperare le chiavi utilizzate per la crittazione.

Questa premessa per introdurre il post odierno, che consiste in un tutorial per immagini dedicato al packet sniffing su reti wireless. Gli strumenti necessari sono semplicemente Backtrack ed un wireless adapter USB Alfa AWUS036H. Come vi accorgerete, data la semplicita’ della procedura, questa dovrebbe essere facilmente replicabile su altre distribuzioni Linux e con hardware wi-fi differente.

Avviamo il nostro computer in Backtrack, colleghiamo la scheda wi-fi ed apriamo un terminale. Innanzitutto utilizziamo il comando iwconfig per visualizzare l’elenco delle interfacce wireless riconosciute dal sistema. Nel mio caso, come potete vedere nello screenshot qui sotto, troviamo due schede, indicate rispettivamente come wlan0 e wlan1. Controllando le bande di trasmissione supportate riconosciamo che wlan0 e’ la scheda PCI installata nel nostro desktop (la quale supporta le bande b, g ed n), mentre wlan1 e’ l’AWUS036H.

Attiviamo quindi la scheda USB con il semplice comando ifconfig wlan1 up. Se non ci sono stati problemi, lanciando ifconfig dovremmo trovare l’interfaccia wlan1 nell’elenco apparso sullo schermo.

A questo punto dobbiamo raccogliere informazioni aggiuntive riguardo alla rete che vogliamo “sniffare”. Per farlo effettuiamo uno scan di tutte le reti presenti nel range della nostra scheda, utilizzando il comando iwlist wlan1 scanning. Per ogni rete (a patto che questa broadcasti il proprio ESSID) otterremo un elenco di informazioni simile a quello che potete vedere nello screenshot che segue. Le informazioni principali che in questo momento ci servono sono: Address (l’indirizzo MAC dell’access point alla rete bersaglio, anche noto come BSSID) e Channel (il canale wireless sulla quale la rete opera). In questo esempio utilizzeremo come bersaglio la rete chiamata “Wireless Lab”, che lavora sul canale 10 ed e’ associata ad un access point il cui indirizzo MAC e’ 1C:BD:XX:XX:A3:52. Per chi se lo stesse chiedendo, l’access point in questione e’ mio, quindi non sto commettendo alcuna irregolarità.

Facciamo si’ che la nostra scheda wireless si vada ad inserire sullo stesso canale utilizzato dalla rete wireless che intendiamo sniffare. Per fare questo, molto semplicemente, impartiamo il comando: iwconfig wlan1 channel 10. Dando poi un ulteriore iwconfig possiamo controllare se la scheda ha cambiato canale correttamente. Lo screenshot di seguito mostra che la rete e’ ora impostata sulla frequenza 2.457GHz.

Dando un’occhiata alla tabellina che segue otteniamo la conferma che la scheda e’ ora effettivamente impostata sul canale 10.

Per il prossimo step facciamo ricorso al software airmon-ng, appartenente alla suite aircrack-ng. airmon-ng serve per creare un interfaccia di rete virtuale (ma che si appoggia ad una “fisica”) da utilizzare a fini di monitoraggio. Lanciando il comando airmon-ng otteniamo l’elenco delle interfacce wi-fi fisiche che possiamo utilizzare (in questo caso entrambe quelle presenti sulla mia macchina).

Possiamo quindi creare l’interfaccia di monitoraggio (che verra’ chiamata mon0) attraverso l’istruzione airmon-ng start wlan1. L’output dovrebbe essere come segue (salvo che, se non avete processi DHCP attivi, non trovaste ritrovarmi il warning che ho invece incontrato io).

L’interfaccia di monitoraggio appare agli occhi del sistema come un’interfaccia di rete vera e propria, e che come tale viene elencata nel momento in cui si lancia il comando ifconfig.

Ora il più e’ fatto. E’ sufficiente lanciare Wireshark, avviare una cattura sull’interfaccia mon0 et voila. Tutti i pacchetti che passano su reti che lavorano sul canale 10 inizieranno a venire elencati nella finestra del software. Per visualizzare soltanto quanto viaggi sulla rete “Wireless Lab” e’ sufficiente applicare in Wireshark un filtro del tipo (wlan.bssid == 1C:BD:XX:XX:A3:52). Lo screenshot di seguito mostra una serie di pacchetti, tra i quali uno generato nel momento in cui con un mio portatile Mac accedo alla rete wireless in questione.

Questo e’ quanto. Mi preme sottolineare come l’intera procedura sia stata effettuata senza alcun bisogno di connettersi alla rete target, ma semplicemente standocene buoni buoni nel nostro angolino ed intercettando passivamente i pacchetti in trasmissione sull’etere.

Piu’ avanti affronteremo il tema del packet injection, ovvero del come iniettare pacchetti all’interno di una rete (alla quale, ancora, non abbiamo accesso).

A brief history of unmanned flight (part II)

Fabio Ruini — Mon, 07 May 2012 00:37:18 +0000

The rest of the story, since the end of WWII until modern times, has been reviewed by Sullivan [1] from an interesting perspective. Rather than focusing on trends in technical development of pilotless aircraft, Sullivan identified four ideas driving the use of unmanned aerial vehicles in the military. Although recently a strong interest has started to grow within the scientific community also, the military field has always been the most significant source of innovation in pilotless aircraft. Thus, the story of unmanned aerial vehicles is closely linked to military history.

The four drives identified by Sullivan are:

force multiplication: a constant drive in military history responds to the ”do more with less” logic. This does not simply mean providing more ”power” to smaller groups, rather accomplishing more with that group than what could have been done previously;

strategic bombing: started during the Spanish civil war in 1936-39, the practice of strategic bombing became widely accepted (and used) during the second World War, as far as becoming a standard tactic during every following conflict;

better intelligence, search and reconnaissance: since the first battle in history was fought, gathering information on enemy troops and fortifications is considered a dangerous but extremely important task. The importance of intelligence further increased over the last few decades, given the nature of modern warfare scenarios that rarely see two or more conventional armies facing each other on an open battlefield;

battlefield of the future: any military planner’s work focuses on imagining ”the next war”. This consideration alone is enough to justify investigations and financial investments in any sort of cutting edge technology that could be used for military purposes.

What follows is a list of some more detailed examples related to Sullivan’s points.

Concerning force multiplication, the aforementioned Aphrodite project demonstrated the need for more precise application of force during WWII. The recognition of this need, indirectly started a stream of investigations along the direction of cruise missiles, weapons significantly more accurate than air-dropped bombs in hitting en- emy targets located in difficult to reach positions. More accurate weapons means more weapons and this is where the concept of force multiplication comes into play. As Davis said [2]:

”[t]he accuracy and invulnerability to enemy countermeasures achieved [by American researchers] effectively multiplies the number of missiles we [the US] have now on stands.”

In 1946 (unofficially at first), the US Navy started the development of the AIM-9 Sidewinder air-to-air missile, a ”heat-homing rocket” according to the words of William B. McLean. The AIM-4 Falcon, designed by the US Air Force, quickly followed. Time was ready for the introduction of AGM (air-to-ground) missiles, with AGM-45 Shrike and AGM-65 Maverick being two of the most prominent examples of the category. The AGM-28 Hound Dog was the first prototype of a cruise missile¹ instead. Worried by the improvements in SAM (surface-to-air) counter air missile technologies exhibited by the Soviet Union (that could have significantly reduced the impact of a nuclear deterrence mainly based on bombers), American scientists started to investigate alternative carriers for their nuclear warheads. The solution found, consisting in the usage of cruise missiles, subsequently led to the appearance of intercontinental ballistic missiles (ICBMs).

The second point raised by Sullivan concerns strategic bombing. This kind of military operation can be performed nowadays by several different means, employing both manned or unmanned aircraft bombers, as well as missiles with various degrees of autonomy. Roughly three families of tools suitable for this purpose can be identified, each of them with its own advantages and disadvantages: bombers, cruise missiles and ICBMs. Bombers are the most flexible solution, since they are flown directly by a human pilot, but at the same time they are the slowest and the biggest (in terms of size) amongst these tools, thus constituting a relatively easy target for enemies’ air defences. Among those listed here, ICBMs are the most autonomous instrument, as they fly independently from lift-off to target under their own guidance systems. Their effectiveness is extremely high, but on the other hand their programming requires time and must be done well in advance before the mission they are intended to take part in. Cruise missiles guarantee a mix of flexibility (provided by the fact they can be fired from mobile platforms) and effectiveness (in terms of penetration inside the enemy’s airspace), without excelling in any of these two dimensions. The X-45 UCAV², for which the development was started by Boeing in 1998, is a technological attempt to combine the flexibility of a manned aircraft with the penetration and range of an ICBM.

Sullivan then introduces among the drives identified the set of tasks constituted by intelligence, search, and reconnaissance (ISR). Considering that, when not dangerous³, collecting intelligence information is an extremely repetitive and boring task, employing automatic systems (as unmanned aircraft) always seemed to be a natural way to go. Firebee Q-2A, developed by Ryan Aeronautical, was a jet- powered, air-launched, remotely piloted and expendable UAV designed to gather information over hostile areas. Operative since 1951, the Firebee (see Figure 1.6) is the most widely used UAV family in military history. An example of the Firebee’s use is during the Vietnam War. In this conflict, the Firebee aircraft (the model 147 Lighting Bug particularly) flew over 3,400 missions. Its design was improved over time, allowing the aircraft to become increasingly more autonomous in its sorties, not necessarily depending on the C-130 bombers usually used for the deployment. Some of the Firebee models also acquired strike capabilities, as the AQM-34 version, operational since 1976.

Figure 1.6: Ryan Aeronautical AQM-34 Firebee

This trend has not stopped yet. Aiming to ”maintain global awareness” [3], in 1998 the US Air Force took control over the High-Altitude Endurance (HAE) UAV Advanced Concept Technology Demonstration (ACTD) programme⁴, resulting in the development of the Northrop Grumman (the new name for the former Ryan Aeronautical company) Global Hawk UAV. The Global Hawk, one of the most advanced UAVs to date, is an extremely interesting aerial platform, since it provides up to 42 hours of endurance and can operate safely in adverse weather conditions. Its most prominent competitor in terms of popularity is certainly the General Atomics Predator. Although the two aircraft have demonstrated how they can be jointly used in a successful way, the Global Hawk, thanks to its significantly superior capabilities for intelligence operations, has become the default choice for intelligence operations, while the Predator is quickly evolving into a widely appreciated combat vehicle.

Finally, Sullivan mentions the ”battlefield of the future”. As we have seen, UAV technologies emerged from the research into missiles carried out during the First World War. At that time, it was thought that ”flying bombs” or ”aerial torpedoes” would have been main players in the upcoming warfare scenarios. These developments did not result in any practical application until much later though. The same applies to unmanned aircraft. Particularly during the Vietnam War, they demonstrated their efficiency in penetrating dense enemy air defences, but it took long before they became accepted as a standard intelligence/combat tool. Now, thanks to the constant technological march towards smaller components, the research is focused on new classes of miniature UAVs.

Footnotes:

1: We define as cruise missile a ”SSM surface-to-surface guided missile that carries an explosive payload and is propelled, usually by a jet engine, towards a land-based or sea-based target”.
2: ”UCAV” is the acronym for ”Unmanned Combat Aerial Vehicle,” i.e., a UAV with combat capabilities.
3: Both in terms of human and political costs. See for example the issues that arose during the Cuban Missile Crisis.
4: http://www.fas.org/spp/military/docops/defense/actd_mp/HAE.htm

Bibliography:

[1] J.M Sullivan. Evolution or Revolution? The Rise of UAVs. IEEE Technology and Society Magazine, 25(3):43–49, 2006.
[2] L. Davis. Military significance of Draper’s work for the Air Force. In S. Lees, editor, Air Space and Instruments. McGraw-Hill, New York, USA, 1963.
[3] J.M Sullivan. Impediments to and Incentives for Automation in the Air Force. In Proceedings of the ISTAS 2005, the International Symposium on Technology and Society. Weapons and Wires: Prevention and Safety in a Time of Fear, pages 102–110, 2005.

A brief history of unmanned flight (part I)

Fabio Ruini — Sun, 06 May 2012 21:00:13 +0000

Revisionare la propria tesi di PhD significa tante cose. Significa apportare modifiche, significa correggere passaggi sbagliati o comunque ambigui e/o poco chiari, significa aggiungere nuove cose. Ma al tempo stesso significa anche tagliare. Tagliare talvolta interi paragrafi sui quali si sono spese ore e ore del proprio tempo. Normale che dispiaccia premere quel “delete” sulla tastiera. Oggi, mentre stavo per farlo su un paragrafo a mio avviso abbastanza simpatico, mi sono fermato un secondo a riflettere. “Ehi, ma io ho un blog” ho pensato. Come che mi fossi davvero dimenticato, anche solo per una frazione di secondo, di un qualcosa che da oltre 6 anni (a proposito, temo che mi sia sfuggito il compleanno del blog, perdonami caro!) e’ parte integrante della mia routine quotidiana. Ecco allora che ripropongo su queste pagine (diviso in due parti) il paragrafo che questo pomeriggio ha abbandonato ufficialmente la mia tesi.

On 17 December 1903, the Wright brothers, Orville and Wilbur, carried out the first successful heavier-than-air flight test in human history using a powered vehicle. Although they were not the first ones to build and fly experimental aircraft, the Wright brothers were the earliest to invent aircraft controls that made fixed-wing powered flight possible. This was due to the inter-linked roll-yaw control system, extensively tested by the Wright brothers on gliders, carefully described in a recent publication by Padfield and Lawrence [1].

Figure 1.1: The famous picture of Wright brothers’ first flight

Following the Wright brothers’ success, it did not take long for the domain of unmanned flight to emerge. In reviewing the history of the field, Sullivan [2] mentions the Kettering Bug flying bomb (see Figure 1.2), developed by Charles Kettering in 1918, as the first unmanned vehicle flown by the US Army Signal Corps. Kettering’s bug was a gyroscope-controlled flying machine that would fall to earth and explode after the propeller turned a preset number of times. All in all similar to an aircraft, this might also be considered the first missile in military history.

But the Kettering Bug was not an original concept. Four years earlier, in June 1914, Lawrence Sperry¹ [3] – together with his assistant/technician Emil Cachin – carried out a public demonstration of an aircraft (a Curtiss C-2 biplane, as the one depicted in Figure 1.3) whose control surfaces were managed by a rudimentary autopilot system, governed in turn by a gyroscope (a ”Sperry gyroscope”, see Figure 1.4(b)) integrated in the fuselage. The gyroscope was ”merely” measuring the error (angle of deviation) between the desired (stable) attitude of the aircraft and the current one, making the necessary adjustments via simple mechanical devices.

Figure 1.2: Kettering Bug flying bomb

The demonstration took place in France, during the ”Concours de la Securite en Aeroplane”. Sperry and Cachin made their exhibition as impressive as possible, flying several times in front of the reviewing stand, sitting on the wings of the plane, with no one at the cockpit.

Figure 1.3: Curtiss C-2 aircraft

Sperry, inventor of this first autopilot system, quickly became extremely pop- ular, appearing on the front pages of the most important newspapers of the time. Furthermore, despite what was erroneously reported by Sullivan, his research was the inspiration behind the creation of the Kettering Bug as well. The first guided bomb in military history was in fact developed by both Sperry and the automotive inventor Charles Kettering, with external advice provided by James Doolittle. William Scheck’s essay [4] on the development of the autopilot narrates the full story in details.

Figure 1.4: (a) Lawrence Sperry, inventor of the first autopilot system; (b) a Sperry gyroscope

Despite the tremendous success achieved from an engineering perspective, the world was not ready for large-scale unmanned flight. Aircraft were not yet considered a method of mass transportation, instead they were viewed as war or entertainment tools. No obvious benefits were visible in the use of autopilot systems with regard to these two areas. Furthermore, the enthusiastic Lawrence Sperry passed away in December 1923. Without his leadership and feeling the economical pressure exercised by the governments selling the aircraft leftover of WWI, the Sperry Gyroscope Company he was governing in conjunction with his father Elmer (that in the meanwhile managed to develop ”universal” autopilot systems thanks to the widespread introduction of the Deperdussin system [5]) did not survive. As a result, the research into unmanned flight consequently stagnated for a couple of decades.

Eventually, in the early 1940s, Sperry’s innovations acted as starting points for the birth of the missile field. Several prototypes, as the above mentioned Sperry-Kettering Bug, were developed over the years, but was not until the burst of WWII that they became a common asset in the arsenal of the belligerent armies. The research on this area took place in Germany in particular, and brought to the appearance of the Vergeltungswaffe-1 (also known as V-1, see Figure 1.5(a)), the first missile (the type of which would be referred to today as a ”cruise missile”) to be employed in wartime. The V-1 (known among the Britons as ”doodlebug” or ”buzz bomb,” because of its noise) was soon replaced by the technologically impressive V-2 (also known as ”Aggregat-4”, A4, see Figure 1.5(b)). The V-2 was also the first known human artefact to achieve sub-orbital spaceflight.

Figure 1.5: (a) Fieseler Fi 103/Vergeltungswaffe-1 (”vengeance weapon”, V-1); (b) Aggregat-4/Vergeltungswaffe-2 (V-2)

On the Allies side, the only attempt to use unmanned aircraft carried out during the second world war was the highly unsuccessful Operation Aphrodite [6]. Operation Aphrodite attempted to use manned vehicles (namely B-17s and PB4Ys bombers) as unmanned ones. Stripped of their standard equipments and loaded with several tons of explosive instead, the Allies were planning to use them against fortified Axis’ defences, but none of them actually managed to hit their designated target.

Footnotes:

1: Son of Elmer A. Sperry, the inventor of the gyrocompass.

Bibliography:

[1] G.D Padfield and B Lawrence. The Birth of Flight control: An Engineering Analysis of the Wright Brothers’ 1902 Glider. The Aeronautical Journal, (December):697–718, 2003.
[2] J.M Sullivan. Evolution or Revolution? The Rise of UAVs. IEEE Technology and Society Magazine, 25(3):43–49, 2006.
[3] William W. Davenport. Gyro!: The Life and Times of Lawrence Sperry. Scribner Publishing, New York, USA, 1978.
[4] W Scheck. Lawrence Sperry: Genius on Autopilot. Aviation History Magazine, November 2004.
[5] M.J. Abzug and E.E. Larrabee. Airplane Stability and Control: a History of the Technologies that Made Aviation Possible. Cambridge University Press, Cambridge, MA, USA, 2002.
[6] P.W. Kenneth. The Evolution of the Cruise Missile. Air University Press, Maxwell, AL, USA, 1985.

iCub & friends

Fabio Ruini — Fri, 04 May 2012 00:15:51 +0000

Mi sono appena accorto che sul sito web iCub.org (punto di riferimento ufficiale per quanto riguarda il robot in questione) hanno pubblicato un simpatico poster ad effetto mosaico le cui tessere raffigurano i vari personaggi sparsi per il mondo che in qualche modo hanno a che fare con iCub.

Ebbene si’. In alcune di queste immagini appare anche il sottoscritto. Che ha speso buoni cinque minuti prima di riuscire a trovarsi (perdipiu’ in multipla copia!).

Plymouth: polizia e cittadini

Fabio Ruini — Thu, 03 May 2012 22:02:22 +0000

Di rientro da una serata fuori, appena varcata la soglia di casa trovo sul pavimento una busta marrone. Indirizzata, genericamente, agli “occupants”. Apro, ovviamente incuriosito, e cosa trovo al suo interno? Una lettera lasciata da un agente della stazione di polizia locale, che avvisa di un furto che vi e’ stato ai danni di un veicolo parcheggiato nelle vicinanze. Una cosa abbastanza normale, direte voi? Si’, lo e’. Ma fa sempre piacere vedere come, da queste parti, anche “piccoli” reati siano perseguiti con questa serietà. E che si cerchi, sempre e comunque, un dialogo proattivo con il cittadino. Per rendere piu’ agevole il lavoro delle forze dell’ordine e, allo stesso tempo, per rendere piu’ sicura e tranquilla la vita del singolo.

By the way, la notizia vera e’ che la macchina colpita non e’ la mia. Data la nuvoletta fantozziana che in questo 2012 sembra perseguitarmi senza darmi la benché minima tregua, direi che e’ un’ottima notizia.

Windows password hashes, rainbow tables ed Ophcrack

Fabio Ruini — Wed, 02 May 2012 00:52:05 +0000

Nel post di oggi torniamo a trattare di sicurezza informatica. Più nello specifico il tema e’ ancora quello del password cracking, con riferimento specifico, questa volta, ai sistemi Windows.

Prima di iniziare e’ doverosa una veloce parentesi di carattere teorico. I sistemi Windows, quando si tratta di memorizzare le varie password di sistema sul disco di un certo computer, non effettuano questo procedimento “in chiaro”. Per fornire un benché minimo livello di sicurezza, le password sono crittate attraverso una funzione hash. Come ci ricorda Wikipedia:

A cryptographic hash function is a hash function, that is, an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an (accidental or intentional) change to the data will (with very high probability) change the hash value. The data to be encoded is often called the “message,” and the hash value is sometimes called the message digest or simply digest.

Quello che viene memorizzato sul disco della macchina e’ appunto il “digest” della password. Riuscire a “decrittare” l’hash, creato da una one-way function, di una certa stringa di testo e’ un’operazione impossibile, non da un punto di vista teorico (lo spazio delle soluzioni non e’ infinito e, dato un lasso di tempo infinito, e’ possibile riuscire a ricavare la stringa che ha generato un certo hash, a patto che questo non sia salted), quanto meramente pratico (per via dei limiti temporali citati nella parentesi precedente).

Chi si occupa di sicurezza sa che e’ pero’ possibile cercare di aggirare il problema. Siccome gli algoritmi per la creazione di hash utilizzati dai principali sistemi operativi sono noti, e’ possibile cercare di effettuare password cracking calcolando gli hash di un certo set di possibili password e confrontandoli con quelli memorizzati sul computer target. Nello specifico i sistemi Windows si affidano ad uno tra questi due algoritmi: LM (utilizzato fino all’avvento di Windows 2000, fa ricorso a DES) oppure NTLMv2 (in uso nelle versioni più recenti dell’OS di Redmond, si appoggia ad MD4). Un tutorial pubblicato su WindowsSecurity.com (parte 1, parte 2) illustra in maniera chiara e semplice come questi algoritmi funzionino.

Cosa deve fare, dunque, un wannabe cracker alle prese con un sistema Windows? Prima di tutto deve recuperare il SAM file memorizzato sul computer target, solitamente immagazzinato all’interno della directory c:\windows\system32\config\. Bisogna pero’ tener presente che su questo file viene posto un lock all’avvio di Windows, cosa che rende impossibile accedervi una volta che il sistema operativo si e’ avviato. Per riuscirci, la soluzione più semplice consiste nell’avviare la macchina con un sistema operativo differente, come ad esempio una distribuzione Linux live e, magari, appoggiarci a tool come bkhive e SAMDUMP. Il video qui sotto dovrebbe dare un’idea sul come poter utilizzare questi due piccoli software in combinazione tra di loro.

Una volta ottenuta l’hash che stavamo cercando e’ ora di passare al cracking vero e proprio. I tool principali ai quali possiamo fare affidamento sono John the Ripper (multi-piattaforma) e Cain and Abel (per chi volesse svolgere l’operazione dall’interno di un ambiente Windows). Tali strumenti offrono le classifiche funzioni per attacchi brute-force basati su dizionario, insieme ad altre piccole varianti sul tema. Come sappiamo molto bene, un attacco a forza bruta e’ un’operazione che può richiedere tempi estremamente lunghi. In questo caso i tempi sono ulteriormente dilazionati dal fatto che, per ogni possibile password da testare, il software deve generare l’hash corrispondente richiamando un po’ di funzioni matematiche non banali. Un’interessante alternativa che permette di velocizzare enormemente il processo e’ data dagli strumenti che fanno ricorso alle cosiddette Rainbow table, più o meno vasti database di hash pre-computate. Grazie a strumenti come ad esempio l’ottimo Ophcrack presente nei repository di default delle principali distribuzioni Linux, il cracking via rainbow table e’ facile ed immediato.

Alcune rainbow table sono messe a disposizione gratuitamente dagli sviluppatori di Ophcrack e scaricabili a partire da questo link, mentre altre (la maggior parte delle quali a pagamento, tranne alcune piacevoli eccezioni quali ad esempio FreeRainbowTables.com) possono essere reperite in giro per la rete.

Per chi non avesse voglia di sbattersi troppo, nel caso in cui pure le rainbow table dovessero richiedere uno sforzo superiore rispetto a quanto siete disposti ad offrire, esiste una ulteriore alternativa. Quella di far processare una propria hash ad altri. Come ad esempio ai creatori di questo servizio online.

In chiusura di post doveroso segnalare che quello descritto qui sopra non e’ ovviamente l’unico modo possibile per accedere ad un sistema Windows per il quale non siamo in possesso delle credenziali necessarie. Lasciando momentaneamente da parte hacking più complessi, un sistema brutale ma molto efficace quando si ha accesso fisico alla macchina target consiste nell’utilizzo di un tool come Offline Windows Password & Registry Editor, il quale consente di rimpiazzare l’hash memorizzato sul sistema con uno a propria scelta. Attenzione, pero’: nel caso in cui i dati sul disco sono crittati (con la password originale) questa procedura può essere oltremodo dannosa per il sistema target!

Update pokeristici: aprile 2012

Fabio Ruini — Tue, 01 May 2012 14:56:21 +0000

Forse forse dovrei iniziare a farci l’abitudine. E, magari, prima o poi ci riuscirò pure. Fatto sta che in questo 2012 sembra non sia proprio possibile per il sottoscritto riuscire a tirare fuori profit dai tavoli. Per il quarto mese consecutivo chiudo con uno score imbarazzante per quanto riguarda il giocato. E, per il quarto mese consecutivo, a salvarmi sono solo rakeback, classifiche e bonus vari ed assortiti.

Ai tavoli runno infatti nella solita maniera indegna chiudendo con un risultato netto di -€647, per un ROI del -2.66% sui €24,283 complessivamente giocati. Valore alto, quello movimentato, dettato dai 615 HU disputati ad un BI medio di €39.48. La rake generata nel corso del mese supera quota €2,000 e si attesta a €2,121.95. Questo, nonostante mi sia diviso (poco) equamente tra la solita Winga e la mia vecchia conoscenza BetPro, mi permette di mettere in tasca una buona cifra e chiudere cosi’ il mese con un guadagno che, dato l’andamento ai tavoli, e’ sorprendentemente positivo. Sono infatti €515 quelli, tra RB, classifiche e network, che BetPro mi regala. Mentre ancora meglio fa Winga, dove raccolgo €300 grazie alla Rake Race organizzata da PIW, ed ulteriori €600 frutto di 3 secondi posti nelle classifiche SnG settimanali. Alla fine di tutto, il risultato netto e’ quindi di +€768, decisamente dignitoso.

Di seguito trovate i soliti grafici riepilogativi del mese appena trascorso. Si parte con quello relativo all’andamento del profit, che non ha bisogno di molti commenti. Partenza decente, poi orma classica discesona da -€1,400, buona risalita e poi ancora una flessione sul finale.

A seguire il dettaglio giornaliero: -€469 su 45 games la sessione peggiore, +€251 su giusto 11 games (con un impressionante 10W/1L) la più positiva.

Andando a vedere i dati suddivisi per BI notiamo come l’incubo vero sia stato ai €55 turbo: -11% di ROI su 141 games giocati, quando il livello (e questa e’ la cosa veramente tiltante) non e’ praticamente per nulla diverso da quello che si trova ai €35. Dove invece runno decentemente, con un ROI dell’1.25% su 465 games (mai che capiti il contrario).

Prima di chiudere il post doverosa parentesi per il gioco live, al quale mi riaffaccio seppur in maniera non intensa. Durante la mia permanenza in Italia mi concedo un torneino da €50 con gli amici dove non riesco a chiudere a premio. Rientrato a Plymouth mi concedo un’uscita per una serata cash il 23 e concludo la sessione con un ottimo +£265. Passano 3 giorni e, il 26, mi reco al Genting Casino per il £20 rebuy che chiudo in prima posizione per £340 di vincita. Preso dall’euforia, sabato 29 mi tuffo anche nel £25 triple-chance del G Casino ma qui le carte non girano e sono fuori poco dopo il primo break.

Insomma, ridendo e scherzando (ma soprattutto bestemmiando), tra online e live un millino il poker me l’ha regalato anche questo mese. Regalo gradito, tanto più ora che non ho uno stipendio sul quale contare. Che fatica, pero’…

iCub simulator on Mac OS X Lion: the definitive (?) tutorial

Fabio Ruini — Mon, 30 Apr 2012 16:27:35 +0000

This tutorial will describe the various steps required to install YARP and the iCub robot simulator on a 64-bit computer running Mac OS X Lion.

Install GCC and homebrew

Make sure your Mac is running the latest version of OS X Lion (currently 10.7.3)
Install Xcode from the Mac App Store (the current version is 4.3.2)
Open Xcode and install the Command Line Tools, going to Preferences (cmd+,) -> Downloads -> Command Line Tools -> Install
Download and install homebrew issuing the following command in a Terminal window: /usr/bin/ruby -e "$(/usr/bin/curl -fksSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"
Run brew doctor to check whether homebrew is fully functioning already. If not, please follow the instructions provided (most of the time you will simply have to launch a command like sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer)

Install YARP via homebrew

Run the brew install yarp command (other than YARP this will also automatically install several dependencies as ACE and CMake)

Compile and install ODE from the sources

Download the ODE sources (version 0.12) and extract the archive somewhere on your computer (we will refer to this location as $ODE_DIR)
Download premake4 and unzip the binary into $ODE_DIR/build
Download Code::Blocks and install it on your machine
Enter $ODE_DIR (cd $ODE_DIR) and generate a Code::Blocks project for ODE using the command ./premake4 --platform=x64 --os=macosx --no-alloca --all-collis-libs --cc=gcc codeblocks
Open $ODE_DIR/build/ode.cdb in Code::Blocks, select as build target “ReleaseDoubleLib|x64” and build everything
Copy the $ODE_DIR/include/ode folder to /usr/local/include/
Rename $ODE_DIR/libode_double.a to $ODE_DIR/libode.a and copy it to /usr/local/lib/

Compile and install SDL from the sources

Download the SDL sources (version 1.2.15), extract the archive somewhere on your computer (we will refer to this location as $SDL_DIR)
Install the autoconf tools running: brew install autoconf
Pre-configure, compile and install SDL running the following commands in sequence:

cd $SDL_DIR
./autogen.sh
./configure --disable-assembly
make
sudo make install

Copy SDLMain.h and SDLMain.m from $SDL_DIR/Xcode/TemplatesForXcodeSnowLeopard/SDL Application/ to /usr/local/include/SDL/

Install the iCub simulator

Install the Gtk+ C++ interface gtkmm running: brew install gtkmm
Create a directory on your machine which will host the sources of the iCub simulator (we will refer to this location as $ICUB_REPOSITORY)
Enter $ICUB_REPOSITORY and download the latest version of the iCub simulator via SVN, running the command: #svn co https://robotcub.svn.sourceforge.net/svnroot/robotcub/trunk/iCub
Setup some environment variables adding the following lines to your ~/.profile file (replace $ICUB_REPOSITORY with the path of the directory created two steps above):

export ICUB_ROOT="$ICUB_REPOSITORY/iCub"
export ICUB_DIR="$ICUB_REPOSITORY/iCub/main/build"

Close and re-open the Terminal for the changes to the environment variables to be applied;
Run: mkdir $ICUB_DIR
Enter $ICUB_DIR (cd $ICUB_DIR) and run: ccmake ..
Configure the project (‘c‘ key) a few times, setting CMAKE_BUILD_TYPE to “Release” and USE_ODE_DOUBLE to “ON“. When it becomes available, press ‘g‘ to generate a Makefile and exit CMake
Compile the iCub simulator running the make command and install it with: sudo make install
Install the support applications running: sudo make install_applications
Enjoy!

Troubleshooting (compile and install YARP from the sources)

Many things might go wrong following the procedure outlined in this tutorial. One of the most common issues in which you could incur consists in the iCub simulator complaining about an incompatible version of YARP installed on your system. If this the case (and you have installed YARP on your computer via homebrew) you will have to download from the SVN the latest version of YARP and compile it by hand. The procedure for doing that is quite straightforward:

Uninstall the homebrew version of YARP running: brew uninstall yarp
Enter $ICUB_REPOSITORY and download the latest version of YARP via SVN, running the command: svn co https://yarp0.svn.sourceforge.net/svnroot/yarp0/trunk/yarp2
Add two new environment variables to your ~/.profile file:

export YARP_ROOT="$ICUB_REPOSITORY/yarp2"
export YARP_DIR="$ICUB_REPOSITORY/yarp2/build"

Close and re-open the Terminal for the changes to the environment variables to be applied;
Run: mkdir $YARP_DIR
Enter $YARP_DIR (cd $YARP_DIR) and run: ccmake ..
Configure the project (‘c‘ key) a few times, setting CMAKE_BUILD_TYPE to “Release, CREATE_GUIS to “ON“, CREATE_LIB_MATH to “ON“, CREATE_YMANAGER to “ON“, and (if available) CREATE_YMANAGER_GUI to “ON“. When it becomes available, press ‘g‘ to generate a Makefile and exit CMake
Compile YARP running the make command and install it with: sudo make install

For any question and/or feedback feel free to write me, or to post a message on the Robotcub Hackers mailing list.

Thanks, amongst the others, to Martin and Juxi for the work they have done on the subject in the past.

If anyone feels like preparing a PDF file out of the information contained in this tutorial, please give me a shout!