Tech For Fun

Menu

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.

HOW TO DETECT IF YOU BLOWN YOUR PA OR LNA STAGE

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

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

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.

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.

REPAIRING THE HACKRF

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

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.

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).

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.

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.

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.

As New Year’s resolution I will try to update the web more often. And to make it easier to you to follow all those “almost daily changes” (note the exaggeration here), I have created a Twitter and a Facebook account.