https://z4ziggy.wordpress.com/feed

Since following the official docs failed for me, here is a short guide to get started and run ‘Hello World’ in Fuchsia.

1. Download and install Fuchsia:

cd ~
curl -s "https://fuchsia.googlesource.com/fuchsia/+/HEAD/scripts/bootstrap?format=TEXT" | base64 --decode | bash
export PATH=~/fuchsia/.jiri_root/bin:$PATH
source ~/fuchsia/scripts/fx-env.sh

2. Configure your target to include /examples/hello_world and build a Fuchsia image:

cd ~/fuchsia
fx set workstation.qemu-x64 --with //examples/hello_world
fx build

3. Start a Fuchsia shell – it will be required even if you run the ‘hello world’ from outside the emulator using ‘ffx’.

fx vdl start -N -u ~/fuchsia/scripts/start-unsecure-internet.sh --headless

4. Run the ‘hello_world’ binaries. You can edit their source code – located under ~/fuchsia/examples/hello_world. Don’t forget to rebuild if you do.

Wait for the Fuchsia command prompt to be ready (displays the ‘$’ sign) and type within the Fuchsia shell:

run fuchsia-pkg://fuchsia.com/hello-world-cpp#meta/hello-world-cpp.cmx
run fuchsia-pkg://fuchsia.com/hello-world-rust#meta/hello-world-rust.cmx

You can also open a new shell and type:

ffx component run fuchsia-pkg://fuchsia.com/hello-world-cpp#meta/hello-world-cpp.cmx
ffx component run fuchsia-pkg://fuchsia.com/hello-world-rust#meta/hello-world-rust.cmx

Or

fx shell run fuchsia-pkg://fuchsia.com/hello-world-cpp#meta/hello-world-cpp.cmx
fx shell run fuchsia-pkg://fuchsia.com/hello-world-rust#meta/hello-world-rust.cmx

To witness a Fuchsia crash, type from within Fuchsia shell:

bin fuchsia-pkg://fuchsia.com/hello-world-rust#meta/hello-world-rust.cm

a long stack backtrace should follow.

Question: Given one repeatable character as input, can a program produce an ‘Hello world!’ output, using only a formula? eg,

Any different input will change the output accordingly.

Answer: Please think over the question before reading the answer.

What started as a naive quander proved to be an enjoyable challenge. At first I doubted this was possible. Then I had given it a second thought and started playing with complex formulas using last added char as reference, shifting bits along some basic xoring – until it hit me – the solution is stupidly simple.

All I need to do is count the number of characters (regardless if they are repeatable – only the count matters), and iterate through printable ASCII codes on each increment. This solution required some recursive thinking, which led me to the simplest solution – count and divide.

We’re only encoding printable ASCII characters (range 0x20-0x80), which in total is 0x60 (96) chars. Therefore, we treat each ASCII code as number from 0x0 to 0x60, and print it back by adding 0x20 (32) to it.

To decode a given number (representing the total count of the repeatable char) we divide the number by 0x60, treat the remainder as ASCII, and loop over the quotient (result) until zero.

Since we can’t really print trillions of one char in Bash and pipe it, I will refer only to the total count of the char. With that in mind, here is my solution:

dc -e "10956485357939826936328[96~32+Pd0<X]dsXx"

Where 10956485357939826936328 is the number of characters needed to print ‘Hello world!’ using this formula. The logic can be further optimized, but it was good enough for me. I leave the encoder as an exercise for the reader.

Connecting ESP01 to ADC0838 via SPI.

I really like messing with the ESP01 modules and use them for various tasks.
​This time I wanted to make a small device to report real-time status of 8 piezos
via Serial & Wifi. So ESP01 was chosen as the main MCU, and an ADC0838 for
Analog/Digital Converter to overcome the ESP01 lack of pins and connect my 8
piezos via SPI.

The problem was how to use both Serial and SPI simultaneously on the ESP01.
Since the ESP01 only provides us with 4 available pins, 2 of them which are
used for serial communication, and that leaves us with only 2 pins which are
clearly not enough for SPI (which requires 4 pins – MOSI,MISO,CLK,CS). The
solution was to disable RX on serial since I didn’t need any serial input,
only output (TX) is used. To achieve that, I’ve used the following line:

Serial.begin(115200,SERIAL_8N1,SERIAL_TX_ONLY);

You will notice the SERIAL_8N1 parameter, which signals the Serial to work with
8 data bits, no parity, and 1 stop bit – a reminder for good old BBS days when
you had to configure the COM port yourself (eg, mode COM1:9600,N,8,1,P).

This leaves me with 3 available pins, which is still not enough for SPI, so I
had to improvise and reuse one ESP01 pin for both MOSI & MISO (eg, DI/DO) and
switch the pins’ direction (INPUT/OUTPUT) in code when needed (from the PDF:
The DI and DO lines can be tied together and controlled through a bidirectional
processor I/O bit with one wire).

The ADC part itself is straight forward and I just followed the PDF instructions –
the CLK has to be cycled after every bit is sent, and cycled before every bit
is received. Do note that sending a command is 5 bits long while a reply is 8
bits long (this is an 8 bit ADC).

ESP PIN #10 (CS)    -> ADC PIN #18
ESP PIN #11 (DI/DO) -> ADC PIN #14 & ADC PIN #17
ESP PIN #12 (CLK)   -> ADC PIN #16

In retrospect I would recommend using a 3V ADC such as MCP3208 which works
better with ESP01 and doesn’t require additional power (5V) input.​

You can find the complete source code here

As the title suggests, I needed to sniff some 802.11 packets, but this time using an ESP8266 (actually, a Wemos D1 mini Lite, which features ESP8285, but any ESP-based device should work).

I started with grabbing the esp8266_pcap_serial from ArduinoPcap just to find out it lacks the structs to properly stream the buffer to Wireshark. I quickly fixed it (uploaded here) and then encountered a 2nd problem which was not as easy to fix – there is a 128 bytes limitation on the SDK for packet size. Oh dear, I guess some firmware hacking are heading my way. But hey, if we’re going to hack the firmware, we better code a new sniffer, right? Here goes.

We have two official firmwares to choose from: Non-OS SDK or RTOS SDK. The main differences are (taken from here):

Non-OS SDK

• The Non-OS SDK uses timers and callbacks as the main way to perform the various functions – nested events, functions triggered by certain conditions. The Non-OS SDK uses the espconn network interface; the user needs to develop their software according to the usage rules of the espconn interface.

RTOS SDK

• RTOS version SDK uses the freeRTOS system, a multi-tasking OS. You can use standard interfaces to freeRTOS resource management, recycling operations, execution delay, inter-task messaging and synchronization, task-oriented process design. For the specifics of interface methods, refer to freeRTOS official website instructions or USING THE FREERTOS REAL TIME KERNEL – A Practical Guide introduction.
• RTOS SDK version of the network operating interface is a standard lwIP API, while providing a package which enables BSD Socket APIsocket interface. Users can directly use the socket API to develop software applications; your code can also be directly compiled to run standard applications on other platforms Socket , effectively reducing the cost of learning platform switching. (possibly flawed translation)
• RTOS version of the SDK introduces cJSON library, use the library functions to more easily parse JSON packets.
• RTOS version is compatible with non-OS SDK in the Wi-Fi interface, smart config interfaces, Sniffer related interfaces, system interface, timer interface, FOTA interfaces and peripheral driver interface, but does not support the AT implementation.

For my purposes I naturally went with the RTOS SDK. Follow the instructions on the README and install the proper toolchain (mine is Linux64) before proceeding with the firmware itself.

WARNING: Do not try `apt install gcc-xtensa-lx106` or any other version, since the firmware will fail to compile. Here, I just saved you a few hours of errors.

wget https://dl.espressif.com/dl/xtensa-lx106-elf-linux64-1.22.0-92-g8facf4c-5.2.0.tar.gz
tar zxvf xtensa-lx106-elf-linux64-1.22.0-92-g8facf4c-5.2.0.tar.gz
export PATH=$PATH:`pwd`/xtensa-lx106-elf/bin

Now I was ready to clone and compile the firmware. First thing todo is configure the firmware options via make menuconfig . A few important notes:

• • Make sure you select correct memory size for your board on 'Serial flasher config -> Flash size'.
  • Do not change 'Compiler Options' from 'Debug' to 'Release', otherwise your program will fail to load properly.
  • For 'Wemos D1 mini Lite' I had to change the default 'Serial flasher config' -> 'Flash SPI mode' to 'DOUT', otherwise it won’t flash properly. Other boards such as 'Wemos D1 mini Pro' worked just fine with the default 'QIO'.

git clone https://github.com/espressif/ESP8266_RTOS_SDK.git
cd ESP8266_RTOS_SDK
export IDF_PATH=`pwd`
cd examples/system/console
make menuconfig
make -j8 flash monitor

Press the RESET on the ESP8266 board, and watch the terminal log for some geeks’ entertainment (to exit Miniterm, press ‘CTRL-]’). If you want more logging fun, select ‘Verbose’ on the log level, recompile and flash again.

Now for the sniffer part, I patched together some ESP8266 pcap sniffer firmware. To try it yourself, make sure you disable all log output (on make menuconfig) since the log output will interfere with the pcap output of the sniffer. Use make menuconfig to change the sniffer settings.

cd $IDF_PATH/examples/wifi
git clone https://github.com/z4ziggy/esp8266_pcap_uart.git
cd esp8266_pcap_uart
make menuconfig
make -j8 flash
./SerialShark.py

This is what it should look like:

Note: Don’t try this with BusPirate V4 since it will fail after turning PSU on.

Normally you would program your STM32 using a USB-To-Serial adapter, but I couldn’t find mine and I knew I can use my BusPirate to act as one, I just had to figure out the correct pins on the STM32, and use the proper UART configuration on BusPirate. So, here goes.

Connect the followings wires from BusPirate to your STM32:

MISO -> A9
MOSI -> A10
GND -> GND
3V3 -> 3V3


Move BOOT0 jumper on STM32 to ‘on’. This is how it should look like:

Plug the BusPirate to the PC and make sure you have read/write permissions to your /dev/buspirate device (symlinked to /dev/ttyUSB0 usually). If not, just allow all users to read/write for now (this ain’t a security post…):

sudo chmod 666 /dev/ttyUSB0

Connect to your BusPirate device:

picocom -b 115200 /dev/ttyUSB0

Press enter to clear the buffer and you will be presented with the BusPirate prompt. Select UART mode, 115200, 8, EVEN, 1 stop bit, Idle 1, Normal output (H=3.3V):

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. PIC
9. DIO
x. exit(without change)

(1)>2
Clutch disengaged!!!
To finish setup, start up the power supplies with command 'W'
Ready

Turn on the STM32 device:

UART>W
POWER SUPPLIES ON
Clutch engaged!!!


The STM32 should turn on and the red led should light up.

Finally select “Bridge with flow control” macro and answer ‘y’ when prompted:

UART>(3)
UART bridge
Reset to exit
Are you sure? y


You can now exit picocom using CTRL-A CTRL-X.

On Arduino IDE, select Board ‘Generic STM32F103C series’, make sure ‘Upload method’ is set to ‘Serial’ and select the BusPirate port (/dev/ttyUSB0) on the ‘Port’ menu. Now upload a blink sketch similar to this:

#define LED_PIN PC13
void setup()
{
pinMode(LED_PIN, OUTPUT);
}

void loop()
{
digitalWrite(LED_PIN,!digitalRead(LED_PIN));
delay(1000);
}

[EDIT: I forgot to add the part where I’m flashing the bootloader – use the correct binary from here and use stm32loader to flash like this:

stm32loader -e -p /dev/ttyUSB0 -w generic_boot20_pc13.bin

and the STM32 should have the stm32duino bootloader installed.]

Move BOOT0 jumper on STM32 to ‘off’ mode before disconnecting the device and remove all the wires between the BusPirate and the STM32.

Create a valid udev rules file for the new device under /etc/udev/rules.d/45-maple.rules:

SUBSYSTEM=="usb" ATTRS{idProduct}=="0003", ATTRS{idVendor}=="1eaf", TAG+="uaccess"
SUBSYSTEM=="usb" ATTRS{idProduct}=="0004", ATTRS{idVendor}=="1eaf", TAG+="uaccess"


Reload the udev rules using:

sudo udevadm control --reload-rules

Connect the STM32 to your PC using a USB connection only. The STM32 should now be identified as a ‘Maple’ USB device. On Arduino IDE, change the ‘Upload method’ to ‘STM32duino bootloader’ and select ‘Port’ to the newly created device listed as ‘Maple mini’ (usually /dev/ttyACM1 or similar), and try to upload the blink sketch again. If this fails, press the ‘Reset’ button on the STM32 and immediately click the ‘Upload’ button on Arduino IDE (thats how it works with my STM32 anyway, I guess it doesn’t recognize the reboot request).

Zigfrid is the end result of my RFID tinkering. Since I will most definitely forget most things described here in the (very) near future, I share this for those few who might find it interesting. Please be warned: This is not a toy. It is completely unreliable, untested, malicious tool, which can and will cause elevators to stop or even shut down immediately, locks to jam, hackers get jailed, and other weird RFID phenomenons. Ok, you get the idea, lets move on.

I guess I watched too many movies as a kid, and craved myself one of those futuristic-looking RFID “master keys” which opens all doors [with a few flashing leds for a more attractive effect], but as I grew older and learned there isn’t one I decided to try and build one for myself. I ended up with a tiny passive device consisting an ATtiny85 AVR, an antenna (coil), and 1 capacitor, with no need for external power. It’s so tiny, it can fit in a common chewing gum and glued next to any RF reader to fuzz away.

My RFID adventures began with a cheap 20$ Handheld RFID Reader/Copier – a simple battery-powered device with 2 buttons controlling the read & write functions of it’s PCB, which uses an obscure chip labeled with the mysterious “F300 ET94 242+” which later found to be based on a more popular chip C8051F300. I hacked the PCB and connected it via it’s pins to my Arduino and later to my BusPirate in the hope of getting something on it’s serial line via the RX & TX pins – (and maybe later to alter it?) for vain – only a random bits every a few reads was letting me know I’m looking at it all wrong. And I was.

I continued looking at other directions and stumbled upon this Magspoof (by SamyK) article (Hebrew only) and among it’s comments I found my answer – AVRFID, a project originated way back in 2008 by the media artist/hacker Micah Elizabeth Scott who published this project – an AVR with hardcoded EM4102 tag id, using the RF frequency for it’s power supply, thus making the AVR completely passive with no need for external battery. Some upgrades & forks has been made since, so I decided to try my luck with this approach, and check if I can adjust the project to my requirements and build a simple RFID fuzzer.

*   This is a very weak power source, and the AVR typically gets little
*   over a volt of Vcc. As a result, most of the AVR's oscillators won't
*   start. We can, however, use the carrier wave itself as a clock as well.
*   This also makes the software easy, since the instruction clock is also
*   the RF clock. We're already clamping the coil voltage into something
*   resembles a square wave, so this makes a good external clock source.

This looked promising.

After flashing the AVR and setting lfuse to 0xC0 to use an external clock, I’ve put it against the RF reader expecting to see any result – but nothing happened. I will save you the time & frustration I had for over a few (!!) weeks – I tried different combinations of capacitors & antennas, but nothing worked, I simply didn’t get any response from my RF reader (actually, RF readers – I tried several different types of 125khz RFID readers, including proxmark3, all ended with same poor results), and during those weeks I found at least two other successful attempts of other individuals who were able to accomplish a working AVRFID without any problem, which only contributed tremendously to my frustration. I finally bought a small nano-scope to assist me with my debugging, and boy, did that help. I finally was able to visually see in real-time what was happening on the AVR with different antennas & capacitors combo, and with some little tweaks (and initially adding a battery source just to boost successful readings) I was able to finally have my own passive AVRFID working to my amusement.

Some notes regarding the capacitors:

• The capacitor is dependent on your antenna (coil). You will have to do some calculations or use trial & error approach with different capacitors combo to get best results with your antenna.

• Using a curtain capacitors combo might initiate a DoS attack on the reader which will prevent legitimate tags from being read correctly after placing it against a reader only once. A hard reset to the reader will be required to resume work. Just FYI.

Same as the original AVRFID, I started with a simple 1mH inductor to act as antenna which works better than most antennas I have tried later on, albeit with one big caveat – you must place it in a curtain angle over the RF reader antenna, which is a major drawback. Among my endless trials to extend the RF range I even tried scraping the antenna out of an RFID tag but the wires are so delicate and that failed miserably. I settled with removing the antenna out of a 125khz RFID module and soldered it to the AVR; If you plan to wire your own antenna DIY style, remember it requires calculations of the coil thickness, tolerance, rounds, etc. – all the useless headache I wanted to avoid. As Micah & others had mentioned, it is essential to add a small capacitor to improve stability & AVR performance. Your results will vary depending on the RF reader & your antennas (both the RF reader and the AVR) and the capacitors should be changed accordingly (eg, trial & error style).

The software part took me much more than I planned nor wanted, but it was a fun journey never the less. Everything was new to me, from AVR assembly language to RFID/em41xx format, so I had to take it step by step. I began with learning the original macro assembly code Micah had written so I kept the “AVR Instruction set” manual opened. After understanding her code logic (she writes beautiful code thus making it much easier and enjoyable read) I immediately jumped into the water and began coding my own version of the EM41xx part in pure AVR assembly. All went fine until I reached the last 10% of the code, at which that point I’ve decided my logic is at false and I have to start over. I did it over a few times, and by the 3rd iteration I was confident enough at my AVR assembly skills to conclude this is completely the wrong approach. I then went with a C program with some inline assembly, expecting it to work like a charm, but it didn’t ofcourse, no matter what I tried. I used the nano-scope to check what was going on and I quickly learned nothing is being sent. Oh my.

Took me a while and lots of banging my head against the wall to figure out what was wrong (debugging AVR with external clock is not an easy task as one might think) and eventually I figured out all those tiny bugs and even better – how to fix them. Hooray, I had a working C program able to send a list of known IDs using a simple state machine. I now wanted something better, and ofcourse, I decided to write a new version, this time using interrupts, only because I thought it’s more ‘appropriate’ to this kind of project. My final design is a C program which does all the boring work of setting up a buffer to be sent, increment a 32bit number with 8 bit registers, and leaves only the time-critical parts to assembly – sending Manchester encoded zeros & ones in nice & clean cycles. The code is also highly optimized (less than 500 code bytes) but won’t fit ATtiny10 because of the data buffer (64 bytes long, twice as what ATtiny10 provides) and I was too lazy to optimize any further, so only ATtiny85 and above are supported atm.

While I was doing all the debugging, I had to reflash the AVR every time. Since we are disabling the internal AVR clock, we must supply the AVR with an external clock signal when programming – luckily BusPirate supports this and latest avrdude (6.3) also supports this in binary mode (was ASCII-mode-only pre 6.3) so everything should be painless. To flash the AVR we’re using the “-x cpufreq=125” parameter to simulate the external clock while reflashing it, otherwise you have to provide your own external clock when you’ll try to reprogram your AVR. The pinout connections is same from Trammell Hudson, I just corrected the Gnd wire:

                        +-------+
    White/white   Reset |1  v  8| Vcc   Red
    Blue/Blue     Xtal1 |2     7| SCK   Purple/green
                  Xtal2 |3     6| MISO  Black/Black
    Brown         Gnd   |4     5| MOSI  Gray/Yellow
                        +-------+

And there you go. You should end up with a nice, tiny, passive fuzzer which fits in the palm of your hand. You can now hide it in a chewing gum and glue it to the reader.

I’m releasing Zigfrid as a POC only – it can/should be enhanced to try some (possible) overflows in RFID readers, and of-course fuzz some “Administrator” tags by filling tag-ID with 0xFF, Nulls, etc. As for this public release, I decided to keep with the KISS approach and only use 32bit incremental, but why not increment all 40bit of the EM41xx tag ID? or fuzz HID readers? Let your imagination run free. The final code supports a led on PIN5 for debugging purposes and to provide the “flashing led effect” (a red led is recommended since it requires less amperage). If you prefer to keep it in stealth mode, simply don’t connect a led. One major drawback with my current design is other tags or interruptions may interfere with our fuzzer while it’s working, thus making it highly likely for the AVR to restart itself which will cause the entire fuzzing process to start from the beginning. Maybe a future version should save the numbers in the EEPROM every xx increments to fix this. Also, adding Manchester reading support (something like this) will turn Zigfrid into a passive sniffer – might be worth the hassle.

Finally, a demo of Zigfrid in action:

Some coding notes:

• Using PROGMEM attribute on your variables requires changing the assembly instructions used to access those variables (eg, from “LD” to “LPM”) or use pgm_read_byte() when in C. You can also modify PROGMEM area, but this is discouraged.

• “-nostdlib” flag shaves off all the gcc extra wrappers, including the part which copies the data section, thus make all your array values play hide & seek with you (spoiler: they’re not there unless you copy them manually __do_copy_data() style).

• “-nostdlib” flag will cause your main() function to travel to a random space instead of zero (which is where the AVR loads the initial code from). You can instruct the linker to set it’s loading address to zero using all kinda tricks, my chosen one is “__attribute__((section(“.vectors”)))” which places the function in the “vectors” section (which begins at zero).

• “-nostdlib” flag also removes the “interrupt jump table” so you will have to provide one yourself using a linker script or in the code.

For more RFID hacks check this site which seems to archive most of them.

[Edit: Useful links]

http://wiki.yobi.be/wiki/RFID

http://www.t4f.org/category/projects/open-rfid-tag/

http://www.instructables.com/id/RFID-Emulator-How-to-Clone-RFID-Card-Tag-/

http://ficara.altervista.org/atmel_avr.php

This is the story of my Bluetooth hacking adventures. If you want to start with BTLE hacking right away, feel free to jump over to the 2nd (technical) part, otherwise read on as I share my BT exploration findings and thoughts.

NOTE: When I refer to BT I also mean BTLE, which as everyone already concluded, aside from the name and the frequency range, it got nothing todo with good-old-BT, but it’s there, so we’re including BTLE as part of our BT attack vector.

As I usually do with a new target, I go for the sources – I started with looking at the BT stack itself – both on Linux and on Android, since apparently they are not the same. Google switched the Android BT stack from BlueZ – the default Linux BT stack – to their own BT stack named BlueDroid, which obviously made all my Linux BT tools & sources obsolete. It seems when Google set to replace BlueZ with their own home-grown BlueDroid, the reason speculated was licensing issues – BlueZ is GPL and Android and its eco system are Apache (yea, well, aside for the closed-source parts held by Google whilst ignoring the elephant in the room – the GPL Linux kernel). However, if you compare the sources of the two projects from a commercial point of view, you notice two big names who contributed most of the code to each project – Intel @ BlueZ and Broadcom @ BlueDroid, which makes me think something else was involved.

On with my target, I then looked at some of the existing BT attacking tools and hacked their sources to get a better understanding of what was going on. Some of the interesting tools are:

• atshell – opens a connection to a BT target on curtain channel
• attest – save as above, will also blindly try to retrieve contacts, calls, etc
• bluesnarfer – same as above, but with more options
• bt_dos – denial of service attack on a BT target

(more info here: http://tools.kali.org/tag/bluetooth)

I continued with looking at the BT documentation (over 2700 of pages long, 8 volumes, hundreds of revisions, and thats apart for BTLE) and was pretty confident I will find some problematic implementation of such an horrifying design. Returning to the BT stack source code confirmed my feeling and I found some promising leads which I wanted to follow. I first mapped my target frequencies:

channel 00 : 2.402000000 Ghz
channel 01 : 2.403000000 Ghz
channel 02 : 2.404000000 Ghz
…
channel 78 : 2.480000000 Ghz

channel 37 : 2.402000000 Ghz
channel 00 : 2.404000000 Ghz
channel 01 : 2.406000000 Ghz
channel 02 : 2.408000000 Ghz
channel 03 : 2.410000000 Ghz
channel 04 : 2.412000000 Ghz
channel 05 : 2.414000000 Ghz
channel 06 : 2.416000000 Ghz
channel 07 : 2.418000000 Ghz
channel 08 : 2.420000000 Ghz
channel 09 : 2.422000000 Ghz
channel 10 : 2.424000000 Ghz
channel 38 : 2.426000000 Ghz
channel 11 : 2.428000000 Ghz
channel 12 : 2.430000000 Ghz
channel 13 : 2.432000000 Ghz
channel 14 : 2.434000000 Ghz
channel 15 : 2.436000000 Ghz
channel 16 : 2.438000000 Ghz
channel 17 : 2.440000000 Ghz
channel 18 : 2.442000000 Ghz
channel 19 : 2.444000000 Ghz
channel 20 : 2.446000000 Ghz
channel 21 : 2.448000000 Ghz
channel 22 : 2.450000000 Ghz
channel 23 : 2.452000000 Ghz
channel 24 : 2.454000000 Ghz
channel 25 : 2.456000000 Ghz
channel 26 : 2.458000000 Ghz
channel 27 : 2.460000000 Ghz
channel 28 : 2.462000000 Ghz
channel 29 : 2.464000000 Ghz
channel 30 : 2.466000000 Ghz
channel 31 : 2.468000000 Ghz
channel 32 : 2.470000000 Ghz
channel 33 : 2.472000000 Ghz
channel 34 : 2.474000000 Ghz
channel 35 : 2.476000000 Ghz
channel 36 : 2.478000000 Ghz
channel 39 : 2.480000000 Ghz

I then put together a simple wrapper around hcitools to perform periodic inquiry and sniff the results, and automatically execute the various BT attack tools upon a newly detected target. This resulted in lots of information retrieved (many phones still provide their contacts list, many BT audio-devices allows connecting using ‘1234’ as pin, etc) but no active attack. It then dawned on me I can no longer avoid using my HackRF if I want to achieve active attacks – the BT tools nor the firmware on my Laptop (nor on my Android) allows much to be played with and I didn’t feel like reversing the firmware is a good idea… so HackRF it is.

I found that Jiao Xianjun was working on a BTLE decoder/encoder and was able to successfully replay iBeacons using his hackrf, so I fired up hackrf_transfer and started playing with recording BTLE channel 37 (one of 3 BTLE advertising channels) on 2.402ghz frequency while sending iBeacons from my laptop, and then replaying the sniffed data – but nothing worked – nothing seemed to be appearing on Gqrx nor in SDRSharp. Was I doing something wrong? I double checked everything, and even made a GNURadio flow for debugging – but same results – nothing was appearing on my 2.402 spectrum. I concluded my antenna which is designed for 75mhz-1ghz range was to blame, and I decided to wait until I get a decent 2.4ghz antenna. The day after I got such antenna (actually I cheated – I took a female SMA 2.4ghz antenna and inserted a pin turning it into a male), plugged it to my hackrf – same results. Now I knew I was doing something wrong, but what was it?

Gain.

The hackrf is very picky about its gain values, and it seems each SDR GUI program behaves differently with different gain values. Once I found the correct values (the values used for each program including hackrf_transfer were different for each) I finally was able to watch my iBeacons and replay them to my enjoyment. I also tried to watch for some interesting data in real time, first using gr-bluetooth but that failed miserably with ‘general protection fault’ errors and I’m guessing thats due to lack of project updates, and so I proceeded to NRF24-BTLE-Decoder which worked nicely with hackrf_transfer as follows:

# hackrf_transfer -r /dev/stdout -f 2402000000 -a 1 -g 16 -l 32 -s 8000000 | nrf24-btle-decoder -d 2

Although decoding was wrong, it was still nice to get some results from the decoder (I’m suspecting the sample rate is wrong here, but too lazy to investigate this further).

HTH.

1. Start sending iBeacons from your computer:

# hciconfig hci0 leadv
# hciconfig hci0 noscan
# hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 00 00 00 C8 00

2. Start recording channel 37 using hackrf_transfer:

# hackrf_transfer -r ibeacon.raw -f 2402000000 -g 16 -l 32 -a 1 -s 8000000 -b 4000000

3. Watch for iBeacons on your iPhone or Android (I used this but you can use any other iBeacon detector) and press CTRL-C on hackrf_transfer once you see an iBeacon on your scanner and stop sending iBeacons:

# hciconfig hci0 noleadv
# hciconfig hci0 piscan

4. Replay your iBeacon from HackRF:

# hackrf_transfer -t ibeacon.raw -f 2402000000 -x 47 -a 1 -s 8000000 -b 4000000

You might need to replay it quickly simultaneously a few times to make the iBeacon get detected. Try something like this (loops 50 times):

# for i in {1..50}; do hackrf_transfer -t ibeacon.raw -f 2402000000 -x 47 -a 1 -s 8000000 -b 4000000; done

5. To further optimize the file to filter out the noise and manually select the BTLE signal we are interested at, we need to open Audacity and import the ibeacons.raw file using the following options:

File > Import > Raw Data

Now search in the file for something which looks like this nice bluetooth wave (depends on your zoom level):

Select this signal on Audacity, and multiply it at least 10 times in a new file. Result should look something like this:

Export the new file using the following options:

File > Export Audio > Other uncompressed files > Options

And enjoy your replayed file:

# hackrf_transfer -t ibeacon_new.raw -f 2402000000 -x 47 -a 1 -s 8000000 -b 4000000

While my friend and colleague Simone was visiting our ZIMPERIUM – Enterprise Mobile Security TLV office, we got our hands on HackRF and hacked together the unguarded boarders of Radio Frequencies. Simone had the great patience to try and explain me the boring world of complex numbers and friends (more on that here), but my dyslexia won over again and left me to fill the gap by following Simone’s steps (and some mistakes, eh Simone? ) and use my ‘trial & error’ approach until success. This tutorial is the result of our collaborate GSM hacking session, presented with the hope it will be useful for others.

• hackrf_kalibrate
• gnuradio-companion
• gr-gsm
• gqrx
• wireshark

First thing, you want to make sure you have all the required software installed, you can install most of them and their dependencies using your distribution package manager. Let’s start with the libraries and tools for the hackrf itself, on a Debian/Ubuntu distro you’ll install them like so:

sudo apt-get install hackrf libhackrf-dev libhackrf0

Once these libraries are installed, you can plug your hackrf into one of your USB ports and execute the hackrf_info command, at this point you should see something like the following:

# hackrf_info

Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1
Part ID Number: 0x00574746 0x00574746
Serial Number: 0x00000000 0x00000000 0x14d463dc 0x2f4339e1

You will now install gnuradio which is the software we’ll use to decode the RF signals, gqrx a tool to visualize signal power on certain frequencies and everything else that will be needed in the next steps:

sudo apt-get install gnuradio gnuradio-dev gr-osmosdr gr-osmosdr gqrx-sdr wireshark

Proceed with gr-gsm, the GnuRadio blocks that will decode GSM packets:

sudo apt-get install git cmake libboost-all-dev libcppunit-dev swig doxygen liblog4cpp5-dev python-scipy
git clone https://github.com/ptrkrysik/gr-gsm.git
cd gr-gsm
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig

Now create the file ~/.gnuradio/config.conf and paste the following contents into it:

[grc]
local_blocks_path=/usr/local/share/gnuradio/grc/blocks

Finally install kalibrate-hackrf, a tool that will hop among known GSM frequencies and will tell you which your country is using:

git clone https://github.com/scateu/kalibrate-hackrf.git
cd kalibrate-hackrf
./bootstrap
./configure
make
sudo make install

Each operator in each country uses a different frequency in the GSM possible spectrum, which usually starts from 900Mhz. You can use hackrf_kalibrate to find the frequencies you want to sniff:

./kal -s GSM900 -g 40 -l 40

Note the two gain values, those are important in order to get some results. Leave kalibrate running and after a while you should see an output similar to this:

You will have to use the proper GSM parameter (‘-s’) to correspond to your local operator. Consult this list for verification.

Sometimes you might want to see the frequencies in order to ensure correct results from hackrf_kalibrate, or to save yourself from calculating the correct frequency given by hackrf_kalibrate (notice the +/- Khz sign of each result – this means the top peak with the corresponding power,not 100% correct frequency). Open gqrx and tune it to the first frequency you got from hackrf_kalibrate, for example 940.6Mhz, and you’ll see something like the following picture:

In the above screenshot you can visually see the activity is around 945Mhz.

Once you know the GSM channels frequencies, you can start gr-gsm by running the python script ./airprobe_rtlsdr.py or load the airprobe_rtlsdr.grc file using gnuradio-companion and set one of the channel frequencies you just found in the frequency field. Don’t forget to add ‘gain’ value again, move back to the frequency field and start pressing the UP/DOWN arrows on your keyboard to start scrolling the frequencies in 200Khz steps until you start seeing some data in your console window. The whole process should look something like this:

Now you only need to launch wireshark from another terminal tab with the following command:

sudo wireshark -k -Y 'gsmtap && !icmp' -i lo

If gr-gsm did his job, you should be able to see decoded GSM traffic sniffed by your hackrf.

It started as a small challenge. “I challenge you to make a Base-Station image for embedded devices” dared me my friend Simone, and I decided he is right and it’s time for a BladeRF Base-station image targeting the armhf architecture. While googling on the subject, I found others struggling with same problems I did, and I also found some developers asking “why even do it [compiling BTS for embedded]”. My answer to those developers will be:

(a) Because we can!

(b) Today’s embedded devices are more powerful than yesterday’s BTS. We have Quad-Core with 8GB-RAM ARM devices, perfectly suitable for running a base-station.

(c) HackRF, BladeRF, USRP, and other RF gadgets alike, are the perfect combo for embedded systems, and even osmo-trx is specifically crafted for ARM devices.

Starting the build process, I initially went with those two tutorials and followed all steps – including compiling uhd – just for the fun of it (even on a 32 cpu’s machine its time consuming), and got everything working, but the image size grew to a monstrous 3gb. I decided to make a separate image with the binaries only, which was a reasonable 1.3gb big. But then I decided to do it the right way – make debian package for each project, and thus build myself a really tiny image using debootstrap and my packages. Coming from Arch Linux, I’m not a big fan of debian packaging, so there is still plenty of room for improvements. Once I packaged everything, I ended up with an armhf image I can chroot-to from most of my ARM-based devices, and enjoy running Asterisk, OpenBTS, Yate, YateBTS using my HackRF or BladeRF from mobile. Here is how you can do it yourself in 2 steps:

get the sources to build armhf packages, including the armhf-specific patches (removing google-coredumper, for example.)

git clone https://github.com/z4ziggy/zebts.git

we’re getting the sources on the host system since chroot/qemu-arm has some weird networking issues (among others)

./build.sh get_src

create ext2 image, 20GB size, and install debian sid on

dd if=/dev/zero of=zebts.build.img seek=20G bs=1 count=0
mke2fs -F zebts.build.img
mount -o loop zebts.build.img mnt
qemu-debootstrap --no-check-gpg --arch=armhf sid mnt ftp://ftp.debian.org/debian/

copy needed files to chroot’ed system and unmount

cp pkg.lst mnt/root
cp -a src mnt/root
mkdir mnt/root/debs
umount mnt

chroot the build system and install build dependencies

./chroot.sh zebts.build.img
echo -e "deb http://ftp.debian.org/debian sid main\ndeb-src http://ftp.debian.org/debian sid main\n" > /etc/apt/sources.list
apt-get update
apt-get install `cat /root/pkg.lst`

build debian packages in a curtain order and install them – this WILL take a few hours

cd /root/src
for d in bladeRF hackrf liba53 airspy osmo-trx yate yatebts openbts smqueue smqueue/SR; do (cd $d; dpkg-buildpackage -b -j32; dpkg -i ../*.deb && mv ../*.deb /root/debs); done
exit

you might have a few left-over processes hanging on your mount. we can safely kill them and unmount

lsof -t mnt/ | xargs kill -9
umount mnt{/dev,}

prepare a debian repository

mount -o loop zebts.build.img mnt
(cd mnt/root/debs && dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz)
cp mnt/root/debs/* debs/
umount mnt

create tiny ext2 image, 1GB size, and install debian sid on

dd if=/dev/zero of=zebts.tiny.img seek=1G bs=1 count=0
mke2fs -F zebts.tiny.img
mount -o loop zebts.tiny.img mnt
qemu-debootstrap --no-check-gpg --arch=armhf sid mnt ftp://ftp.debian.org/debian/

bind the debs/ directory to where we will chroot next

mount -o bind debs mnt/mnt

chroot the tiny image, install our packages and cleanup

./chroot.sh zebts.tiny.img
echo -e "deb http://ftp.debian.org/debian sid main\ndeb-src http://ftp.debian.org/debian sid main\n" > /etc/apt/sources.list
echo -e "deb file:/mnt ./\n" >> /etc/apt/sources.list
apt-get update
apt-get install airspy bladerf bladerf-firmware-fx3 bladerf-fpga-hostedx115 bladerf-fpga-hostedx40 hackrf liba53 openbts osmo-trx smqueue yate yatebts sipauthserve asterisk
apt-get clean
exit

you will have a few left-over processes hanging on your mount. we can safely kill them and unmount

lsof -t mnt/ | xargs kill -9
umount mnt{/mnt,/dev,}

shrink the image to minimum size

resize2fs -M zebts.tiny.img

Thats it. To test your new tiny ARM image, use

./chroot.sh zebts.tiny.img

You can download my own tiny image from here, but I have to worn you – I will keep it updated only as long as I’ll be using it, which might won’t be long. For history reasons, you can still use the old method for compiling everything yourself (including uhd, gnuradio, openbts, etc) using the build.sh script.

I used Bochs at 2004 for some projects of mine since that was the only way to emulate a complete PC back in the days. The performance was horrible, hardly usable, since all CPU & BIOS commands were emulated in software. Even on the best of hardware, performance was lacking. Fast forward a few years, and Qemu emerges. I was able to emulate most of my favorite OS’s in a snap, with reasonable performance, and once KVM and friends emerged, I was a happy camper. Lately I started working on a new ARM image for some project at work, and I had to build an emulated system. Naturally, I picked Qemu for the job, and used it as follows:

qemu-system-arm -append "root=/dev/mmcblk0p1 rw console=ttyAMA0" -M vexpress-a9 -kernel zImage -sd my.img -nographic

Performance was as expected, but I then remembered the binfmt_misc tricks and I thought to myself there must be nowdays a better way to emulate my image, and I was right. Today we can chroot an emulated image from any host and enjoy almost full capabilities of the host hardware. In the following example, I used an Amazon instance on the cloud with 32 CPUs as a host, and the emulated ARM image was happily utilizing all those 32 CPUs. Here is how:

sudo apt-get install qemu-user-static

This package has all the binaries needed and also registers the correct binfmt_misc enteries for you. We are now ready to build a new ARM system and chroot it:

dd if=/dev/zero of=my.img seek=20000000000 bs=1 count=1
mke2fs -F my.img
mkdir my.mnt
mount -o loop my.img my.mnt
qemu-debootstrap --no-check-gpg --arch=armhf sid my.mnt ftp://ftp.debian.org/debian/

mount -o bind /dev my.mnt/dev
mount -o bind /sys my.mnt/sys
mount -o bind /proc my.mnt/proc

chroot my.mnt
echo -e "deb http://ftp.debian.org/debian sid main\ndeb-src http://ftp.debian.org/debian sid main\n" > /etc/apt/sources.list
apt-get update

Once you exit your chroot (via CTRL-D or ‘exit’), don’t forget to unmount it:

umount my.mnt/{dev,sys,proc}
umount my.mnt

And thats it. Performance and usability is great, since we simply ‘login’ (via chroot) to our image. Enjoy.