Skip to content

Android Brute Force Tutorial

Djamil Elaidi edited this page Mar 30, 2021 · 12 revisions

Android Brute Force Tutorial

Here is a detailed tutorial to implement a new bruteforce on the Android application. The following example is based on the model:

It can be purchased here: [Kerui RC531 on Amazon](https://www.amazon.fr/gp/product/B01KWSL5BW).

Useful vocabulary :

  • Frame : This is the whole message sent by pressing one button
  • CodeWord : One frame is composed of multiple identical (generally) code words.

Step 1 : Gather and analyze the data

A) Center onto signal frequency

Please note that all the above is also explained in URH user guide and Youtube tutorials.

  • First of all, you need a Software Defined Radio (RTL-SDR, HackRF, BladeRF, etc…), plugged on your computer.

  • Launch your favorite data analyzer software. In the current tutorial, I will use Universal Radio Hacker (URH).

  • The first important parameter to know is the frequency of your signal.

    • If you don't know at all the frequency:
      • use a SDR software with a wider range to find the frequency your device uses. You can use any SDR software (SDR# - SDR Sharp, HDSDR , …).
      • Once you know (approximately) your frequency, go to the next step
    • Once you approximately know the frequency:
      • Use the "Spectrum Analyzer" feature from URH (File / Spectrum Analyzer).
      • Put the device on RTL-SDR, or any other SDR you have plugged in.
      • Enter the frequency in the right field and Start Spectrum Analyzer.
  • You should see a frequency peak

- Click on the center of the signal detected. When this is done, you can quit the Spectrum Analyzer.

B) Record signal

The device settings should now be configured, so you can record your signal.

  • Go in the Record Signal tool (File / Record Signal).
  • Capture signal: in this example we pressed once the Disarm button, then once the **Arm ** button of the remote control.
  • When you are satisfied of your signal (noise can be lowered, we will see how in the next point), just save it and quit the "Record Signal" window.

Now you have to interpret what you have just recorded.

C) Interpret signal

In the Interpretation tab, the captured signal looks like:

  • The first step is to choose your modulation (ASK, FSK or PSK). Generally signals are ASK encoded. Then, you have to find the Bit Length. To easily find it, you can change the Signal View to Demodulated. This will change the display of your signal. According to the following picture, measure your Bit Length. Be careful ! You have to be accurate, or your interpretation of the data will be wrong. You have to take the shortest (time meaning) peak.

- You can now go into the *Analysis* tab. Choose how you want to see your data (hex is useful quite often).

As shown, it can be interesting to *Mark difference in protocol* (checkbox on left) between two set of captured data and find the **function** part (you can select your *Message reference* by right clicking on one bit of the frame).

In this picture, you can note that the difference between the Disarm and Arm buttons seems to be on symbols [22-23]. Note down every important information about your signal:

  • Frequency : 433.901 MHz
  • Data Rate : 3225 (SampleRate/BitLength)
  • Modulation : ASK
  • Number of code words : 32
  • Decomposition of your signal :
    • 4 Code Words then one pause of 51.91 ms then 28 similar code words each spaced by 9.88ms as shown below.
    • We can see that one code word is composed of 104 bits (13 x 8 bits):
      • 12 symbols, each symbol being one of {0x88, 0xEE, 0xE8, 0x8E}. If symbols are encoded in 3 bits, please check the NB on the bottom of this section.
      • 1 tail symbol, always 0x80
    • Is there a synchronisation word (sometimes it is really important) ? Not here.
    • Is there a tail word ? I often recommend to add a tail word with 00 to ensure time between each codeword. Then you are assured that 2 following codewords are different and not a single one. Here, we notice that each code word is ended by a pulse (represented as a 0x80). So we will add a tail word like 0x800000.
    • How you want to write your signal : here, the most relevant choice is to encode with Base-4 symbols such as {0x88, 0xEE, 0xE8, 0x8E} because the hex encoding is the easiest to read. Now we will call one symbol one byte from this list (which is of course exhaustive).
    • Which symbols depend on this unique (according to its serial number) device ? For this, I recommend you to try with at least 2 different devices and to record the signal of each button to be sure of what byte will be fixed and what will not. In this example, after a few records, I noted that the 4 last symbols [17-24] (eg. last 4 bytes) depend on the button pressed. This is the function part.
    • Write function part link between each button. For example:
      • Arm --> E8 88 8E 88
      • Disarm --> E8 88 88 E8
      • etc...

So to summarize, we can now see that one code word is composed of 104 bits (13 x 8 bits): - 12 symbols, each symbol being one of {0x88, 0xEE, 0xE8, 0x8E}: * 8 symbols [1-16] for the Device Id * 4 symbols [17-24] for the button function - 1 tail symbol, always 0x80

Now you should know how exactly the transmission is. Let's go to Step 2.

NB : Sometimes your signal doesn't look that easy to decrypt. If the encoding isn't on 2 or 4 bits (which is generally easy to detect with Hex view), it can be on 3 bits! For example, for some devices, logical symbols can be 100 and 101. Like the raw data could be 1011011001001011001001011001011001011

So, to encode it in the app, we need to find the smallest common denominator between 8 (one byte) and 3 which is 24 : That leads to an encoding on 1 byte for every bit : 100 --> 0xFF 0x00 0x00 --> logical 0 ; 101 --> 0xFF 0x00 0xFF --> logical 1. Do not forget to multiply the data rate by 8 too ! Then you transmit the corresponding signal. So, in our current example, as we have 36+1 bits read, that represents 12 logical bits. A logical 0 is 0x00 (which is 100 in our real signal) and a logical 1 is 0xFF (which is 101 in our real signal).

To sum up, we have 36 bits, which represent a Code Word length of 12 symbols, each coded on 3 bytes. The data rate is also multiplied by 8.

Step 2 : Brute Force using the PandwaRF Android application

A) Fill each field of the Brute Force page

This is the easiest part. Launch the app, connect your app to your PandwaRF, go into the Brute Force tab and fill data as following :

  • Frequency (Hz): 433 901 000
  • Data Rate (bits/s): 3225
  • Modulation: ASK/OOK

  • Type/Brand/Model/Function: Leave the default values as they will be overwritten anyway.
  • CodeWord Settings
    • Length : Number of Symbols, so it is 12
    • Start: The start value of Brute Force you want to begin, so 0.
    • Stop: The stop value of Brute Force you want to stop, so (412)-1 = 16777215. Because we have 12 symbols, each can have 4 values { 0x88, 0xEE, 0xE8, 0x8E }.
    • Frame Repetition: Number of Frames you want to send for each BruteForce attempt (you can adapt this parameter if you want to go faster, but sometimes the receiver needs at least 5 frames for example to recognize the signal).
    • Endianess : The byte-order you want to use, generally Big-Endian.

  • Function Mask & Value: The general logic is: Transmitted data = (data_to_send AND Function_Mask) OR (Function_Value) Note that these are bitwise AND/bitwise OR.
    • Mask : This is like a Mask IP Address. Every symbol noted FF is brute-forced, and every symbol noted 00 is fixed. So in our case : FFFFFFFFFFFFFFFF00000000
    • Value : This is the "contrary" of mask. Every symbol noted 00 is not fixed, and every symbol that you want to be fixed needs to be set here. For the Arm function for example : 0000000000000000E8888E88. Note that these last bytes (E8 88 8E 88) correspond to what you have written in Step 1 - C) in the last bullet point.

  • Symbols Encoding
    • Symbols : This is how you encode your signal which is {0x88, 0xEE, 0xE8, 0x8E} so : [0: 88] [1: EE] [2: E8] [3: 8E] The corresponding encoding base is automatically displayed based on the number of symbols (from 2 to 4 symbols).
    • Sync Word (in hex): If you have a synchronisation word, blank in this example.
    • Tail Word (in hex) : If you have a tail word, I put 800000 to ensure time between every codeword.
  • Delay Between attemps: This is the delay between each frame you send. I put 50ms for example. Minimum value is 100ms for a regular PandwaRF, 0ms for a PandwaRF Rogue Pro.

B) Try it yourself !

  • Press "Start Brute Force Attack" button. The Attack status shall display the Brute Force progress.

  • This is now really important to test your signal and adjust parameters such as Delay between attempts or Frame Repetition
  • Remember that we have a PandwaRF Device Bounty, so send us your data, and you can earn some PandwaRF/PandwaRF Rogue Pro.
  • Happy RF hacking!

Project Information

PandwaRF Android Application (Normal Mode)

PandwaRF Android Application (Dev Mode)

Marauder Android Application

iOS Application

Linux

Hardware

For developers

Support

Gimme moar!

Clone this wiki locally