labs

Introducción al análisis de señales

Ya hicimos una introducción a Arduino, mostrando como ejemplo la lectura de un EEPROM.
Ahora por lo tanto toca hablar sobre el análisis de señales.

Esto suele empezar así: “Oh! vaya… una señal curiosa; a veeeeer” xD

El ejemplo que voy a mostrar es el típico caso real de cualquiera que juega con señales, radio, etc. simplemente llega un día que por casualidad se encuentra con “algo” llamativo en su espectrograma, FFT o altavoz y con tiempo y ganas para investigarlo. :-)

En este día le tocó a la banda ISM LPD433 que para entendernos, es una banda UHF (433.050 – 434.790 MHz) pensada para la comunicación entre integrados a cortas distancias y baja potencia (1 – 10mW).

– ¿Y qué nos podemos encontrar ahí?
De todo. Principalmente radioaficionados (es una banda compartida) pero se permite el uso sin licencia en los dispositivos que cumplan la LPD433, como pueden ser por ejemplo: llaves de coches, buscas, telemetrías varias, etc.

– ¿Y como se da con ello? Normalmente así:
SDR# probando un EzCap de los chinos

Si estamos preparados en el momento justo; tendremos algún programa grabando cuando abra el SQL (squelch) y con suerte la tendremos ahí. Pero si buscamos una señal en concreto y sin posibles pérdidas, no queda otra que armarse con un buen disco duro y grabar en raw de continuo hasta que aparezca de nuevo la señal, si es que lo hace.

En este caso era repetitiva y constante (de hecho es una molestia) con lo que grabarla en condiciones es algo trivial. Una vez grabada pasamos al análisis de la misma.

Personalmente recomiendo el siguiente software, que es muy completo y avanzado, aunque al principio puede costar un poco hacerse a él. Signals Analyzer aunque la idea es armarse de unos cuantos, ya que cada uno tiene sus puntos fuertes.

Ahora, veamos la señal con el software SA:
Análisis de la señal con el software Signals Analyzer.

<< Bien JR; menudo empedrado de imagen que nos has colado... xD >>

Tranquilos, por partes; vamos a leer la imagen de abajo a arriba, el primer paso es el de mas abajo, que simplemente es el fichero de audio (un wav) abierto con el programa. La señal se ve claramente, así que podemos seleccionarla y ampliarla con el botón de la lupa.

En el segundo paso, ya se aprecia la señal; que parece una OOK repetida en bloques iguales de lo que podrían ser datos. Seleccionamos uno de los bloques y damos al botón de copia, lo que nos creará un nuevo fichero temporal con solo el tramo seleccionado.

Ya en el tercer paso, de ser una OOK, podremos ver en detalle la señal en nuestro espectrograma reduciendo el valor de la FFT y dividiendo el tamaño. El resultado… sí, parecen paquetes.

En el último paso, aplicamos una serie de filtros y damos valor al payload, parece que tiene sentido, más adelante veremos el detalle del análisis.

Ahora veremos lo mismo, pero en otro software: “GoldWave”.
Su misión no es tanto el análisis de señales, sino más bien el tratamiento de ficheros de sonido; desde mi punto de vista son dos software que se complementan muy bien. Pero como este caso es muy simple, desde GoldWave podríamos hacer todo el proceso.

GoldWave en acción!

El proceso hablando en modo profano, es mucho más simple; ampliar con la rueda del ratón, invertir la señal y ale! :-D

Ahora al caso, me encuentro con un churro de unos y ceros, lo primero suele ser separarlo por bloques según te apetezca y experiencia personal e intentar buscar significado en HEX, DEC, ASCII, ITA2, hacer bruteforce con XOR, etc.

Si lo separamos por bloques de cuatro u ocho bits vemos que queda un bit suelto, buena señal, ya que podría ser perfectamente un bit de paridad; pasamos todo a hexadecimal y bueno, está claro que no hay texto, debe de ser una cabecera y un conjunto de cifras… ¿una telemetría tal vez?

Bueno, aquí lo lógico es pensar que seis ceros seguidos podrían perfectamente ser un padding de la cabecera, pero entonces quedaría poco hueco para datos; por lo que separamos en bloques de 8bits tomando como cabecera los dos primeros bloques y el resto como datos más padding con otro bloque al final de 8bits.

Ahí ya tenemos algo decente, dos posibilidades:
Tres números:
– 1
– 82
– 35

O dos números:
– 210
– 35

Como no se ve claro el que puede ser, llegado a este punto lo mejor es buscar sobre cacharros que trabajen en 433Mhz y manejen una estructura similar a la que tenemos como indicio. El resultado es contundente, estaciones meteorológicas :-P

Y aunque no es ninguno de los modelos que aparecen en Internet, la estructura parece siempre la misma, la temperatura por diez en un campo seguida de la humedad relativa.

¿85 -> 8.5ºC en verano?! Va a ser que no. :-D
Bingo.

Dejamos pasar el rato, las temperaturas suben y es lo que se refleja en la trama.

Ya empieza la caló

Por cierto, si, he dejado un bit que sobra en la temperatura; es por que me imagino que los valores de temperatura negativos serán marcando ese bit a 1. Cuando estemos a bajo cero actualizo la entrada.

Chicos, sed buenos. ;-)
73

Leer y escribir EEPROM desde Arduino

Vamos a ver como leer y escribir en una EEPROM I2C utilizando las entradas analógicas de Arduino.

La EEPROM que he utilizado en el ejemplo es una 24LC256, podéis ver más información en su datasheet. El esquema de conexiones con Arduino es el siguiente: Una vez está conectado todo al Arduino desde el IDE copiamos el siguiente código:

#include <Wire.h>

/* --- START ARDUINO FUNCS ---
 * From: http://www.arduino.cc/playground/Code/I2CEEPROM
 * Author: hkhijhe
 */

void i2c_eeprom_write_byte( int deviceaddress, unsigned int eeaddress, byte data ) {
  int rdata = data;
  Wire.beginTransmission(deviceaddress);
  Wire.write((int)(eeaddress >> 8)); // MSB
  Wire.write((int)(eeaddress & 0xFF)); // LSB
  Wire.write(rdata);
  Wire.endTransmission();
}

// WARNING: address is a page address, 6-bit end will wrap around
// also, data can be maximum of about 30 bytes, because the Wire library has a buffer of 32 bytes
void i2c_eeprom_write_page( int deviceaddress, unsigned int eeaddresspage, byte* data, byte length ) {
  Wire.beginTransmission(deviceaddress);
  Wire.write((int)(eeaddresspage >> 8)); // MSB
  Wire.write((int)(eeaddresspage & 0xFF)); // LSB
  byte c;
  for ( c = 0; c < length; c++)
    Wire.write(data[c]);
  Wire.endTransmission();
}

byte i2c_eeprom_read_byte( int deviceaddress, unsigned int eeaddress ) {
  byte rdata = 0xFF;
  Wire.beginTransmission(deviceaddress);
  Wire.write((int)(eeaddress >> 8)); // MSB
  Wire.write((int)(eeaddress & 0xFF)); // LSB
  Wire.endTransmission();
  Wire.requestFrom(deviceaddress,1);
  if (Wire.available()) rdata = Wire.read();
  return rdata;
}

// maybe let's not read more than 30 or 32 bytes at a time!
void i2c_eeprom_read_buffer( int deviceaddress, unsigned int eeaddress, byte *buffer, int length ) {
  Wire.beginTransmission(deviceaddress);
  Wire.write((int)(eeaddress >> 8)); // MSB
  Wire.write((int)(eeaddress & 0xFF)); // LSB
  Wire.endTransmission();
  Wire.requestFrom(deviceaddress,length);
  int c = 0;
  for ( c = 0; c < length; c++ )
    if (Wire.available()) buffer[c] = Wire.read();
}

/* --- END ARDUINO FUNCS --- */

void writeString() {
  char cadena[] = "HOLA NENITAS :-)";
  i2c_eeprom_write_page(0x50, 0, (byte *)cadena, sizeof(cadena));
  delay(10);
}

void setup() {
  Wire.begin();
  Serial.begin(9600);
}

void loop() {
  int addr = 0;
  char b   = 'X';

  Serial.println("### READ EEPROM ###");

  while (b != 0) {
    b = i2c_eeprom_read_byte(0x50, addr);
    Serial.print((char)b);
    addr++;
  }

  Serial.print("\n### EOF ###\n");

  delay(2000);
}

Veremos los datos de la EEPROM en ASCII por la salida serie a 9600 baudios.
El programa, como prueba de concepto dejará de leer cuando encuentre un nulo, con lo que para hacer dumps de EEPROM es mejor meter un contador por cada byte leído y cortar el bucle cuando se alcance el límite de la memoria.

Si la EEPROM está virgen, puede llamarse a writeString() desde setup :-)


Salu2.

(Español) DNSSnoopy – Herramienta para hacer DNS Cache Snooping

(Español) Mejorando los resultados de nmap – La bbdd de payloads.

Malware analysis Trojan-Spy.AndroidOS.Zitmo.a v1.2.8

We already saw at a previous post Malware analysis Trojan-Spy.AndroidOS.Zitmo.a what could do “Trojan-Spy.AndroidOS.Zitmo.a” v1.2.3. In this post, we’ll talk about the next version seen in the wild, 1.2.8.

Despite this version has some minor changes and new implementations (defence points, etc.) about which we’ll talk later, it still propagates trough SMS messages, faking the encryption application sent from the bank used by the user, as usually.

The first change in the code is one line added to the “MainActivity class”. The developer must have thought that, after loading the cool shield image in the screen and the activation code, and before starting the other functions, it’d better get the C&C URL.

There are new imports in the class “SecurityReceiver”:

  • import java.util.zip.CRC32;
  • import java.util.Random;
  • import java.text.SimpleDateFormat; (version 1.2.3 imported java.util.Date instead)

The new load of a CRC32 module is very striking, so we searched where it was used. It first defines a new constant:

And then the trojan calls the function “SqlCheckLastSend” to get the CRC32 checksum of the C&C URL and compares these two values against each other:

After validating the URL, CRC32 is not used elsewhere.

In this version, the developer has decided to save in the db file a timestamp with the SMS messages’ info.

As we know, the malware was able to receive control commands and has kept this capability and even the functions are the same in this version, but the set control characters have been changed from {“%”, “:”, “*”, “,”} in version 1.2.3 to {“#”, “/”, “!”, “.”}, respectively. Here are the details:

  • “%” –  GET INFO: extracts the phone number from the message and sends the report.
  • “:” – Report Number Update, extract the phone number from the message, saves the phone number to send there following reports,  and sends the report
  • “*” – Uninstall, actives the uninstall flag, extract the phone number from the message and sends the report.
  • “.” – End of control message, cleans the phone number like alternative control point, extract the phone number from the message and sends the report

The last addition is a new “reverseString” function for the class “ValueProvider” that, as it name implies, returns a string with its characters in reverse order.

This new function is used in the new method of evaluating the activation code. In version 1.2.8 the function “GetActivationCode”  gets the “deviceId”, reverses it with “reverseString” and appends a “3” at the end of the resulting string.

The rest of the code is identical to version 1.2.3. These changes mean that the developer is still working on this malware, and new evolutions will be seen on the ongoing future.

Reference: Malware analysis Trojan-Spy.AndroidOS.Zitmo.a version 1.2.3

MD5: e9068f116991b2ee7dcd6f2a4ecdd141

Page 1 of 812345»...Last »