Repairing the HackRF

I broke my HackRF One. I have no idea how, but I did it.

While testing a power amplifier I realized that there was not transmission at all. After checking the software, the connections and the power amplifier, I confirmed that my HackRF was broken. It was able receive but not to transmit. More precisely, I was not able to transmit when configuring the HackRF with medium-high TX power. However it worked when configuring the HackRF to transmit with low power.

A fast check in the schematics confirmed my fears: the power amplifier stage was blown.


The HackRF One uses two Avago MGA-81563 amplifiers. This chip amplifies the input signal by 14dB. In the HackRF this chip is used as a power amplifier (PA) for transmitting and as a Low Noise Amplifier (LNA) for receiving. In the PCB they are marked as U25 and U13 respectively.


HackRF One – LNA and PA schematic

Two RF switches Skyworks Sky13317 – U12 and U14 in the schematic – connect the antenna to the LNA, the PA or they just bypass the amplifiers. When working the with HackRF in GNU Radio, the RF parameter enables the amplifiers (RF=14)  or disables/bypass them (RF=0)

Is very easy to find if the LNA – the amplifier for the RX signal – is broken. You just have to launch the osmocom_fft program (you can find it in the  gr-osmosdr package of Pybombs) and sintonize a frequency where you can see transmissions (eg: the FM band). Configure the IF and BB gain to something in the middle of the scale (around 16 and 26dB respectively) and set the RF gain to 0. Measure signals you receive, set the RF gain to 14 and measure them again. You should have approximately a 14db gain. If switching the RF to 14 attenuates the signals instead of increasing, the LNA (U25 in the schematics) is broken and you have to change it.
The following image shows a working LNA. When the RF is set to 14, the signal is amplified by almost 14dB.

Osmocom_fft. LNA OFF vs LNA ON

Osmocom_fft. LNA OFF vs LNA ON

Finding if the PA is broken can be trickier because you need to use a external tool to measure the output power. This tool can be another HackRF or a cheap SDR like the RTL-SDR, but I will use a spectrum analyzer.
Use GNU Radio Companion to transmit a carrier. Set the IF gain to 47 and the RF gain to 0. Measure the output power, set the RF gain to 14 and measure again. If you don’t see an increase of approximately 14 dBs but you see that the signal is attenuated instead, your PA (U13 in the schematic) is broken and it needs to be substituted.

GNU Radio Companion flow used for testing the HackRF

GNU Radio Companion flow used for testing the HackRF

The following image shows the output of my HackRF with PA off and on. As you can see, the signal with the PA off is stronger. This clearly indicates that the PA is blown.

Broken HackRF. Left: PA off - Right: PA on.

Broken HackRF. Left: PA off – Right: PA on.

The main reason why people kill the LNA is because they put too much power in the input. The HackRF is designed for a maximum RX signal of -5dBm. I read in Internet about people that connected their 5Watts (37dBm) directly to the HackRF input, without any attenuator. Magic smoke guaranteed!

The PA can be destroyed because a antenna impedance mismatch. Transmitting without antenna or an incorrect antenna produces a high reflected power that can destroy the PA. In my case, I did not know that the HackRF continues transmitting even if you stop the application. In order to stop HackRF to transmit, you need to press the reset button. I probably killed my HackRF when inserting and removing the external power amplifier I was testing.


You will need to substitute the blown amplifier. You can buy a replacement in Farnell, Digikey, Mouser, etc for less that 3€. The following image shows the location of the LNA and PA (U25 and U13) in the PCB. Blue arrow points to the LNA (U25) and the red arrow points to the PA (U13):

HackRF PCB. Blue arrow: LNA. Red arrow: PA

HackRF PCB. Blue arrow: LNA. Red arrow: PA

I recommend you to use a hot air soldering station and a lot of flux. If you dont have it, you can still use a regular iron solderer if you have a fine tip and you are skilled enough.

Once you substitute the broken amplifier, repeat the tests to check that the LNA or PA works. This is how my HackRF performs after fixing the PA:

Fixed HackRF. Left: PA off - Right: PA on.

Fixed HackRF. Left: PA off – Right: PA on.

If you changed the MGA-81563 and your HackRF still does not work, I would try to change the Sky13317 RF switches (U12 and U14).

Fault injection attacks on microcontrollers: clock glitching tutorial

There is a lot of published papers with information about practical attacks using glitching on cryptographic devices or embedded systems in general. These papers are usually detailed in the process of glitching but not in the setup they use to inject the glitches. They just say at most what kind of FPGA (or commercial station) are using and what “glitching capabilities” they get (frequency, resolution, etc).

If you look for schematic and code to replicate the attacks on these papers, you will not find too much. Almost nothing is published so the reader might think that glitching is something complicated and not easily to perform without specialized and expensive equipment so a false illusion of security against these attacks is perceived.

However, the truth is that glitching can be done with simple and cheap hardware as it has already shown, for example, with the XBOX360 glitch hack or the unloopers that jeopardized the pay-tv smartcards in the mid-00’s.

Today I am going to show you how to clock-glitch for less than 15$ on equipment.

Continue reading

Ultra-low cost IC decapsulation

or how to decap microcontrollers at home and cut your life expectancy in 20 years

Have you ever read about IC reversing? Would you like to introduce you to the world of invasive IC attacks but do you think it is very expensive?
Of course! It is very expensive! I am not going to lie you about that. However, your can do the first step of a invasive IC attack – the decapsulation – at your home using very cheap tools. Instead of spending thousands of euros in chemical laboratory equipment we can spend just only 40€ in common household equipment.

Continue reading

Optimization of Microchip PIC XC8 compiler in Free and Pro mode

I don’t like to program PICs in C language. In fact, I even used to hate it due to the poor quality of the C compilers.

When I started to program PICs microcontrollers in 1998 there was not too many options to program PICs in C. As far as I remember, only Hi-Tech, IAR and CCS had compilers – not even Microchip has his own one – and they were quite horrible compiling. But the fault was not in the compilers manufacturers, but in the PIC core architecture.

Those days Microchip had only what we know nowadays as the ‘base-line’ (12C50X) and ‘mid-range’ (16C54,16F84,16F87X…) architectures. Those cores were so simple that it was not easy no make a C compiler for them. Few memory, scarce resources, small instructions set, few addressing modes…
Anyway, who needs a C compiler with such simple architectures?

Years later Microchip released the more C oriented PIC17/PIC18 architecture and a new range of C compilers for the new PICs were created. Finally we had “reasonable efficient” tools to program Microchip microcontrollers in C!

Two years ago Microchip bought the Hi-Tech company and renamed their Picc compiler as XC8. With this movement, Microchip provide to their clients a cheap and decent C compiler as their old and deprecated C18 compiler was – in my opinion – plenty of bugs and not worthy to work with.

I still use ASM to program the PIC12 and PIC16 family. However, I program the PIC18 devices in C but I often had to dive into the asm of the generated binary  to optimize it.
In those optimizations I have seen weird things made by compilers and I have been long time wanting to write about it.
Today I am only going to write shortly about how the free mode of the XC8 compiler bloats the binary to make the Pro version look more efficient.

Continue reading

eZ430-Chronos tutorial – Part I

Sorry! It is in Spanish only and it is not finished. I will fix this as soon as possible.



El eZ430-Chronos es reloj basado en una plataforma de desarrollo para el microcontrolador MSP430 de Texas Instruments.




En este primer tutorial vamos a conocer la estructura general del firmware del eZ430-Chronos y a añadir nuestra primera funcion: un calendario mejorado.


Entorno de desarrollo

Utilizaremos el Code Composer Studio v4.0 como entorno de desarrollo.

Podemos usar la version limitada descargable gratuitamente de la pagina de Texas Instruments o alguna de las versiones de pago (Microcontroller o Platinum).

La instalacion y uso del CCS no es es objeto de este tutorial.


Instalaremos tambien el codigo fuente del firmware incluido en el reloj descargandolo o utilizando el cdrom incluido con el reloj.


Una vez tengamos todo el entorno de desarrollo instalado, arrancamos el CCS y procedemos a importar un proyecto existente ( File -> Import -> CCS -> Existing CCS/CCE Eclipse Project )


Elegimos como path el directorio donde hemos instalado el codigo fuente.

Durante la instalacion, se habra instalado la version del firmware para el CCS y para el IAR. Asegurate de elegir la version para CCS.

Tambien se incluyen dos versiones del firmware: Una que ofrece la funcionalidad de un reloj deportivo (“CCS\Sport Watch”) y otra que realiza logueo continuo de los sensores (“CSS\Data logger”).

Si se realiza la instalacion por defecto, el path sera C:\Archivos de programa\Texas Instruments\eZ430-Chronos\Software Projects\Chronos Watch\CCS\Sports Watch

Nos aseguramos de activar la casilla “Copy projects into workspace”.


Terminada la importacion, debemos tener nuestro proyecto en la vista de proyectos




Elegimos el perfil activo (868MHz Europa – CSS limited)


Project -> Build Project y confirmamos en la consola que no se ha producido ningun error.

Estructura general ->

– main.c: bucle principal.
– logic\*: Contiene el codigo que gestiona las logicas de las distintas funciones del reloj. Ejemplos:
logic\menu.c: menus
logic\clock.c: reloj
logic\stopwatch.c: cronometro
logic\date.c: fecha
logic\acceleration.c: acelerador

– simpliciti\*: Pila SIMPLICITI
– bluerobin\*: pila bluerobin. (es un binario y los .h. No hay fuente)
– driver\*: control de los distintos perifericos hardware. <- si usamos la version lite, no se compilan.

Echar un vistazo a main.c, menu.c y menu.h


menu.h nos fijamos en esto:


Esta estructura contiene la informacion relativa a los menus que permiten acceder a las funciones del reloj. La estructura sirve para definir indistintamente a los menus del LCD superior o del inferior.

sx_function es la funcion que se ejecuta cuando se pulsa el boton derecho y MX_funciontion la que se ejecuta al mantener apretado el boton derecho unos segundos.

Display_function apunta al metodo que se invoca para pintar el menu en el LCD. El parametro “line” de las 3 funciones anteriores sirve para indicar el LCD donde se renderizara la funcion.

next es un puntero al menu que se saltara la aplicacion cuando se apriete el boton izquierdo una sola vez.


Un vistazo a menu.c

Observamos como se declaran e inicializan los distintos menus, tanto para el LCD (LINE1) superior como el inferior (LINE2).

Por ejemplo, esta es la declaracion de los menus del LCD superior:

Notese como se encadena cada menu al siguiente y el ultimo al primero.

Vamos a centrarnos en la funcionalidad del calendario cuya estructura del menu es la siguiente:

Echaremos un vistazo a display_date() , que es la funcion que se ejecuta cuando el reloj debe debe mostrar la fecha.

El primer argumento, line indica en que LCD se renderizara

que es el metodo que se ejecuta al mantener pulsado el boton izquierdo durante un tiempo