Hacking with a rubber duck

On the weekend I had the pleasure to present at CrikeyCon 2015. I want to thank everyone involved including the organizers; the other speakers; our wonderful MC, Patrick Gray from Risky Business; and of course the attendees!

This year I chose something a bit different to present on, the Hak5 Rubber Ducky. I started with two (and one failed,) demonstrations in the morning before setting up in the events area to show off some more advanced demonstrations.

As promised, I am posting up my content for everyone to make use of it.

Firstly, the PowerPoint slides can be downloaded here, or viewed on SlideShare here (and below).

I have setup a separate page on this side, Rubber Ducky, where you can find the scripts/payloads and a description with each.

There are a number of links which I found to be extremely useful.

If you have any questions, comments, or feedback please feel free to leave a comment, contact me via this site or send a message to me on Twitter.


Revisiting Syslog in PowerShell

I often wonder, as I am sure most developers do, if people ever actually read and use the code that I post online. Was it helpful to them or was it useless? Did they use it for something interesting? One piece of code which I know people do use, is my PowerShell SYSLOG code.

A few weeks ago, a user opened my very first GitHub issue! This issue appeared at first to be simple, but as the user and I started to delve into the complexities of the various SYSLOG RFCs, I realized it was far from it.

Before we get into the issue, the code and the resolution, it is worth highlighting that there quite a few IETF RFCs that relate to SYSLOG messages. The two primary ones being:

  • RFC 3164 - BSD SYSLOG. This actually wasn't an IETF standard.
  • RFC 5424 - IETF SYSLOG. This is a IETF standard. This obsoletes RFC 3164.

There are also RFCs:

  • RFC 3195 - Reliable Delivery for SYSLOG
  • RFC 5425 - TLS Transport Mapping for 
  • RFC 5426 - Transmission of SYSLOG Messages over UDP
  • RFC 5427 - Textual Conventions for Syslog Management
  • RFC 5848 - Signed Syslog Messages
  • RFC 6012 - Datagram Transport Layer Security (DTLS) Transport Mapping for SYSLOG
  • RFC 6587 - Transmission of SYSLOG Messages over TCP

I want to send a very big thanks out to the user, DFCH for reporting the issue, helping me understand the RFCs in question and also testing the resulting code.

The Issue

So what was the issue? As DFCH stated:

The Cmdlet send-syslog.ps1 states in its description to send a syslog message as defined in RFC 5424. However the generated timestamp in the Cmdlet incorrectly formats a timestamp when none is specified by the caller, nor does it validate or convert the timestamp if specified by the caller.
— https://github.com/kjacobsen/PowerShellSyslog/issues/1

I will admit that I hadn't ready RFC 5424 or RFC 3164 in a huge amount of detail. As soon as I did it was very obvious that the code was not producing an appropriate timestamp, it also become evident that the overall message I was sending did not meet the RFC specification.

From my analysis, it appeared that I had crossed parts of both RFC 5424 and RFC 3164, ending up with code that wasn't fully complaint to either, and in the long run, not entirely useful.

As DFCH reported, the code didn't not generate the appropriate timestamp, with issues in how it was formatted as well as the precision. Resolving these issues was quite simple, the timestamp could be formatted as recommended by DFCH, this not only resolved the format issue but also increased the precision. Validation of the caller specified timestamp was also easy to implement. I simply changed the parameter to take an object of type DateTime instead of a String. 

But this was just the start of the fixes, as I continued to read and understand the RFCs, I realized my messages were incorrectly formatted as well.

Message Formats

There are two valid SYSLOG message structures as defined in RFC 3164 and 5424. 

Firstly, RFC 3164 specifies the message structure to be the following:



  • PRI - Value based on severity and facility
  • TIMESTAMP - What date and time with format MMM dd HH:mm:ss
  • HOSTNAME - Who is sending the message
  • TAG - Name of the process or program generating the message
  • CONTENT - Obviously the message being sent

Next, RFC 5424 specifies the message structure as:



  • PRI - Value based on severity and facility
  • VERSION - Version of the SYSLOG message (typically 1)
  • TIMESTAMP - What date and time with format: yyyy-MM-ddtHH:mm:ss.ffffffzzz
  • HOSTNAME Who is sending the message
  • APPNAME Name of the process or program generating the message
  • PROCID - Process ID of the application or script
  • MSGID - An Identifier to assist in troubleshooting
  • STRUCTUREDDATA - RFC 5424 specifies a method of sending key/value pairs
  • CONTENT - Obviously the content of the message

One thing to note with RFC 5424 is that the majority of the fields are optional, you still need to send something to ensure the correct layout however, so the nil value "-" is sent. I should also point out that the RFC states that the CONTENT section at the end is completely optional. If nothing is sent, you don't need to even send the nil value. 

My original code on the other hands, was sending messages with the structure of:



  • PRI - Value based on severity and facility
  • TIMESTAMP - What date and time with format: yyyy:MM:dd:-HH:mm:ss zzz
  • HOSTNAME - Who is sending the message
  • CONTENT - Obviously the message being sent

How did this happen? 

Well, there are a few reasons why this occurred, in no particular order.

  1. I borrowed some of the logic and ideas from other .Net and PowerShell code samples
  2. I didn't read either RFC
  3. The SYSLOG servers I tested against were not stringent in their rendering of messages received.
  4. I referred to Wikipedia when I was checking that my messages were correctly formatted.

In hindsight, the biggest mistakes were using Wikipedia as my guide, and not testing against a more RFC compliant server.

Using Wikipedia as a source for developing compliant code is probably a bad idea, on this occasion it was a great learning experience. Previously the SYSLOG Wikipedia article did not correctly describe the layout and formatting of the full message, crucially missing out the information about the TAG field. The article has been updated since then with corrections ensuring that it is more understandable. It should be noted however that overall, the Wikipedia article is still focused on RFC 3164 and not 5424.

Let’s look at how we clean-up the code.

Additional Parameters

To ensure that we have enough information to support RFC 5424, I needed to add some additional Parameters (which are not mandatory). These include ApplicationName, ProcessID, MessageID, StructuredData and a switch RFC 3164.

The switch RFC 3164 will simply tell the code to send a message in the RFC 3164 format, instead of sending it via RFC 5424 which is its default.

Hostname Generation

Previously, if the hostname parameter was not specified in my code, I simply used the hostname.exe. Whilst there isn't any problems with this, however RFC 5424 actually specifies in some detail how the hostname field should be determined:

  1. The FQDN of the server
  2. A static IP address
  3. The hostname of the server (Windows will always have on of these)
  4. Dynamic IP address
  5. A NILVALUE (-)

I have updated my code to generate the hostname component of the SYSLOG message via the first 3 steps.

Application Name

The Application name can be a little difficult. Typically from within a function we can determine the name of the script which is calling the function via 2 properties of the $myInvocation variable: ScriptName and PSCommandPath. I have used ScriptName with success in the past, and hence decided to use it again. There is one thing to note, if I am sitting at a console and call send-syslogmessage, then ScriptName will be null, and if that is the case, we will simply use “PowerShell”.

Process ID 

The Process ID is new requirement to ensure RFC 5424. We get this simply from the $PID global variable.

Message ID and Structured Data

These two will always be user specified, if the user doesn't specify them, then send the default RFC 5424 nil value of "-".

Message Generation

Now that we have all of the information required for either RFC, we can now look at message generation. When it comes time, I simply have an ‘if’ statement that controls which format we want to use. The script will then format the timestamp and message accordingly.

Message generation looks like the following:

For RFC 3164, I fixed up the timestamp, and also added in the application name. For RFC 5424 there are some significant changes. I now correctly include the SYSLOG version (1), and then included the corrected timestamp, application name, process ID, message ID and structured data.

The Future

If there was a demand, I would be interested in extending the CMDLet to support the transmission of messages via TCP, as well as sending signed messages. Right now, I don't have a need for such things.


Now that all of those changes have been completed and tested, I have pushed the changes up to the PowerShellSyslog GitHub repository.

I want to thank DFCH again for raising the issue and helping me through the development of the fixes.

Kieran Jacobsen

First Impressions: MSI GS30 Shadow Pt3 - The Dock

In this final post, I will talk about the GS30's dock and my overall thoughts on its performance.

Whilst the laptop is cool, everything is really talking about the dock. As I mentioned earlier, the dock consists of a PCI Express x16 slot, a 450 watt power supply, a KillerNIC, audio connectors (speakers and microphone), stereo speakers with sub-woofer and 4 USB3 ports. 

You can install any NVIDIA or ATI card you want into the dock, and from any manufacturer. It should be noted though that MSI has stated that all of their cards will work within the dock. I chose an MSI NVIDIA GeForce GTX 970 not only on the reviews, but also due to the fact I knew I would receive suitable support in such a configuration. The power supply in the dock has two 6/8 pin power plugs to supply power to whatever card you end up selecting. There is also a fan on one side to assist in keeping everything cool.

It is worth noting that MSI wasn't the first to come up with the idea of strapping a desktop graphics card to a laptop. Currently the other well-known vendor is Alienware. Alienware first offered the graphics amplifier to their 13 inch series, and in the latest generation it is available in the 15 and 17 series. MSi claim that the biggest difference between the GS30 and the Alienware is that their dock is a PCI Express x16 solution, whilst the Alienware is only x4. There is a significant bandwidth difference between PCI Express x16 and x4, however these claims haven’t been independently verified. 

Connecting to the dock is a fairly straight forward process. Shutdown the laptop, place the laptop in the cradle and pull the handle to bring the two together. The locking process also ensures that there is now way the laptop could easily come away from the dock. For those who are wondering, the dock connector looks pretty much like a PCI Express connector. To undock, simply shutdown and unlock then push the handle to eject the laptop. You need to shut down, you cannot simply put your laptop to sleep or hibernate. My theory of how everything is working internally, and this is just conjecture, is that when connected, the dock is disconnecting the Intel Iris graphics and the Atheros Ethernet controller. 

I chose to install my Western Digital 2TB Black Edition drive in the dock. This drive has all 240 of my Steam games, and has worked well for me in my previous system. Installation of the drive was also extremely easy, I recommend installing the hard disk prior to installing the video card.

The audio options on the dock are rather disappointing. Whilst it is great to see (hear) the stereo speakers and sub-woofer in the dock, I would have much rather seen a fully fledged sound card included. I previously used optical out to a set of Yamaha speakers, now I am going to have to go back to the drawing board because the GS30 dock only provides a standard headphone/speakers connector.

I have been extremely impressed by the performance of the GS30, dock and GTX970 combination. Whilst I haven’t spent much time playing games, only FireFall and BioShock Infinite, I can confirm the performance is quite remarkable. I was not disappointed running both games with their video settings maxed out. The fans on the laptop will ramp up during this time, but once again, it is nothing too serious.

For a detailed performance breakdown and benchmark, check out the review by Hexus here.

Transforming a thin-and-light 13.3in laptop, the bundled GamingDock opens the door to greater storage, better connectivity, improved audio and a far superior graphics experience.
— http://hexus.net/tech/reviews/laptop/79397-msi-gs30-shadow-gamingdock/?page=16


Overall this is an exceptional laptop, be it as a work PC running virtual machines or visual studio, or at home as a gaming machine. This is a great work machine and a great home machine. I would definitely recommend it to people!

Whilst the laptop would probably struggle competing on its own against the likes of Alienware or the HP Omen, or even a business oriented device like the HP EliteBook Folio, when combined with the dock, it becomes one hell of a system. 

MSI have done an amazing job, their engineers have created something exciting, unique and quite revolutionary. I will be very interested to see how they continue to develop and expand upon this concept in the coming years. Hopefully in 2 years when I am looking for a new laptop, they will have resolved some of my gripes and filled in some of the missing features.

The GS30 Shadow is definitely one of the more interesting laptops we’ve seen, and for those that don’t need to have a ton of gaming power on the go it offers a nice blend of mobility with the option to hook up to a dedicated display and GPU at home for serious gaming.
— http://www.anandtech.com/show/8817/msi-announces-gs30-shadow-laptop-and-gpu-expansion-dock



  • True Quad Core i7
  • Docking station
  • Lightweight Ultrabook
  • 16Gb of memory
  • Twin 128Gb SSDs
  • Gaming performance when docked is equivalent to desktop systems
  • Excellent option for work/life balance system
  • All of your data in one place
  • Dock features PIC Express 16x and one SATA 3 port


  • No touch screen
  • No TPM
  • No NFC
  • No KillerNIC Ethernet or WIFI on Laptop, KillerNIC only in dock
  • Screen resolution could be higher
  • Audio options could be better (no optical out)
  • Need external monitor/keyboard/mouse when docked
  • Need to shutdown to dock/undock
  • 3 hours battery life

Improvements I want to see in the future

  • Touch Screen
  • TPM
  • NFC
  • Better audio options in the dock
  • Windows 8.1 pro
  • No Symantec AV
  • Better driver update system

Kieran Jacobsen

First Impressions: MSI GS30 Shadow Pt2 - A powerful ultrabook

Welcome back! Yesterday I introduced the MSI GS30 Shadow, and today I will be talking about the specifics of the laptop and its performance whilst away from the docking station. Tomorrow I will talk about the dock in more detail.

MSI has come at this new approach to empowering gaming notebooks from a different angle from its competition, focused almost solely on value, performance and design in GS30 Shadow and GamingDock. The result is a machine that can be an Ultrabook in your backpack when you need to get things done and a gaming PC at home that can play with the big boys.
— http://www.techradar.com/reviews/pc-mac/laptops-portable-pcs/laptops-and-netbooks/msi-gs30-shadow-1277918/review

Upon unboxing the laptop, there were a few things that caught my surprise. Firstly, it is packed at the bottom, with the weighty dock on top of it. More importantly however, the laptop looks really well designed, and is extremely light. The styling is quite plain, quite utilitarian, but on the whole very nice to see. This is not a garish looking machine like the Alienware laptops which screen “I AM A GAMMING MACHINE” at the top of their lungs, this is a quite but extremely powerfully little creature which doesn’t like the limelight. The GS30 reminds me of my older Dell Latitude crossed with my old Sony VAIO. I wish I could say that this design allows it to blend into a corporate environment, but MSI then decided the GS30 did need to look a little like its Alienware competitors. The front bezel has a white light along the front of it, not a simple little white light, but a long beam of white light which really does take away from the look. You can’t turn it off, dim it or change the colour. It is rather disappointing, and just drains battery in my opinion. 

The GS30 comes with an interesting array of hardware options, featuring an Intel Core i7 (4th Gen) 4870HQ CPU, 16GB of memory and two 128GB SSDs which are in a RAID0 (stripped) set. 
Having a quad core CPU, whilst there are significant reasons to have reservations about putting a such a  processor into a laptop, MSI appears to have pulled this one off quite well. Most people I have spoken to about the GS30 ask me one thing, “is it noisy?”. The answer to this is, well, sort of. The GS30 does appear to have some very efficient and well-designed cooling, however if you place a quad core i7 processor under load, there will still be quite a bit of heat generated that needs to go somewhere. Unlike many other laptops, which become hot to touch under extreme load, the GS30 remains cool. The fans can be loud, these are not the quite fans in your Surface Pro, I work in an office with quite a few MacBook Pros, and the GS30 fans are extremely comparable to those. 

Coming with 16GB of memory is probably suitable for most developers and gamers, however it would have been really nice to have the option for 32GB. I suspect the limitation here is more around the fact that DDR3 modules for laptops max out at 8GB, and there wasn’t the space to offer 4 memory slots, only 2. 

The storage configuration still seems a little bit of a waste for me. Whilst there does seem to be a performance boost, I don’t think it is significant enough overall, but I wonder what the design and cost implications to this one are. I really have to wonder why MSI chose 128 GB SSDs, this does seem to be a very small size, especially for something targeted towards the gamming community. I realise that I have another SATA3 HDD in the dock, but a little more whilst away from the docking station would have been nice. The good news, these drives are replaceable, if you want to touch the warranty void sticker.

The GS30 features a 13 inch, 1920*1200 resolution display with a matte finish. If you like an extremely glossy screen, you might want to look elsewhere. The screen is quite thin, much like any of the high end Sony, Dell and HP laptops, and whilst others have mentioned it seemed “flimsy”, I don’t seem to think it is. This is an extremely nice screen to use and I am very pleased to use it. Viewing angle seems extremely good, and the display is crisp and clear. I do wish for a few things, higher resolution, touch support and a wider opening angle. A higher resolution is always good however it can introduce its own set of issues; touch support seems pretty obvious these days, but it is something you can live without. The last, the opening angle, might seem to be an odd comment, however due to the design of the docking connector, the laptop screen cannot be opened fully and you are limited to about 120 degrees. This isn't a huge issue for me, but I could understand others wanting to open their laptop to almost flat.

The GS30 comes with an Intel Iris Pro 5200 graphics card for times when you are not connected to the dock. This is new from Intel however I have found it to be extremely suitable with a great balance between performance and battery life. I will admit I haven’t tried gaming whilst mobile yet.

There are a bunch of little things that MSI has done really well in the GS30. I really appreciate that internal components like Ethernet, WIFI, Bluetooth and the SD card are not based upon internal USB connections like those found in some low end DELL and HP laptops, and in the Surface PRO. Tight integration with the PCI Express channels provides extremely suitable performance and reliability.

WIFI connectivity is provided by an Intel 7260, and Ethernet is provided (whilst undocked) by a Qualcomm Atheros AR8161. The GS30 doesn’t suffer from the WIFI drop outs suffered by the Surface Pro 1, 2, and 3. My connectivity in the office has improved quite significantly. I am left wondering why MSI didn't package a KillerNIC WIFI and Ethernet controller in the laptop. A significant proportion of MSI’s other devices feature the Killer Double Shot Pro, so why not this one? I thought that would seem pretty logical for their target market, one positive about the use of these two is extremely strong Linux and visualization performance. 

Battery life could be better. The GS30 provides about 3 hours battery life in the limited testing I have performed. This isn't great by any means, but isn't the end of the world.

A quick word on the keyboard. Yes it is back lit, however you do not get any control over the colour, nor are there programmable/macro key support like other MSI laptops. To some this could be a disappointment, however in the grand scheme of things, it is something you can live without.

Now for my big rant. I was quite gutted to see that the GS30 doesn't come with a TPM. I realize that this device is targeted towards gamers, and not the security paranoid let’s encrypt everything crowd that I belong to. This is however 2015, how much effort would have it taken to install one? Seriously, they are tiny chips. I can work around that, but this is the one thing I wish I could get MSI to fix!

Join me tomorrow when I review the GS30's dock, gaming and the performance over all.

Kieran Jacobsen