Didier Stevens

Monday 2 November 2020

Quickpost: Portable Power

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I did some tests to generate electricity (230V AC) with a portable 12V battery (well, it’s 10 Kg).

I have a 12V VRLA battery with a capacity of 35,000 mAh. That’s 12V times 35 Ah = 420 Wh. Or equivalent to a 116,667 mAh (420,000 mWh / 3.6 V) USB powerbank.

Charging this 12V battery with a 12V battery charger connected to a 230V power outlet takes almost 7 hours (6:57) and requires 0.49 kWh. That is measured with a plug-in electricity meter with a .00 kWh precision. And I’m working under the assumption that the power requirement of the electricity meter is so small that it can be neglected.

Then I use this fully charged battery to power a 230V 150W halogen lamp via a 12V DC to 230V AC power inverter (modified sine wave).

It runs for 2 hours (2 tests: 2:01 and 2:03) and consumes 0.30 kWh.

Of the 0.49 kWh energy I put into my system, I get 0.30 kWh out of the system. That’s 61%, or a bit better than half of the energy I put into the system.

The main phases where I expect the energy losses are occurring, is in 230V AC to 12V DC conversion and electrical to chemical energy conversion (charging); and chemical to electrical conversion and 12V DC to 230V AC conversion (discharging). I believe the highest energy loss to occur in the power inverter.

And with energy loss, I mean energy that is converted into forms that are not directly useful to me, like heat.

Remark that the halogen lamp test stopped after 2 hours, because the power inverter stopped converting. The battery voltage was 11.5 V then, and I could still draw 1 A at 11.5 V for an hour (I stopped that test after 1 hour).

Next I’m going to try out a 12V to 5V adapter and power some USB devices.

Monday 28 September 2020

Quickpost: USB Passive Load

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I just received a USB passive load. It’s basically 2 resistors connected to the USB power wires in parallel, each with a switch in series:

It can draw approximately 1, 2 or 3 amps (depending on switch positions) from a 5 volt USB source.

The resistors can dissipate 10 Watts, and will become very hot.

The resistor for 1 amp (4,7 ohms, tolerance 5%) maxed-out my FLIR One thermal camera (> 150 °C), but I could measure around 220°C (that’s close to 451°F) with another thermal imaging camera.

The second resistor (2 amps: 2,2 ohms, tolerance 5%) maxed-out that other thermal camera too: this one got hotter than 280°C.

I’m referring to 451°F, because presumably, that’s the temperature to ignite paper. Something I’ll have to test out in safe conditions.

I also measured the resistors, and they are well within tolerance:

Here is a short thermal imaging video of the first resistor heating up:

Quickpost info

Sunday 2 August 2020

Videos: Defective USB Cable

Filed under: Hardware,video — Didier Stevens @ 0:00

When I had issues with my portapack, it took me some time to remark that these issues only happened with a particular USB cable.

The SDR would work fine, and then when I would try to record or playback, the screen would turn dark.

You can see this in the following video:

What is happening, is that this particular USB cable is electrically defective: the voltage drop is too large, due to the abnormally high resistance of the cable. The portapack doesn’t receive enough power, and starts to malfunction.

In the following 2 videos, I perform various tests with that defective cable:

Videos on my video blog (with some info on the devices I used):

Wednesday 2 October 2019

Shark Jack Capture File

Filed under: Hardware,Networking — Didier Stevens @ 0:00

I have a new toy: a “Shark Jack“. It’s a small device sold by Hak5 that performs a nmap scan (-sP) when plugged into a network port (that’s the default “payload”).

In this blog post, I’m sharing the network capture of a scan performed in this “test environment”:

The device (small black box, almost square) between the Shark Jack (SJ) and the router is my “Packet Squirrel”: a simple network capture device.

A couple of observations:

  1. The SJ was tested with its original firmware (1.0.0)
  2. The SJ will randomize its MAC address
  3. The SJ performs 2 full DHCP handshakes prior to the nmap scan
  4. The SJ listens on port 53 (tcp and udp) using dnsmasq (observed while scanning)

Example of different MAC addresses after before and after reboot:

root@shark:~# ifconfig
eth0 Link encap:Ethernet HWaddr 2E:AF:43:F2:3E:22
inet addr: Bcast: Mask:


root@shark:~# ifconfig
eth0 Link encap:Ethernet HWaddr 86:72:96:71:C3:3C
inet addr: Bcast: Mask:


And it can get quite hot while charging, as can be observed in this thermal image:

shark_jack_capture.zip (https)
MD5: 9E5C1187D64A6EC7284C06464E791F01
SHA256: 5153F5C7B559BEC1539B0395F97C5852064D7ED9309B837F11A9381EA6ED4C88

Monday 3 December 2018

Quickpost: Developing for ESP32 with the Arduino IDE

Filed under: Hardware,Quickpost,WiFi — Didier Stevens @ 0:00

I have a couple of ESP32’s that can also be programmed with the Arduino IDE, provided the necessary board manager is installed:

After starting the IDE

I open the preferences:

And add the board manager URL for the ESP32 (https://dl.espressif.com/dl/package_esp32_index.json):

And via the Tools menu I launch the Boards Manager:

And install the ESP32 board manager:

And then I can select the right board (ESP32 Dev Module):

Then I can connect my ESP32 board to my Windows machine, and it will complain about missing drivers:

I install the CP210x drivers:

Then I can select the right port in the Tools menu:

And now everything is ready to program my ESP32. I will start with the WiFiScan example:

Which can then be compiled and uploaded to the ESP32 board:

Once it is uploaded and running, I can connect to the ESP32 board via the serial monitor:



Tuesday 19 September 2017

Quickpost: Creating A Simple Flow Graph With GNU Radio Companion

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

If you installed GNU Radio and want to know how to create the Flow Graph I used to test my SDR, follow along:

Start GNU Radio Companion, and create a new WX GUI file:

You will see 2 blocks, Options and Variable:

Notice that the ID is “top_block” (that’s the default), and that the Generate Options is “WX GUI” (QT GUI is the default).

Variable is a block that defines a variable for the sample rate: samp_rate. By default, it’s 32k (32000), but that’s too small.

For my RTL-SDR, I will use 2 MHz (2000000 Hz). Double click the Variable block, change the value and click OK:

Now we will add a block that represents our SDR as a source of data. Go to the right menu and select “RTL-SDR Source” (you can click the search button on the toolbar to search for this block).

Drag this block into the flow graph:

Notice that the title of this block is in red: that’s to indicate that there is an error with this block (it’s not connected). We will fix that soon.

Next select the “WX GUI Waterfall Sink” block:

Drag this block into the flow graph:

Hover with your mouse over the blue port of block “RTL-SDR Source”, the word “out” will appear:

Click on the blue port:

Now hover with your mouse over the blue port of block “WX GUI Waterfall Sink”, the word “in” will appear:

Click on the blue port:

An arrow connects the 2 ports, and the titles turn black (no errors).

The default frequency of block “RTL-SDR Source” is 100 MHz. I will tune this to a local FM radio station at 100.6 MHz. Double click the “RTL-SDR Source” block, and edit the Ch0 Frequency: 100.6e6 is 100600000 or 100.6 MHz (e6 is the exponent notation for 1000000, 6 zeroes).

We can now save the flow graph. A flow graph has to be saved before it can be executed, if it is not saved, GNU Radio Companion will display a save dialog box when you execute the flow graph.

The extension for flow graph files is .grc:

A .grc file is an XML file:

Now we can execute the flow graph by clicking on the Play button:

When everything works fine, you should see output like this:

The green bands represent the signals of broadcast stations, and in the terminal you can see that a top_block.py program was generated and executed, and that GNU Radio is able to connect to the SDR device and get data.

GNU Radio Companion creates the top_block.py program (the name comes from the ID in the Options block), and executes it with GNU Radio:

If GNU Radio is not able to get data from your SDR device, it will generate null values: the waterfall plot will be uniform blue, and the terminal will report errors:

You can stop the Python program from running by clicking the stop button:

If there are errors in your flow graph, you will not be able to click the play button. Click the error button to get more info:



Quickpost info

Monday 18 September 2017

Quickpost: GNU Radio On Windows

Filed under: Hardware,Quickpost — Didier Stevens @ 20:43

I’ve been using GNU Radio & GNU Radio Companion with the GNU Radio Live SDR Environment, but now I’ve switched to GNU Radio on Windows (I’ve seen posts that it’s stable now).

The installation was easy, I downloaded the GNURadio x64 binaries and proceeded with a default install:

Next, install drivers for my HackRF One and RTL-SDR with Zadig.

Zadig can auto-update:

When I plug in my HackRF One, no driver is installed automatically (Windows 10), I use Zadig to install a WinUSB driver:

The same for my RTL-SDR, although the name of the device is “Bulk-In, Interface (Interface 0)”. A driver was automatically installed after connecting it (RTL2832UUSB), but I need WinUSB here too:

If you don’t see your device listed, make sure that all devices are listed:

Now I can use GNU Radio on my Windows machine. I start GNU Radio Companion, and get a one time warning about xterm missing, that I can ignore:

A quick flow graph connecting my RTL-SDR (tuned to a local FM station) to a waterfall plot shows my SDR is working (the terminal output confirms that too):

If GNU Radio is not receiving I/Q data from your SDR, the waterfall plot will be pure blue, and you will see a message attesting to that in the terminal.


Quickpost info

Sunday 17 September 2017

Quickpost: Update: Infinite Control For Bash Bunny

Filed under: Bash Bunny,Hardware,My Software,Quickpost,Update — Didier Stevens @ 16:39

This is an update to my Bash Bunny payload Infinite Control: it sends a CONTROL keypress every 10 seconds. I changed the LED colors, and if you uncomment line 27 the BREAK key will be used (function key 15, as some people suggested).

You can find it on HAK5’s GitHub Bash Bunny repository too.

# Title:         Infinite Control
# Author:        Didier Stevens (https://DidierStevens.com)
# Version:       0.0.2 2017/09/02
# History:       0.0.1 2017/04/08 start
#                0.0.2 2017/09/02 changed LED colors, added BREAK
# Hit the CONTROL key every 10 seconds in an infinite loop,
# while blinking the CYAN LED with every keypress.
# Can be used to prevent a machine from sleeping or auto-locking.
# Some users have suggested to hit F15 (BREAK) in stead of CTRL.
# This can be done by uncommenting line #INFINITE_KEY=BREAK.
# WARNING: Do not type on the machine's keyboard while this script
#          is running, or your keystrokes might become commands,
#          for example CTRL-Q: Quit
# Cyan ..............Hitting CONTROL key
# Yellow Blinking ...Sleeping
# Red Blinking.......Wow! We broke out of the infinite while loop!



# infinite while loop
while true
	sleep 1
	sleep 9

# this code will never be reached


Quickpost info

Saturday 16 September 2017

PyBoard LCD160CR Text Scrolling Window 8

Filed under: Hacking,Hardware — Didier Stevens @ 13:38

I used my PyBoard microcontroller + LCD160CD screen as a name tag at 44CON.

I had to do some research, as I could not find example code to get the text scrolling working. The key to the solution was to set the direction to 2 (-x).

This is the code I put in main.py:

# main.py -- put your code here!

# Didier Stevens 2017/09/13 https://DidierStevens.com

# https://docs.micropython.org/en/latest/pyboard/library/lcd160cr.html
import lcd160cr

# http://micropython.org/resources/LCD160CRv10-refmanual.pdf page 7
def LCDVector(frame_mode, direction, step):
    return frame_mode << 15 | direction << 12 | step

# http://micropython.org/resources/LCD160CRv10-refmanual.pdf page 8
def LCDFont(pixel_replication, soft_scroll_flag, transparency_flag, font_number, horizontal_bold_offst, vertical_bold_offst):
    return pixel_replication << 8 | soft_scroll_flag << 7 | transparency_flag << 6 | font_number << 4 | horizontal_bold_offst << 2 | vertical_bold_offst

lcd = lcd160cr.LCD160CR('X')
lcd.set_scroll_buf('Didier NVISO.BE ')
lcd.set_scroll_win(8, 0, 0, 128, 128, LCDVector(0, 2, 4), LCDFont(7, 0, 0, 3, 0, 0), 0x0000, 0xFFFF)

Monday 24 April 2017

Bash Bunny PDF Dropper

Filed under: Hardware,My Software,PDF — Didier Stevens @ 0:00

More than 5 years ago, I worked out a technique to drop any file on a machine which has removable storage disabled. The technique used a Teensy to simulate a keyboard and type out a pure ASCII PDF to notepad. The PDF, containing an embedded executable, can then be saved and opened with a PDF reader to extract the embedded file.

I recently re-visited this technique with my Bash Bunny (it can also be done with a Rubber Ducky):

First I create a pure ASCII PDF file with an embedded executable using my make-pdf-embedded.py tool:

make-pdf-embedded.py -f fi80 -t -n Dialog42.exe.txt Dialog42.exe Dialog42.pdf

Option -f select the filters to use: f to deflate (zlib compress) and i80 to use hexadecimal lines of 80 characters to encode the compressed executable file in pure ASCII.

Option -t for pure text.

Option -n to choose the name used in the PDF document for the embedded file (files with extension .exe can not be extracted with Adobe Reader).

And then I create a Ducky Script script from the PDF with my python-per-line.py tool:

python-per-line.py "Duckify({})" -o payload.duck Dialog42.pdf

The payload.duck file can then be installed on my Bash Bunny, referenced from a payload.txt bash script like this:




QUACK STRING notepad.exe

QUACK switch1/payload.duck

Here is a video showing my Bash Bunny dropping this PDF file:

Next Page »

Blog at WordPress.com.