EFR32 RAIL Reverse engineering/Open source alternative

[jsilva]

I have recently discovered Sillicon Labs' Wireless gecko SoCs, the EFR32 series.

Upon reading the datasheet and reference manual for the chip, I noticed that the radio interface chapter is short and just tells people to use RAIL, their closed source radio interface library.

As I am not a big fan of closed source libraries, and I am getting really interested on those chips, I started to search for an open source alternative, but got no success, most likely because they are not wide spread yet.

I though about trying to reverse engineer the library, but I soon realised that would not be easy. I gave it a shot anyways and opened it with IDA to look at some pseudocode that crushed my dreams... Just writes and reads to memory accesses in the radio peripheral address range and even undocumented memory regions.

I would really like to fully use those chips, including the radio. What are your thoughts?

[rstofer]

My thoughts?  Use what the factory provides and be happy! 

At least they give you more than just a 1200 page manual.

[amyk]

. I gave it a shot anyways and opened it with IDA to look at some pseudocode that crushed my dreams... Just writes and reads to memory accesses in the radio peripheral address range and even undocumented memory regions.

What did you expect? That's typical of hardware-interacting code. You will need to make the documentation yourself, based on what the library functions do.

[free_electron]

Most likely this is a kind of SDR. without knowing the actual hardware inside the chip there is no way you will figure out what this library does. Just use it.

[chicken]

What is your intended application?

For the sub-GHz side: When I looked at them in the past (EZR32), the interface for the sub-GHz radio was identical with the EZRadioPRO family. So you might have some luck digging through the datasheets of their standalone radios or older chips. Though, from a quick glance at the block diagram in the linked datasheet for the EFR32BG12, this is probably a different radio.

If you target the 2.4 GHz side and want to replace their BT stack, I wish you good luck :-)

PS: I did some reverse engineering of the insides of the EZRadioPRO radios. Turns out they use the same silicon across the whole EZRadio and EZRadioPRO family, only differentiated by a few factory programmed settings. I wouldn't be surprised if that also applies to the EFR32 series of chips.

[jsilva]

Thanks for your replies. Honestly I would prefer a 1200 pages manual describing the PHY...

I am going to take a look at the EZR series.

[chicken]

Thanks for your replies. Honestly I would prefer a 1200 pages manual describing the PHY...

I am going to take a look at the EZR series.

But what level of abstraction do you want to declare as the PHY? Behind the (mostly) documented SPI interface of the EZRadioPRO is a 8051 running proprietary firmware, and below that there’s a DSP of some sorts, which talks to the hardware (I think)... It’s turtles all the way down!
https://github.com/astuder/Inside-EZRadioPRO

Sorry for the tangent.

For actually getting things done, ignorance is often bliss 

[harbinger]

Sorry for necroposting.
Now it's no longer difficult to do. Using Ghidra I decompiled this library earlier versions (1.xx). Fortunately Flex SDK version 3.xx contains RF registers descriptions - for EFR32 Series 2 as header files, for series 1 as python scripts. So work is in progress now!
Preliminarily: radio part of EFR32 series 1 looks like EZRadio but interface to main CPU is different - using shared memory spaces unlike SPI in EZRadio/EZR32. Mentioned undocumented area of memory (4 KB started at 0x21000000) contains so called "sequencer code" (interrupt vectors and jump tables for 8051-like RF MCU) and (close to end) some registers for address filtering parameters etc...

[chicken]

I did find the register map in the Python code hidden in the SDK. Even wrote a little script for importing the symbols from the EFR32 series 1 SDK into Ghidra.

But I never realized/considered that the radio would still be an EZRadioPRO. Now you're sending me down another rabbit hole! 

I just pushed the Ghidra script to my EZRadioPRO Github repository if anyone is interested - though it may be outdated as I didn't touch it in months.
https://github.com/astuder/Inside-EZRadioPRO/blob/master/ghidra/EFR32registers.py

[harbinger]

But I never realized/considered that the radio would still be an EZRadioPRO. Now you're sending me down another rabbit hole! 

Radio subsystem looks similar to EZ Radio Pro in EFR32 Series 1 only. Series 2 looks very different, e.g. sequencer MCU core is Cortex-M0 unlike 51 and much more...
Thank You very much for script; unfortunately I'm not familliar with python but here is some stimulus to learn it.

[chicken]

Thank You very much for script; unfortunately I'm not familliar with python but here is some stimulus to learn it.

No need to speak Python. Just copy the script into the Ghidra script folder ($USER_HOME/ghidra_scripts). Then in Ghidra open the firmware binary in the CodeBrowser, then launch Script Manager (Windows > Script Manager). You can find the script by filtering for EFR32. Click on script EFR32registers.py to see instructions. Follow the steps to extract the JAR file, then run the script.

[harbinger]

Thanks, it works. 
But I did it already by manual editing .svd file and import it into Ghidra by SVD-Loader. Unfortunately not all RF-related peripherals are fully described in scripts - missing bit-fields of PROTIMER and BUFC registers, but it's not significant problem.   

[harbinger]

Sorry. RF core (called "sequencer") in EFR32 is NOT 51. Probably it's some proprietary core with 16-bit opcodes... Ghidra doesn't know anything about him.

[chicken]

I wonder if the "sequencer" of the EFR32 is equivalent to what they interchangeably call "DSP Core" and "Digital Modem" in patents related to the EZRadio family [1]. The same patents also indicate a DSP program RAM which I was never able to locate when reverse engineering the EZRadioPRO. The EZRadioPRO does have a SEQUENCER peripheral with a few registers, guessing from the field names mostly for enabling/disabling features, setting a few thresholds and a software reset.

Do you publicly document your findings somewhere?

[1] US Patent 8,050,313: Single chip low power fully integrated 802.15.4 radio platform https://patents.google.com/patent/US8050313B2

[harbinger]

Do you publicly document your findings somewhere?

Recently Keil MDK project published on Github.
Now only channel setting, CW and PN9 transmitting are working. On the nearest weekend I will create some description.

[harbinger]

Attempted to create a bitmaps of BUFC and PROTIMER registers, based on data from similar chip (EFR32FG21). Not all bitfields maybe correct, some experiments in progress now.

[krakatit]

Hello,
nice to see you guys enjoy this good job as I planned to reverse the efr32 radio too, you are a miles ahead. Recently I developed efr32fg1/mg13 application, attempting to use long range DSSS phy settings. After some research I realized that even chips within the efr series-1 are equipped with different hardware demodulators: FG1 (dumbo) does not properly work with DSSS oQPSK settings, sensitivity is worse with no observable processing gain, MG1x (nerio) does exhibit better sensitivity even with FSK. Sadly this information is not published anywhere in SL documentation, only a few replies from employees in forum confirm that (https://community.silabs.com/s/question/0D51M00007xeRNRSA2/5kbps-rail-configuration?language=en_US
).
On radio submachine: SL acquired Ember https://en.wikipedia.org/wiki/Ember_(company) as like as their SDK, so there may be a way to reach the devils core (https://en.wikipedia.org/wiki/XAP_processor)?

Good luck!

[harbinger]

Transmitting fixed-length packets and TX power level control are working now.

[harbinger]

Two-way TX/RX working, add simplified TX power setting in dBm units (using power table).

[harbinger]

Did some refactoring. Now working on EFR32FG23.