0

Libreboot X200 il notebook certificato dalla Free Software Foundation

La Free Software Foundation ha annunciato la certificazione riguardante il notebook Libreboot X200.

Libreboot X200
Dopo IBM ThinkPad X60 l’azienda inglese The Gluglug ha presentato il nuovo Libreboot X200, personal computer portatile che vanta della certificazione della Free Software Foundation garantendo driver, bios e sistema operativo completamente open source.
Libreboot X200 è una versione modificata di Lenovo ThinkPad X200, notebook robusto grazie a materiali di alta qualità, cerniere rinforzate, tastiera AccuType ( in grado di resistere a polvere e acqua), il famoso dispositivo di puntamento trackpoint ecc.
Con Gluglug Libreboot X200 avremo un notebook con hardware non recente che comunque ci garantisce il completo supporto per le principali distribuzioni Linux (possiamo rimuovere Trisquel ed installare ad esempio Ubuntu, Debian, Fedora ecc).

Continua a leggere…

 

 

0

Marco's Box I/O 46

La classe di cacciatorpedinieri americani Zumwalt è dotata di un centro di missione con software basato su Linux [FoxtrotAlpha]

  • Il CERN dal 2011 ospita un programma di collaborazione fra artisti e scienziati per la creazione di opere ispirate alla ricerca effettuata nel laboratorio [Gizmodo]
  • Sono stati annunciati i vincitori dei premi intermedi del Lunar Xprize, finanziato da Google, che nel 2016 premierà il primo team che manderà con successo un rover sul suolo lunare. [Xprize]
  • Yanis Varoufakis viene nominato ministro delle finanze greco: è stato per tre anni economista capo per Valve (qualcuno ha parlato di cappelli?) [PcGamesN]
  • Arctic Fibre vuole stendere un cavo sottomarino diretto tra Tokyo e Londra passando per lo stretto di Bering [IEEE Spectrum]
  • Youtube elimina definitivamente il player in Flash [Youtube]
  • Il processo a Dread Pirate Roberts, il responsabile di Silk Road, si combatte anche sull’interpretazione da dare alle emoticon nei messaggi [Gizmodo]
  • Un paper americano illustra come con tecniche di machine learning sia possibile attribuire un codice sorgente al relativo autore solo analizzandone lo stile [Gizmodo]
  • In America le connessioni a banda larga verranno definite tali solo con un minimo di 25 megabit in download e 3 megabit in upload [The Verge]

 

 

 

0

Ubuntu 15.04 passa al kernel 3.18.4

Ubuntu-15-04Gli sviluppatori di casa Canonical hanno appena aggiornato il kernel Linux. L’obiettivo? Riuscire ad offrire la release 3.19 agli utenti di Ubuntu 15.04. Ubuntu 15.04 verrà rilasciato negli ultimi giorni del mese di Aprile. Fino ad allora, gli sviluppatori del team di Mark Shuttleworth avranno diverse gatte da pelare: oltre allo sviluppo della prossima release …

 

0

Git e GitHub su Ubuntu: come si crea un repository?

githubTi sei mai chiesto come condividere con l’intera comunità un repository locale? Con questo semplice tutorial scopriremo come fare ad usare Git e GitHub. Vogliamo condividere con il mondo intero il frutto di intere nottate di sviluppo o, più semplicemente, vogliamo dare una mano alla comunità Open Source? Beh, non possiamo di certo non conoscere …

 

0

Nike+ FuelBand SE BLE Protocol Reversed

During the last two weeks I had fun playing with the BLE protocol of the Nike+ FuelBand SE, a device to track daily stesp, calories, time, etc.

nikeband

I’ve completely reversed its protocol and found out the following key points:

  • The authentication system is vulnerable, anyone could connect to your device.
  • The protocol supports direct reading and writing of the device memory, up to 65K of contents.
  • The protocol supports commands that are not supposed to be implemented in a production release ( bootloader mode, device self test, etc ).

I’ve published a proof of concept Android application on github, don’t expect it to be production ready code of course, but it works :)

poc logcat

Why?

Because! I had fun reversing it, I hate closed source hardware protocols, and as long as I know I’m the first one to actually manage to do it, despite many are trying since the first version with no luck.

The question is never why, the question is always how.

fucku

BLE

The Bluetooth Low Energy is a wireless personal area network technology designed and marketed by the Bluetooth Special Interest Group aimed at novel applications in the healthcare, fitness, beacons, security ( LOL, more on this later ), and home entertainment industries. Compared to Classic Bluetooth, Bluetooth Smart is intended to provide considerably reduced power consumption and cost while maintaining a similar communication range.

Basically it’s something that works on the bluetooth frequencies, but has very little in common to the classic bluetooth, mostly because the device protocol must be implemented by each vendor since there isn’t really a standard (yet?).

Each device has its characteristics which basically are read/write channels (thing about them as sockets), while the writing method is only one, there are two modes of reading data, either you perform an active reading or you wait for the onCharacteristicChanged event and get the available data from the read channel.

The annoying part of this technology is synchronization, since read and write operations can not be performed simultaneously, instead each one needs the previous operation to be completed before being scheduled … event programming dudes!

That’s why you will find an event queue and a lot of sinchronization code in my PoC, not my fault :P

How

Fortunately there’s a Nike official Android application that I managed to reverse, since I don’t (actually didn’t, more on this later ) know smali, I used the lame method of converting the APK to a JAR package using the great dex2jar tool and then JD-Gui to easily read the Java source code.

First thing first, the device is detected and recognized by its COMPANYCODE in the advertisment data ( byte[] NIKE_COMPANY_CODE = { 0, 120 } ), then a GATT service discovery is launched.

The main command service UUID is 83cdc410-31dd-11e2-81c1-0800200c9a66 and it has two characteristics:

  • Command Channel (where you write commands) : c7d25540-31dd-11e2-81c1-0800200c9a66
  • Response Channel (where you wait for responses) : d36f33f0-31dd-11e2-81c1-0800200c9a66

You the client attaches to these two channels, it enables notifications on the response one and the authentication procedure starts.

How the Authentication Procedure Theoretically Works

I’m saying theoretically because that’s what some parts of the application suggest it should work, but actually I’ve found out that most of the authentication code is bypassed and some pretty funny constants are used :)

Everything starts with a PIN, a string that “someone” will send you (probably the Nike web api) during the first login/setup with the device, this string is stored inside the XML file /data/data/com.nike.fb/shared_prefs/profilePreferences.xml, in my case its node is:

...
<string name="pin">69AB8DA2-F7D6-497C-869D-493CCF8FE8BC</string>
...

The pin is then hashed with the MD5 function and the first 6 bytes of the resulting hash are converted to hexadecimal, those 6 bytes will become the discovery_token stored in the same file:

...
<string name="discovery_token">5E5E6F7A7FE2</string>
...

Every time the app finds the device and wants to connect with it, it sends the following START AUTHENTICATION command:

0x90 0x0101 0x00 0x00 0x00 ....

0×90 indicates that’s a SESSION command and its bits contains the sequence number, number of total packets in the transaction and packet index ( this is the encoder ).

0×0101 are the bytes indicating the START AUTH command and all the 0×00 are zero bytes padding up to 19 bytes.

Once the app sends this packet, the device replies with a challenge response containing a 16 bytes long nonce buffer.

0xC0 0x11 0x41 0xF495C98693075322225EB8B8A4D79B39
  • 0xC0 Reply opcode ( SESSION protocol, 0 following packets, packet index 0, sequence number 4 ).
  • 0×11 Following data size ( 16 of the nonce + 1 of 0×41 ).
  • 0×41 Auth opcode OPCODE_AUTH_CHALLENGE ( namely: “Hey dude, I’m sending you the nonce! )
  • 0xF495C98693075322225EB8B8A4D79B39 : The nonce itself.

To succesfully authenticate to the device, you need to take this nonce, the previously discussed discovery_token, get a CRC32 of them, truncate it to two bytes and send it back to the device, so the resulting packet would be something like:

0xB0 0x0302 XX XX 0x00 0x00 ........
  • 0xB0 : SESSION protocol, 0 following packets, packet index 0, sequence number 5.
  • 0×0302 : Authentication request opcode.
  • XX XX : The two bytes of the truncated CRC32.
  • 0×00 … : Zero padding up to 19 bytes.

Sounds quite simple yet robust doesn’t it? Since you need both the pin ( which is probably linked to the user account ) and the nonce sent by the device, there’s no way you can remotely connect to a FuelBand unless you have physical access to the owner device or you have hacket his account and used it on your device to force the web api to send you back his pin.

Right? ….. WRONG ! :D

NOTE
Besides what I’m about to write, the device is broadcasting the user discovery_token within its advertisment data ( the MANUDATA field ), so you could sniff it anyway … LOL!

I’ve been stucked a couple of days on this … I implemented everything in the right way, I was using my own discovery_token, succesfully initiated the connection to the device and got the nonce, CRC32′ed them together … and then I got an InvalidParameterException from the class which was computing the CRC32 checksum ( that I copied from the JD-GUI decompilation ) with the message:

Length of data must be a multiple of 4

WTF DUDE?! How could the discovery_token, which is only 6 bytes long, have a size which is divisible by 4?!
So I tried to truncate it to 4 bytes, pad it, hash it … you say it!
Nothing was working.

So I decided that it was the time for me to learn to read and write in Smali ( took me a couple of hours, quite simple actually ).

I decompiled the APK again, this time using apktool to get the smali code, injected some code of mine to make the application log the actual token it was using, recompiled it with apktool, signed it with signapk and reinstalled to my device.

Guess what?

How the Authentication Procedure Really Works

Fuck it, who fucking cares about that token anyway? Let’s just use 0xff 0xff 0xff 0xff 0xff 0xff …. !

facepalm

Yeah … although the code is there and all the mechanism described in the previous section could be robust … they are just using a hard coded token of 0xff 0xff 0xff 0xff 0xff 0xff …. meaning that, anyonce who’s able to get the nonce from the device ( so anyone with a BLE capable Android smarphone since the device itself it’s sending it ) will be able to authenticate against your device and send any command … let me facepalm again ….

So basically here the code to create an authentication packet:

CopperheadCRC32 crc = new CopperheadCRC32();

byte[] auth_token = Utils.hexToBytes("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"); 

/*
 * Create the response packet: 0xb0 0x03 0x02 [2 BYTES OF CRC] 0x00 ...
 */
Packet resp_packet = new Packet(19);

resp_packet.setProtocolLayer( CommandResponseOperation.ProtocolLayer.SESSION );  
resp_packet.setPacketCount(0);  
resp_packet.setPacketIndex(0);  
resp_packet.setSequenceNumber( challenge_packet.getSequenceNumber() + 1 );

ByteBuffer response = ByteBuffer.allocate(18);

response.put( (byte)0x03 );  
response.put( (byte)0x02 );

crc.update(nonce);  
crc.update(auth_token);

short sum = (short)((0xFFFF & crc.getValue()) ^ (0xFFFF & crc.getValue() >>> 16));

response.putShort(sum);

resp_packet.setPayload( response.array() );  

And finally the device will reply with:

0xE0 0x01 0x42 0x00000000000000000000000000000000
  • 0xE0: SESSION layer reply, bla bla bla.
  • 0×01: 1 byte of reply.
  • 0×42: Succesfully authenticated ( FUCK YEAH! )
  • 0×00..: Padding.

Sending Commands

Once you’re succesfully authenticated, you can start sending command, each command has its own encoding standard, but the first three bytes are always:

  • protocol byte: SESSION or COMMAND constants + some bit hacking to set sequence number etc.
  • length byte: Size of the following data.
  • opcode : Code of the command:

Each command ( and its encode ) is implemented inside the class com.nike.nikerf.protocol.impl.NikeProtocolCoder_Copperhead, for instance here’s the redacted implementation of Cmd_GenericMemoryBlock ( yeah -.- ):

private abstract class Cmd_GenericMemoryBlock  
{
    private static final int MAX_ADDRESS = 65536;
    private static final String MSG_ERR1 = "Request packet does not contain all required fields";
    private static final String MSG_ERR2 = "Request fields contain invalid values";
    private static final String MSG_ERR3 = "Transaction already in progress";
    private static final String MSG_ERR4 = "Request does not belong to a transaction";
    private static final String MSG_ERR5 = "Failed to open a transaction";
    private static final String MSG_ERR6 = "Failed to close a transaction";
    private static final String MSG_ERR7 = "I/O failed";
    private static final byte SUBCMD_END_TRANSACTION = 3;
    private static final byte SUBCMD_READ_CHUNK = 0;
    private static final byte SUBCMD_START_READ = 4;
    private static final byte SUBCMD_START_WRITE = 2;
    private static final byte SUBCMD_WRITE_CHUNK = 1;

    ...

    public NikeMessage decode(final NikeTransaction nikeTransaction) throws ProtocolCoderException {
        ... decode a response ...
    }

    public void encode(final NikeTransaction nikeTransaction) throws ProtocolCoderException {
        ... encode this command ...
    }

    byte getOpCode() {
        ...
    }
}

In my proof of concept application you will find the code to create and send CmdSettingsGet commands, retrieving some sample data such as BAND_COLOR, FUEL level, owner FIRST_NAME and device SERIAL_NUMBER.

Commands Lists

  • Cmd_BatteryState: Retrieve battery state.
  • Cmd_Bootloader: Set the device to bootloader mode ( basically it locks down the device, the official app won’t work either … only resetting it with the usb cable will unlock it ).
  • Cmd_DesktopData: ???
  • Cmd_EventLog: Get device event log.
  • Cmd_GenericMemoryBlock: Read or Write a memory address from 0 to 0xFFFF.
  • Cmd_MetricNotificationIntervalUpdate: Set interval time to receive metrics update notifications.
  • Cmd_Notification_Subscribe: Subscribe to the notification of a specific metric.
  • Cmd_ProtocolVersion: Get device protocol version.
  • Cmd_RTC: Configure the device real time clock.
  • Cmd_Reset: Reset the device.
  • Cmd_ResetStatus: Reset the user data.
  • Cmd_SampleStore: Use the device memory to store a custom object (!!!).
  • Cmd_SampleStoreAsync: Same, but async.
  • Cmd_SelfTest: Perform a hardware self test and get the results.
  • Cmd_Session_Ctrl: Login/Logout/Ping
  • Cmd_Settings_Get: Get a setting value by its code.
  • Cmd_Settings_Get_Activity_Stats: Get user activity statistics.
  • Cmd_Settings_Get_Boolean: Get a boolean setting.
  • Cmd_Settings_Get_Int: Get an integer setting.
  • Cmd_Settings_Get_MoveReminder: Get a “move reminder” type setting.
  • Cmd_Settings_Set: Set the value of a setting by its code.
  • Cmd_Settings_Set_MoveReminder: Set a “movie reminder” setting.
  • Cmd_UploadGraphic: Upload a bitmap to show on the device led screen ( a subclass of Cmd_GenericMemoryBlock ).
  • Cmd_UploadGraphicsPack: ???
  • Cmd_Version: Get device firmware version.

Conclusions

Altough the device does not contain sensitive data about the user, this is a good proof of concept on how a badly implemented BLE custom protocol could lead an attacker to compromise a device ( such as the BLE proximity sensor of an alarm :) ) without any kind of authentication or expensive hardware.

 

0

BackBox 4.1 is now here!

Oggi è giornata di festeggiamenti e come vi avevo preannunciato BackBox 4.1 è finalmente disponibile al grande pubblico abbiamo fatto un grande lavoro per poter ottimizzare al meglio questa nuova versione correggendo tanti piccoli errori della precedente versione 4.0. Una grande novità è volta alla virtualizzazione, caricando BackBox in live-mode troverete già disponibili e avviati …

L’articolo BackBox 4.1 is now here! sembra essere il primo su Over Security.

 

0

GParted Live 0.21.0-1

GParted Live GParted Live è una distribuzione Linux basata su Debian rilasciata su un mini CD che fornisce tutti i programmi per partizionare gli hard disk. Utilizza XOrg e il window manager Fluxbox per rendere l’ambiente intuitivo. Funziona su tutte le macchine dal Pentium II in poi. Versione 0.21.0-1 Questa versione contiene (in Inglese): Based […]

Related posts:

  1. GParted Live 0.19.1-1 GParted Live GParted Live è una distribuzione Linux basata su…
  2. GParted Live 0.18.0-1 GParted Live GParted Live è una distribuzione Linux basata su…
  3. GParted Live 0.19.0-1 GParted Live GParted Live è una distribuzione Linux basata su…