Monday, 25 May 2015

Enabling an additional screen in a Qubes OS Windows HVM

Enabling an additional screen in a Qubes OS Windows HVM

I recently converted my work laptop over to using Qubes OS; an awesome OS based around the concept of using lightweight VMs to provide enhanced security.
Naturally I added a Windows VM using this handy guide to install and configure a working Windows 7 install so i could run Powerpoint.
Everything worked great until i connected an external monitor; naturally my Qubes desktop expanded to fill the new monitor but my Windows VM was still stuck with a single display window. This is great but i needed a second window so i could view my presentation notes when doing a talk using the built in view in Powerpoint.
At first I thought maybe I could enable this through the ".conf" file for VM but couldn't find any option to enable emulation of an additional screen.
I tried assigning the video adapter hardware to the running VM but all that did was disable my laptop screen.
However I had success configuring it directly in the Windows VM.


  1. Connect up your external monitor to your system - Dom0 should detect and extend your desktop to this display.
  2. Boot your Windows VM and open the device hardware pane. 
  3. Enable The "Standard VGA Graphics Adapter" and reboot the VM.
  4. Test that Powerpoint now detects your screen.
  5. Resize the new window through windows to make it usable
Now you should be able to read your presentation notes while talking!
I highly recommend you give Qubes a go as it's a great idea with lots of advantages when you need to run lots of different applications and OS's on a single computer.

Tuesday, 14 May 2013

Coordinated ATM Heists, and a rant...

Been a while since I posted, have been a bit flat out with lots of multiple projects on different continents.

This story is a great one for those of us in the payments security field.

This is an interesting story in that it was not the card-holder data that was attacked, but the balance and withdrawal limits data that was breached. There is a chance that the payment processors were PCI compliant as these standards are concerned with the protection of card-holder data, not with balances on accounts or withdrawal limits.

This is a good lesson to all payment processors that PCI compliance alone is not sufficient security. You must continually assess and test your payment environment for security vulnerabilities.

Also, countries not using chip-card/EMV should hurry up and join the rest of the world.

Magstripe is a broken technology, it contributed to the above attack (the pre-paid cards were cloned allowing an exponential increase in the losses occured).
EMV/Chip Cards cannot be economically cloned, which reduces the economic impact of attacks like the one above.

Why is a product like this: even feasible in 2013? Almost all payment terminals produced now support Chip/EMV transactions.
$299 for a product that is not PCI compliant, already obsolete and insecure; sounds like the Windows 3.1 of payment terminals...

Wednesday, 13 March 2013

Nice write-up on issues in TLS/SSL

Haven't blogged in a while due to studying for the CISSP certification and working on other fun projects. Amazon EC2 instances are enormous fun to play with, and free to get started with, wish i had this type of stuff when i was in uni.

Came across this great story on RC4 and TLS:
Attack of the week: RC4 is kind of broken in TLS
Cipher suites in the TLS/SSL implementations have been an interesting area of late with a number of attacks being published in the last few months.
A fun thing to do is to scan a website using the TLSSLED shell script and see what cipher suites it supports.
Here's the output for

         Accepted  SSLv3  256 bits  ECDHE-RSA-AES256-SHA
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  168 bits  ECDHE-RSA-DES-CBC3-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  ECDHE-RSA-AES128-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  128 bits  ECDHE-RSA-RC4-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  ECDHE-RSA-AES256-SHA
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  168 bits  ECDHE-RSA-DES-CBC3-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  ECDHE-RSA-AES128-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  128 bits  ECDHE-RSA-RC4-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

The interesting listing in this case is "RC4-MD5", considering the MD5 is considered broken and should have been retired by now. 

Compared this to

    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
Which is in line with FIPS 140-2 Annex A.

Monday, 11 February 2013

Nice attack on an bad implementation of using the Atmel SAM7XC Crypto Co-Processor

This is why hardware key management is so important. In this case the processor contains hardware cryptographic engines yet no dedicated key storage or tamper protection. This means that keys have to be stored in internal Flash or RAM which opens up vulnerabilities allowing keys to be extracted.

A proper secure processor implements dedicated key storage memory combined with active tamper detection. If a tamper event is detected by the processors security sub-system; then the key storage area will be actively cleared preventing key extraction. Examples of these processors include the Maxim USIP, Freescale i.MX258 or the Broadcom BCM5982.

The analysis performed here validates how much implementation matters when designing a secure system.

Monday, 4 February 2013

iOS 6.x Untethered Jailbreak out

Available at:

I recommend checking the SHA-1 hash of the release you downloaded against the provided list (a habit I should get into as well). This can be performed by using OpenSSL:
openssl sha1 <filename>

Interesting that the jailbreak steps are different from the "redsn0w" utility, not having to get the device into DFU mode is great as I muck it up every time and have to reboot.
The installer places a "Jailbreak" icon onto the SpringBoard as part of the process which has to be clicked, i'm interested to know what role this performs in the jailbreak process.

Make sure if you've jailbroken your device to change the your default root password to something you've chosen! we don't want this happening again.

ssh root@<ip of your device>
iPhone:~ root# passwd

Changing password for root.
New password:

and heres a great writeup of what the jailbreak does:

Friday, 1 February 2013

Hooking objective-c internals using the Captain Hook framework.

One of the fun things to do with a Jailbroken iPhone is to install custom themes using the "WinterBoard" application.
This allows you to install themes such as: Auxo which customises the application switcher bar or Boss.ios which alters the whole look of the interface.

How does "Winterboard" work?

The "WinterBoard" application works by "hooking" the existing internal classes using the Objective-C Runtime Library. This library is loaded by all Objective-C applications to support the dynamic features of the language which means that we can utlilise is to perform our own alterations to the OS and applications.
This allows for the alteration of icons, sounds and textures without having to touch the originals supplied with the device. This means that you can alter the device without the risk of breaking the device.

The CaptainHook framework

This is a header file created by Ryan Petrich( to assist with the creation of hooking libraries using the Objective-C runtime. This provides a functions to assist in the setting up of custom hooking code. Documentation is a little scant so hopefully this blog can help you begin to create your own hooks.

Getting started

I've altered the sample code provided at the Github as the function used has been depreciated by Apple
hook source code and a makefile
#import <CaptainHook/CaptainHook.h>
CHDeclareClass(NSString); //set up the Captain Hook Library

//function called when hook is encountered
CHMethod(4, void, NSString, writeToFile, NSString *, path,  
         atomically, BOOL, useAuxiliaryFile, encoding,  
         NSStringEncoding, end, error, NSError **, error) 
  NSLog(@"Writing string to %@: %@", path, self);
  //send received arguments to the original class
  CHSuper(4, NSString, writeToFile, path, atomically,
  useAuxiliaryFile, encoding, end, error, error);

//create the hook
  CHLoadClass(NSString); //setup the class
  //hook the chosen method
  CHHook(4, NSString, writeToFile, atomically, encoding, 

Heres a sample program you can test it with:
link to test program and makefile
#import <Foundation/Foundation.h>
#import <Foundation/NSString.h>

int main(void) {
  NSAutoreleasePool *pool = \
    [[NSAutoreleasePool alloc] init];
  NSString *testString = @"Hello, I am the test string";
  [pool release];
  return 0;


Compiling works on OS X with xCode 4.x and iOS SDK version 6.0 in the default library locations.
Copy the compiled "testhook" and "stringHook.dylib" to your device. SSH in, export DYLD_INSERT_LIBRARIES and then execute "testhook" e.g:
  desktop$ scp ./hooktest ./stringHook.dylib \
root@<device ip>:/var/root/
  desktop$ ssh root@<device ip>
  device # export \
  device # /var/root/hooktest

And you should see:
  2013-02-01 21:40:58.710 hooktest[562:707] Writing string to   
  test.txt: Hello, I am the test string
Which only works for command line apps as export DYLD... does not get performed by SpringBoard

A bit of explanation

The CHMethod function declaration is:
  CHMethod(number of inputs, return type, class name, name1, type1, 
  arg1, name2, type2, arg2 ...(number of inputs));

An easy way to fill this method is to take the method definition, and fill it in left to right e.g.
  [NSString writeToFile: atomically: encoding: error:]
  -(BOOL)writeToFile:(NSString *)path atomically:   
  (BOOL)useAuxiliaryFile encoding:(NSStringEncoding)enc error   
  (NSError **)error
translates to:
  CHMethod(4, void, NSString, writeToFile, NSString *, path,    
  atomically, BOOL, useAuxiliaryFile, encoding, NSStringEncoding, 
end, error, NSError **, error)
We set the return type to void as for the example we don't return anything

The function declaration of CHSuper and CHHook are:
CHSuper(number of inputs, class name, name1, arg1, name2,
arg2 ...(number of inputs)

CHHook(number of inputs, class name,name1,name2,
...(num of inputs)

Other ways of inserting the injection library

Using launchctl seems to be a great way.
launchctl setenv DYLD_INSERT_LIBRARIES "/path/to/dylib"
which can be used for individual SpringBoard apps
or you can insert this plist key into one of the plists in "/System/Library/LaunchDaemons/"
although be careful! i screwed up my SpringBoard.plist editing it which caused the SpringBoard to stop loading(i.e no icons), so make a backup of the file just to be sure.

reload the plist using
launchctl unload <chosen plist>
then reload
launchctl load <chosen plist>

Another easy method is to install MobileSubstrate and copy the dylib to "/Library/MobileSubstrate/DynamicLibraries" and reload the SpringBoard. MobileSubstrate loads all the dylibs in this folder automatically.

Heres another piece of sample hooking code i created playing this stuff:
This changes the status bar each time a touch is detected.

A great use of this hooking in security testing has been recently released by Jeremy Allen which uses it to disable certificate verification.
So play around with it and see what fun you can have.

Sunday, 20 January 2013

removePIE - a tool for disabling ASLR on iOS applications

I've put together this small tool which removes ASLR from iOS applications.

This works by flipping the MH_PIE bit used in the MACH-O header of the application.
Since iOS 6.0 this bit is enabled by default in xcode when compiling applications.

Still works for the iOS 6.1 update, doesn't require resigning of the binary if using the evasi0n jailbreak as i believe signature checking of apps is patched out.