Cracked Screen? No problem!

I managed to brake an old Nexus smartphone that I use for some infosec stuff (running Kali Nethunter). Only the touchscreen input broke, I can see the screen pretty good, but can't input anything... so how to unlock the phone?
If you used ADB before on the device (and computer), its pretty simple, just connect your smartphone and fire up your terminal:

$ adb shell input text YOURPIN
$ adb shell input keyevent 66

If you haven't used ADB before you probably can't connect to the device because 1) you need to enable developer settings and 2) you need to allow the computer to connect, both steps need user input.
But there are other ways, like using an OTG cable to connect a USB mouse (duh!). I found this article on Joy of Android mentioning other methods.

NFC Drip

Last year, I gave a couple of talks about data exfiltration and my research using NFC as a covert channel to exfiltrate data. I found that NFC can be used at a much longer distance than I expect.
Much longer.

If you like data exfiltration or want to know more about my NFC research, you can find a video of  my Hack.lu presentation bellow.
(TL;DR I've managed to exfiltrate data from a smartphone NFC radio up to 20 meters and from a NFC Usb dongle from more than 60 meters away!)

Experience with Coinhive

It seems a study found out that around 500 million users are mining crypto currencies without even knowing it.
Can this be the future of the adless Internet?
Is it profitable with a low traffic blog like this one?
I'll be running an experience with Coinhive for a while on this blog and post the results as comments. This means you will be mining for the experience while browsing this blog!

Meanwhile, thank you for your CPU time!

Update:

This experience started in October 18, 2017. Today, November 13, almost a month later I got my first official "complaint" about the mining in a MicLoc comment. Maybe the user has not noticed this post before. In any case, I'm removing the miner and end the experiment (and all ads from the blog). I already have a clear notion on the results:



Today, XMR was trading around 125$. This yielded around 0.035$ a day on my slow traffic website. My monthly adwords revenue is 0.05$

Is the age of the ads in the Internet coming to an end? I don't think so, not yet. There are too many advertising channels, many not miner friendly.
But I'm betting this mining websites will grow exponentially pretty soon.

Retrofitting a LED Display into the IoT

I have a LED panel. I have an ESP8266. Annhmm! LED - ESP!
Kinda works well if you spell it: L E D - E S P! Or maybe not...

Viral pun aside, I had an old LED panel laying around my workshop. It once had uses in one of my old companies, spitting out Forex prices and news. It was pretty cool back then.
I knew it had a RS-232 interface which I have hacked before, but I managed to lost all code for it long time ago. The remote control had batteries inside for years, which is usually not a very good idea. Battery fluids spilled out  everywhere and it was basically useless.
I could fix the remote, replace the rusted contacts, clean up the board and so on...
But why fix when you can retrofit? And why a physical remote when you have a bunch of ESP8266 around?
Let's put this old dog into the IosT.

(Yes, IosT, as in Internet of Shitty Things since I'll not be worrying about security. I can, because I'm just an hobbyist messing around with stuff. And because I work with security for a living. And because I'm lazy. And just because. But if you are a toaster/fridge/door/camera/ manufacturer, please do worry about security... Last thing I need is to be cut offline for a day because a botnet of lawn mowers screws up my ISP)

Anyway, I had lost all documentation on the LED panel and the casing had no brand or any indication of manufacturer. Luckily for me, the panel prints out its model as soon as it boots: AM03127
This made it easier to find some documentation about it.

So I pop open the LED panel and behold two nice contacts on the board marked as TX / RX. Great, I'll just solder some pins to it and use that as an entry point.

But we can't just connect the serial pins on the ESP8266 to the RS-232 port, since RS-232 physical interface works with different voltages.
There are several articles written on how to connect an Arduino to the RS-232 port. I used this excellent article on  ArduinoDIY blog, based on the MAX232, to build my own interface.
I used it since I had all parts that I need to built one in my workshop. If you have a ton of old stuff laying around, you will most likely find a MAX232 or similar IC in one of your old boards.

Since the power plug is also close to the TX/RX location and I had more than enough space to put the ESP-12E and all the support hardware.

In a nutshell, the retrofit involves a power converter to get the 3.3V for the ESP-12 (marked orange), the ESP itself (marked green), the MAX232 interface board (marked blue) and finally the LED Display itself:

Lots of wires going around but it's actually quite simple. It's ugly but out of sight.

As for the software, on the ESP side, I just cannibalized the WiFiTelnetToSerial Example, a transparent UART to Telnet Server made by Hristo Gochkov.
On the client side, not wanting to go through the specs all over again, I used Christian Sullivan toledo, which has most of the stuff implemented for my needs.
I just needed to patch the code so it prints to stdout instead of a serial connection.

(UPDATE: you can now fetch the working code at github without the need for patching, thanks Christian)

Here's the patch for version 0.0.4.3 which adds a --stdout flag:

--- orig/toledo.py    2008-04-14 11:57:12.000000000 +0100
+++ toledo.py    2016-10-26 15:15:38.920431334 +0100
@@ -59,6 +59,7 @@
     global _version
     global _output
     global _debug
+    global _stdout
    
     _port       = "COM7"
     _message    = "snicklfritz982342"
@@ -79,9 +80,10 @@
     _version    = "0.0.4.3"
     _output     = 0
     _debug      = 0
+    _stdout        = 0
   
     try:
-        opts, args = getopt.getopt(argv, "hvof:s:l:m:p:c:", ["help", "raw=", "version", "output", "font=", "sid=", "line=", "message=", "port=", "intro=", "exit=", "speed=", "bell=", "color=", "date", "time", "link=", "page=", "runpage=", "debug"])
+        opts, args = getopt.getopt(argv, "hnsvof:s:l:m:p:c:", ["help","stdout", "raw=", "version", "output", "font=", "sid=", "line=", "message=", "port=", "intro=", "exit=", "speed=", "bell=", "color=", "date", "time", "link=", "page=", "runpage=", "debug"])
     except getopt.GetoptError:
         usage()
         sys.exit(2)
@@ -90,6 +92,8 @@
         if opt in ("-h", "--help"):
             usage()
             sys.exit()
+        if opt in ("-n", "--stdout"):
+            _stdout = 1
         if opt in ("--raw"):
             _raw = arg
             toraw()
@@ -369,6 +373,7 @@
     print "                    and XOR checksum"
     print "-m (--message=)   Set the desired message (call this flag before output)"
     print "-o (--output)     Output to sign (call this flag last)"
+    print "-n (--stdout)     Only print command, no serial connection"
     print ""
     print "-------------------------------------------------------------------------"
     print 'example: ./toledo.py --link="ABACAB" --output'
@@ -379,6 +384,9 @@

 def serout(finalMessage):
    # set up serial port
+    if (_stdout == 1):
+        print finalMessage
+        return
     ser = serial.Serial(_port, 9600, timeout=3)
    
     # clear out the buffer 

After making sure the ESP-12E is working and has an IP address (in this case 192.168.0.101) , just pipe the toledo.py output to the telnet port:

./toledo.py --stdout -f 2 --message='I can haz ESP' -c rainbow --page=A --output | nc 192.168.0.101 23

All in all, it's not a complicated hack and it's pretty much generic, you could control any other RS-232 based hardware you have using a similar setup.

Sorry for the long post, here's a potato:

Wait, that's not a potato. It's one of the first messages someone left on the board. A news feed.
No, its a live snapshot of my LED - ESP board. And the live video is here:
http://kripthor.zapto.org:8081/video
Also, at kripthor.zapto.org:8023 lives the direct serial interface to the board.
If you reached this far in the post and you want to test it out, you can send serial commands to serial interface and watch the results in the live feed.
Go ahead, send me a message (I'll probably regret this...). You can patch and use toledo.py and pipe it via netcat as the example bellow:

./toledo.py --stdout -f 2 --message='I HaXoR L33T' -c rainbow --page=A --output | nc kripthor.zapto.org 8023

ESP8266 Jamming

This weekend I finally managed to make time to play around with some ESP8266 based boards I had laying in my garage. I wanted to try and use them standalone, i.e., without any other micro controller like an Arduino or a RPI.
Also, for those of you that don't know my mindset, I was obviously wondering about the raw packet injection capability of the thing! Obviously...

Well, using Arduino IDE 1.6.5 and the additional board manager to program the ESP8266 chip, I made a small program to spam the aether with random beacon frames. It's mostly harmless, but it shows packet injection is working just fine.

I couldn't resist to make a small portable gadget just for the kicks:

WiFi Beacon Jam

(I know that powering the thing with a 9V battery is not a very smart thing to do, I made do with what I had in my garage. It's basically just the ESP8266, an external antenna and a battery)
 
It has only two functions: on and off. :)
Here's the result in my phone WiFi scanner, seems like a christmas tree:

As I said, this is mostly harmless. It's not a *real* jammer. But I can easily imagine pretty interesting times ahead with these little chips.
Possibilities are, as they should be, limitless!

Anyway, it was a fun weekend project.
You can fetch the code at GitHub here (warning: lazy code ahead)!

Android Kolme

Its been a while since I post anything security related. Mostly because since I work in security I tend to publish hobbie related stuff.
So here's an interesting joint research I was involved with Marco Lux from Curesec.
We investigated the source code of the Android Operating System and its default apps.
It was real interesting, to say the least.
Today we released some details of our findings about CVE-2013-6272 and another one unassigned yet. Basically, did you know an app doesn't really need permissions to make a phone call from your device? ;)

Without going much into details, which you can find here and here, lets just say something is broken in Android. Of course, I guess we all know it deep inside...
Don't get me wrong, I love Android, own a few and I think it's a great OS from the user perspective. The point is that someone, sometime will have to take security more serious in such a widespread mobile OS. Or not...

What do you think about it?

MicLoc V2

I'm happy to announce that MicLoc is getting its own page!

Due to several requests and incentives I decided to revisit MicLoc and I'm currently working on another prototype. This time, however, I will be documenting the process and releasing all software and hardware plans.
You can follow the developments in this blog, under MicLoc, or directly via link.
As always, suggestions are most welcomed!


My thanks to everyone that showed interest/commented/suggested modifications!

Arduino MicLoc or an Acoustic Location System

(update: MicLoc is further documented here)

I always liked the general concept of signal triangulation. I always wanted to write some software related to this. Maybe even design some hardware. We see it countless times in movies as a standard way to catch the bad guys. So as I studied through the various techniques of triangulation, trilateration, multilateration, I came across with Acoustic Location. Acoustic location methods use sound to determine the distance and direction of something and sounded perfect (pun intended) for my intents, which will became clearer later on.

In order for this to work I needed least 3 input sources which I strategically placed in my backyard. (you can see the rain protection mechanism in the photo)

If you have a stereo mic line in your PC, you already have 2 input channels, but you can't have 3 mics in 2 channels... So I went on and designed a multiplexing circuit with a 555 timer, a JK flip-flop and a 4066 digital switch (which I had readily available) to connect up to 4 mics sharing the mic input. If you sample at 44.1khz from the soundboard, divide bandwidth by 2, you get around 22 samples per millisecond. The speed of sound is around 334mm/ms so the setup should give some results... but it was a big FAIL!

That's because switching from theory to practice is a nasty business. The switching circuit introduced way too much noise to be useable and I ended up loosing too many samples to have any kind of decent precision.

So I went on to plan B...

Arduino MicLoc

Arduino has some cool features, one of them being the ADC, which allow us to sample analog signals from some source. I wanted to sample the microphones output at a pretty high sampling rate, so I started to investigate the limits of the ADC.

The ADC clock is 16 MHz divided by a prescale factor. The prescale default value is set to 128 (16MHz/128 = 125 KHz) in wiring.c. A conversion takes 13 ADC clocks, so the sampling rate is about 125KHz/13 or 9600 Hz. But you can mess around with the prescale factor, which allows you to sample at a much higher rate, which is essential to proper sound location. The setup is not complicated, despite all the wires. I have 3 microphones connected to 3 2N3904 based amplifier and feed into 3 analog channels (A0,A1,A2) on the arduino nano. A temperature sensor was also added.

The arduino samples each of the channels in turn and if the value (i.e. sound intensity) is above a certain threshold it records it. If the 3 mic are above the threshold within a certain time frame, the arduino write them out to the serial port. I wrote a daemon the is listening for this data to come in from the serial line, and then does its magic, using some fancy math with  the speed of sound, temperature, time difference between the samples, mic position and sample rate. After that, it spits out the most probable geographic position of the sound source in kml, which I directly connected as a network source to Google Earth and ended up with a realtime passive acoustic locating system.

You can see the mic positions on the satellite image, on the left. The Shot 1,2 and 3 are the actual location where I shot a BB gun and the red icons is where the Arduino MicLoc estimated the location of the shots. 

I was surprised with the accuracy of this project, given that I worked on in for a weekend and extra cheap materials I used. I believe a sub meter precision shouldn't be very hard to achieve, adding some more mics, better quality amplifiers and a little software tunning.

So why MicLoc? I was pretty sure the local hunters are hunting too close to my house. I just wanted to actually see where they were shooting, in realtime!

Oh, and because MicLoc is cool.