Son Of Sun Tzu

To content | To menu | To search

Saturday 1 April 2017

How to run Xbian off a USB display on a Raspberry PI

The short version

Don't.

The long version

( I've not gone into too much detail, I figure the only people who'll stumble across this are either considering the same solution, or troubleshooting their own attempt )

I had a Raspberry Pi 2, it's a "2+" I think, running Xbian. Xbian is a pre-built version of Kodi, the popular media player that used to be called XBMC. No X server is used, Xbian turns your Raspberry Pi into a media player with relatively little effort.

Having acquired a couple of USB screens over the years I thought it would be useful to connect one of these screens to the Pi, just so something like BBC News 24 or the NFL Network could run in the background to the side of my main monitors, or a Twitch channel.

So I connected a Mimo USB UM710 monitor and rebooted the Pi. This came up as a green screen, which means that the udlfb driver has loaded; and from the command line I can see that I have "/dev/fb0" and "/dev/fb1" - meaning that two framebuffers are available.

However I couldn't find any way within the Xbian interface to direct Xbian to use /dev/fb1, nor any kind of option to specify this in any of its configuration files.

I tried using the con2fb tool to redirect a different console to each framebuffer, directing tty1 to the USB monitor, in the hope that Xbian was starting on tty1 ... but still running "kodi start" from the command line brings up Xbian on HDMI.

I looked at somehow disabling the first framebuffer, but to no avail; the relevant bcm2708_fb driver is part of the kernel, and there's no way to stop it being used. Also I don't know if that functionality is required to generate that graphics that are then sent to the USB monitor using the udlfb driver. I expect that a Raspbian kernel can be compiled that doesn't include this functionality, but I decided that for a relatively simple system, which I'm trying to use in an "plug and play" way as possible, compiling my own kernels was a step too far, especially as I had no idea if the solution would work or not.

Also, ideally, I would be able to switch this device from using the USB screen to an HDMI screen with a few commands.

( As a side note, if you're looking at this in general it's worth researching the "chvt" and "xbmc_send.py" commands online )

On further research it turns out this is a common issue for people trying to extend their use of a Raspberry Pi.

That research did lead to a couple of possible solutions, these are framebuffer copiers, or mirrors, that copy of the output from framebuffer to another. While not ideal, this could work.

Firstly I tried fbcp but that just didn't work.

I set the Xbian resolution down to 480p to match what the USB screen was capable of, but this didn't make a difference.

So I moved on to raspi2fb instead.

This worked up to a point, showing the output of the first framebuffer at the right resolution, and at something like 25 frames a second. While slightly jerky this was more than enough to satisfy my requirement to keep an eye on the channel. Kodi's BBC News 24 plugin worked fine, the NFL Network worked fine at a low enough resolution ... but both the Twitch and YouTube plugins would crash the entire system. As far as I can tell it seemed that if I attempted to display anything above the resolution supported by the USB screen the Pi would just crash and need to be manually restarted. Also the system was now a little flaky in general.

I tried both 1.0 amp and 2.0 amp power supplies with the same result.

In the end I gave up, and decided I'd try something else to get Xbian on the USB monitor.

However having disconnected the USB screen, and tried using the Raspberry Pi on an HDMI monitor again, it's crashed after a few minutes. I'll be seeing if there's some kind of software diagnostics I can run to spot any obvious problems - it feels like something the community will have written already.

So in the end I have a Pi that appears to be broken in some way, possibly a result of how many USB devices I plugged into it at once - suggestions for easy ways of running hardware diagnostics are welcome in the comments below.

Sunday 26 March 2017

Notes on Incident Response from the SC Congress

I had the pleasure of attending the "Do Data Breaches Matter? Mitigating Impact" session at the SC Congress last month ( details here http://www.sccongress.com/london/programme/section/4505/ ).

The panel consisted of:

  • Beverley Allen CISA, Information Security Professional, Independent|
  • Bob Tarzey, Analyst and Director, Quocirca
  • Sarb Sembhi CISM, CTO CISO DPO, Virtually Informed

There were some great points made on incident response, which I've summarised below:

The stages of incident response

The actions that result from an incident being detected and becoming a breach fall into the stages below:

Stage 1 - The company wonders why it's been attacked, is in shock to discover it has been successfully compromised.

Nothing happens during this stage.

Stage 2 - Staff ask "What do we do? What's the plan? Where's the plan?"

A lack of leadership will be shown up here.

Also people will think they know better than the plan and will act independently.

It will be illustrated that the plan has never been tested and does not work in practice.

Stage 3 - Dealing with the breach

I.T. teams are likely to take control of the situation because the compromise will be I.T. based, and they will fall back on, or create, informal processes if no formal processes are available.

Internal teams may make land grabs during incident response, or actively avoid responsibility in order to avoid blame, both responses are counter-productive.

Stakeholders will want updates during the incident and afterwards, this capability should be planned for.

Everyone has a role, even if that role is staying out of the way.

Stage 4 - After the breach has been resolved.

It is important here to review the actions that took place in the previous stage, so that the breach can be learnt from in future. If an ad-hoc response method was used it's extremely unlikely that sufficient information will be available.

While the impact on share price and customer trust can be insignificant over the longer term, don't underestimated the impact on staff morale on the long term viability of their employer, also that scrutiny by regulators and auditors will be intense and ongoing.

Stage 0

Not a term that was used on the day, but looking at the stages above much of the conversation covered what was required before an incident response plan had to be initiated:

Part of thinking ahead is determining who is in charge of the breach response, and who should be contacted, and how.

This is the most important stage to get right, and is the foundation for best practice for all the other stages.

Companies don't have time to be breached, so make time now for your preparation - Sarb Sembhi.

"You have to do all of your thinking up front, test it, and test it again" - Beverley Allen.

 

Hacking For A Career - Drinking From The Firehose

( NOTE - this should have been published six weeks ago, apologies )

A short list of which podcasts to listen to, and which blogs to follow. These are just a few entries to get you started, there's a lot of information out there, learning how to filter it to what is relevant to you is a very useful skill.

Podcasts

Risky Business - particularly the first twenty or so minutes covering the main stories of the last week, but also the interviews tend to be worth your time. Find it here.

SANS Internet Storm Center - released daily, and just a few minutes long, a quick way to be bang up to date with security news. Find it here.

Down The Security Rabbit Hole - good coverage of recent news, or an in-depth look at particular issues. Find it here.

The Silver Bullet Podcast - particularly useful just to get an insight into the "names" from cyber security you'll have seen online or presenting at conferences. Find it here.

Blogs

I went through my RSS reader and pulled out those few blogs that would be the most useful to anyone entering the industry:

For thoughts on penetration testing by working penetration testers try Holly Graceful, Carlos Perez's Dark Operator, and Digi Ninja's blog,

For a wider perspective of information security go to Black Swan Security, Michael Santarcangelo at CSO Online, Naked Security from Sophos, or Brian Krebs.

For regular updates on security news and testing tools, try Darknet. While I've found the quality of entries to vary quite considerably, this seems to be the best resource for quickly reviewing the latest news and a useful way of seeing what's out there.

RSA Roundtable on AI and Automation

I recently had the pleasure of attending a roundtable discussion at the RSA on the future of "AI and Automation" in business, particularly among the so-called "low-skilled" workers. Many ideas were discussed under Chatham House rules, and there were a few of my own which didn't fit into the discussion.

A great deal was discussed, but a couple of highlights that I noted down:

  • The definition of Artificial Intelligence itself is tricky, and mischaracterising Machine Learning as Artificial Intelligence can raise expectations beyond what is possible or necessary.
  • "Switching costs" can be huge, with technology developing so quickly organisations can overlook the cost in resource of moving from one technology requirement to the next when the next move is already on the horizon.

The overall discussion prompted a few thoughts of my own, some points I made, some weren't appropriate to the conversation or didn't fit the timescale, deciding which are which is left as an exercise for the reader:

  • A largely artificial workforce, combined with the ever-present threat of ransomware, leads to some very interesting criminal possibilities.
  • With many employees being replaced by automated processes, or actual robots, there is a correspondingly massive increase in the attack surface that any organisation presents to an attacker? It will be much easier to affect or disrupt an organisation when so many more of its resources are on a network, and interact directly with many of the existing security systems.
  • With regard to Fraud Detection an intriguing difference might be that the increasing use of Machine Learning means success or failure of fraudulent activity is far more predictable than human analysts, therefore will it be possible for particularly smart organised crime groups to test their efforts in a safe environment before trying them out?
  • Alternatively will it be possible to steal and/or download fraud detection methodologies and test them offline for weaknesses, so that organised crime can then guarantee the success of efforts in the real world against known procedures?
  • It feels like too much of a "cyberpunk" idea, but if artificial intelligence is used by more and more organisations to detect fraudulent activity, or for other assessments that benefit the profitability of a business - i.e. determining insurance premiums - can criminal organisations use their own AI technology to determine how to bypass the AI of those organisations that they're attempted to defraud?

In the event that you're reading this, and thinking that these ideas have been covered before, and I should read a particular book or article or author, then please do list them in the comments section below.

Monday 27 February 2017

Everything Wrong With CloudPets

I've just read Troy Hunt's excellent summary of the CloudPets breach, and it got me thinking. I'm a big fan of those "movie snark" YouTube channels, something like CinemaSins where they take a film to pieces and list "Everything Wrong With" it. The same kind of idea struck me about this issue, it is the Suicide Squad of security practice; CloudPets didn't make one error, but made several errors which exacerbated the effects of the others.

Cinema Sins

Referencing CinemaSins mean you should be watching a video with high production values but instead you've just got a text only blog that really needs a livelier theme.... but putting that to one side, I think CloudPets committed twelve "security sins". Did I get them all? And bear in mind I've just read Troy's blog, I've carried out no extra investigation myself.

Firstly - what they did get right - the use of bcrypt. Bcrypt is recommended for password hashes as it includes a salt, and so greatly reduces the feasibility of being attacked using rainbow tables.

However, for what they did wrong, in no particular order:

CloudPets

  • Unnecessary Internet connectivity - I assume the MongoDB just needs to interface with the API, which is what interfaces with the phone apps, therefore the database doesn't need to be Internet facing at all.
  • No firewalling in place - just the fact that the MongoDB was exposed to the Internet, rather than any kind of any host or network based firewall being in place.
  • No database authentication - by default MongoDB does not used a password.
  • Using live data in development - as Troy explains, there's no apparent separation between live and development environments or data.
  • Not protecting your interfaces from known bad actors - while Shodan.io isn't necessarily a "bad actor", it does help your security if you block traffic from a service known to index vulnerable systems.
  • No security based email addresses in place - standard email addresses that should be run for each domain are specified in RFC 2142. While some of these are undoubtedly out of date ( usenet@ anyone? ), others, such as security@, should be implemented and monitored appropriately.
  • No network or security monitoring - the database was compromised multiple times and yet CloudPets obviously didn't spot this as they didn't react by securing their systems, or at least protecting the database server from the Internet.
  • Unencrypted data within the database - it strikes me that there could/should have been a clever way to encrypt the data in the database, maybe tied into a particular toy's hardware, or some key derived from the App associated with the toy. As the toy appears to talk using Bluetooth to an App within the same household, as that App acts as a gatekeeper for inbound and outbound messages; a key based on the toy might work. By cryptography standards it would be horrible, a shared key in multiple locations, and that would require little effort for the App to encrypt or decrypt voice data, but certainly better than nothing.
  • No authentication protecting online assets - the profile pictures, voice recordings, and so on are all accessible with knowledge of the complex URL they're hosted at. While not trivial to index this makes them vulnerable. The authentication credentials required are already available to the service, this is omitted simply because the service is so poorly secured.
  • No network separation - from Troy's article it looks like the webserver, the production database server, and the development database server, were either all sitting on the same IP address, the same physical or virtual system, or all were the same physical or virtual system. I assume it's difficult to elevate privileges from MongoDB access otherwise far more damage would have been caused by all the recent compromises, but this is a less than ideal configuration all the same.
  • No password policy in place - any password was permitted, including a single letter; as Troy points out the demo video uses "qwe", and judging by his article, the obvious choice of "cloudpets" was common.
  • No notification of compromise - as Troy illustrates through interrogating Shodan, CloudPets knew that there database had been compromised, but made no effort to contact their users. I can't comment on the legal situation here, but it's due to vendors like this that the inbound GDPR disclosure rules look so useful, or so concerning, depending on whether you're consuming or providing a service.

So that's the twelve. There was a couple more that sprang to mind around Threat Intelligence, and more fine grained database security, but they're too wobbly for this piece.

So what did I miss? Did I catch everything? Suggestions for what else they did wrong are welcome in the comments below.

And do sign up for Troy's haveIbeenpwned.com website too.

Monday 13 February 2017

The "Targus Wireless Bluetooth Presenter Remote Control & Mouse Cursor", model BEU0564C

In an earlier blog here I stated I was going to use a Targus device that combined the functionality of being a wireless mouse, and a wireless remote control for presenting; rare functionality that is exactly what I was after.

As stated... it does work with Linux, but only for short periods of time. Sometimes it can only last for a couple of minutes before it just kind of forgets that it was talking to something else. This makes it completely unusable for presentations, and essentially completely worthless. Reading through the Amazon reviews more thoroughly, it looks like I'm not the only one with this problem.

I realise the device was on the "cheap and cheerful" side but I expected basic functionality, rather than no functionality.

Avoid.

Suggestions for equivalent but reliable devices would be appreciated in the comments.

Monday 6 February 2017

Hacking For A Career - Which Events To Attend

A short blog this time, which events should you attend as a budding penetration tester?

There's a great list here on cyber.uk of all the relevant UK conferences - the only thing I'd add is that the dates for BSidesLondon have been announced.

So once you're at a cyber security conference, how to make the most of it? Talks are always important, they can be great chance to learn a lot about a subject in a short amount of time. But do make a point of making contact with new people in-between or outside of the presentations, what people tend to call "CorridorCon".

As with any experts cyber security people will tend to dislike uninformed questions, so "how do I learn to hack?" or "who will pay me the most?" or "you use Windows, you must suck" won't go down well. However if you're obviously put in some effort, and ask "I really enjoyed your presentation, I'm interested as to why you advocate X not Y" or "I'm looking for a company to work for over my holidays, and I'm wondering whether to contact Weyland Industries or The Umbrella Corporation, who should I consider?", you're much more likely to get a response.

Be interested, be interesting, and have your contact details ready to pass on, and a day spent at security conference can make all the difference to starting your career in the right way.

Hacking For A Career - Tools You Should Know

This is the next entry in the series, aimed at providing depth to parts of my "Hacking For A Living" presentation.

Further to the packed slide I gave during my presentation, here are the tools you should have a passing familiarity with. Note that these aren't the offensive tools, but the other programs you should be familiar with. Do bear in mind my background is as an infrastructure tester, in my experience of web application testing a lot of the information on the target was within a single application - Burp Suite.

Also, do look at the functionality and integration between up to date versions of Nmap, Nessus, and Metasploit - being able to easily transfer data between all three will enable you to do more testing in less time, making you more valuable as an employee, and more efficient as a tester.

The emphasis below is very much on Unix tooling, if you prefer to test from a Windows system I'd still recommend installing Cygwin to give you access to these, unless you're particularly adept at the Windows command prompt or PowerShell.

System and network monitoring tools

These will help you understand what your own system is doing, any bottlenecks or other issues that mean your system is slower than it should be, or any local connectivity issues causing you problems:

htop, iotop, ip, lsof, netstat, ps

Interrogating remote services or networks

All of these programs are useful for determining that you're on the right network, that you've got the right connection to your target systems, and so on. Also some of them are useful in an elementary way for obtaining information on whatever system or service it is you're attacking:

arp, arping, dig, host, hping2, netcat ( in all its forms ), nslookup, ping, openssl, socat, tcptraceroute, telnet, tftp, tracepath, traceroute, wget,

Terminal multiplexers

These programs allow you to easily manage multiple programs simultaneously, or to keep a session up on a remote system that will survive a break in connectivity:

screen, tmux

Recording your output

These programs are useful for recording your tool output, or network traffic - so you can grab entries from their logs for your report, or demonstrate to a customer what was or was not happening on your testing system at a particular time:

script, snoop, tcpdump, tshark

Sorting, searching, and manipulating output

There's a lot here, and I should stress that you don't need to know them extensively, you just need to know *of* them, and have an idea of how to start using them when necessary:

awk, sed, head, tail, strings, grep, egrep, findstr, cut, sort, uniq, sponge, tee, pee

Recording your knowledge

You will learn a great deal as a penetration tester, and won't have access to old machines or reports or notes when you change employer. For recording wehat I learnt on a test, so I could easily reference it on a future test, I always liked TiddlyWiki. Find something that suits you, but I'd strongly recommend using something digital, rather than a paper notebook - that way you can back up your notes, or easily search through them for a specific entry.

Programming Languages

You can arguably get by as a penetration tester with just a little bash shell scripting, but to really get on with automating your penetration testing workflow do look at advanced bash shell scripting, or Python. If you're going to be attacking Windows systems a working knowledge of PowerShell is increasingly required.

Others

A couple of commands it's worth familiarising yourself with, just so you can ensure the output from your tools, or your notes, isn't accidentally overwritten:

chmod, chattr

And also the text editor "vi", as you'll find it on any Unix system you have access to.

One last thing, familiarise yourself with "man" pages. I always find man pages useful reminders for how a tool or program works, but far less useful in determining why or when I should use it.

Hacking For A Career - What To Learn

So, you want to become a penetration tester, where do you start?

Introductions

Really the place to start is Robin Wood's two "Breaking in to Security" blog posts, which are here and here.

After that watch this great twenty minute interview with John Carroll on what it's like to be a penetration tester.

Now you have some context, work through "Start In InfoSec", put up by Rob Fuller, also known as Mubix. His Twitter feed is here: https://twitter.com/mubix. There's a considerable number of resources there, don't be afraid to pick and choose, move on to the next entry if the subject matter or the tone isn't relevant.

There's also a lot of information listed in "Getting Started in Information Security" on the netsec sub-reddit wiki here: https://www.reddit.com/r/netsec/wiki/start. While not directly useful this is handy to see the breadth of the subject matter, and what resources are available. Overall "/r/netsec" is worth your time as long as you aggressively filter. The regular hiring threads, while mainly focused on North America, are also worth following.

Attack Platforms

Kali is definitely the attack platform that many penetration testers use, and the most common. However it's also worth looking at BlackArch .

I would recommend running these as a virtual machine, however if you're looking at attacks at Layer 2, such as VLAN Hopping, you may have issues and ideally you'll run your attack platform directly from your laptop.

There are other platforms available, and also you may prefer to "roll your own" rather than having the platform maintainer decide how you work and what interface you use.

Offensive Tools

Depending on where you'll focus as a penetration tester you'll either need to become very familiar with very few tools, or at least have an understanding of a wide range of tools. These are good ones to start off with:

  • Nmap - the industry default for port scanning.
  • Nessus - this tends to be the vulnerability scanner that companies will use, and expect you to know.
  • Metasploit - a well maintained collection of attacks and an industry default.
  • Nikto - useful to see just how simple some tools can be, and the strengths and weaknesses of that approach.
  • SqlMap - SQL injection is still a major weakness on websites, this program automates exploiting it.
  • Burp Suite - the free version is enough for you to get the hang of this software, which is an industry default for web application testing.
  • Kismet - for analysis wireless networks.
  • Aircrack-NG - for testing wireless networks.

Targets To Attack

Of course you should only be attacking systems that you control, and have authorisation to do so. I always think it's much better to attack something locally that you're running as a virtual machine rather than to attack a Virtual Private System ( VPS ) you've paid for on the Internet. The best resource I've found is Awesome Cyber Skills as a list of systems to download, or access online.

Other Notes

As per my presentation, if you're interested in physical Social Engineering look at films such as Sneakers or the TV series Leverage just for flavour, look at the YouTube videos of Jayson Street and Johnny Long to see how professionals do it. Also check out the "career" of Karl Power and the book "The Complete Guide To Gatecrashing" to obtain interesting and entertaining insights into what's possible, and the mental challenges involved.

I expect similar examples of real world security failures to be present in Channel Four's "Britain's Greatest Hoaxer" documentary, which is on this week.

For real world examples of where this is important, look at the "KVM Hack" of Santander, and much more recently, the taping of members of the Republican Party...

Friday 3 February 2017

Hacking For A Career - Introduction

I was a penetration tester for ten years, working for a few companies in the UK, and participating or leading hundreds of tests. I also find the overall philosophy behind penetration testing, and pentesters themselves, particularly interesting, so I'm reasonably familiar with how the industry "works" in the UK.

Since moving on from penetration testing I've presented a few times on "Hacking As A Career", a rough guide to being a penetration tester, covering what the career involves, how to get into it, and what to get out of it. The presentation is usually given to Computer Science students in the UK, so that's where my focus lies. It's mainly based on my own experience, but I've made a point of asking a few friends for suggestions for each category.

In the following blog posts expand on this presentation, with references taken from my research and notes, and partly filling in the detail from my slidedeck:

What To Learn

A few references on where to start:

  • which resources to read on breaking into the industry
  • which attack platforms or tools to learn
  • what to attack using those tools

Tools You Should Know

A list of the tools which any aspiring tester should familiarise themselves with in order to make their life easier.

Which Events To Attend

A list of which events anyone looking to enter the industry should attend.

A guide on what to ask, and how to introduce yourself.

Drinking From The FireHose

Which blogs to follow, and which podcasts to listen to - focusing on those that will provide the greatest value in the shortest amount of time.

In particular for this one I'll list relatively few resources as I'm naturally averse to listing everything, pre-curated lists of resources are woefully rare on the present day Internet.

Tuesday 13 December 2016

xmonad issue with drop down menus - workaround

If you have a problem with drop down menus for certain programs ( in my case kdenlive and virtualbox ) not displaying their drop down menus in xmonad it might be this issue:

https://github.com/xmonad/xmonad-contrib/issues/73

The workaround proposed by geekosaur in that bug report appears to work for me, after about ten minutes of testing.

However if you've followed the usual introductions to xmonad you'll need to change "workspacen" for "myWorkspaces", as looking at this online paste that appears to be what geekosaur calls their workspaces variable. ( It might be a "variable", I don't know Haskell ).

So copy and paste this text into the appropriate place in your xmonad.hs file, and restart xmonad:

-- @@@@@@@@ HAAAAAAAAAACK
setWorkArea :: X ()
setWorkArea = withDisplay $ \dpy -> do
    a <- getAtom "_NET_WORKAREA"
    c <- getAtom "CARDINAL"
    r <- asks theRoot
    io $ changeProperty32 dpy r a c propModeReplace (concat $ replicate (length myWorkspaces) [0, 26, 3840, 1028])

Friday 9 December 2016

How to remove all notifications of FaceBook user status changes in Weechat when it's talking to Bitlbee

If you're using Weechat to talk to Bitlbee to talk to FaceBook ( or other instant messaging services ), your private message window for each user will be full of notifications that the user has joined or quit.

You can get rid of most of the notifications using this filter line:

/filter add joinquitbitlbee irc.bitlbee.* irc_join,irc_part,irc_quit *

Which is specified here,

However if you do this you'll see get the "is back on server" messages; to remove those as well you want to use this line:

/filter add joinquitbitlbee irc.bitlbee.* irc_join,irc_part,irc_quit,irc_nick_back *

If you want to see those messages temporarily, for example to see if someone is online or not, enable them in Weechat with ALT and "=". Use the same key combination to remove them.

Tuesday 6 December 2016

Running videos directly from LibreOffice Impress

For a recent presentation I gave at DC4420 I needed to show some videos, so I originally tried embedding them into the presentation's LibreOffice Impress file. LibreOffice did not handle the resulting large file size well, and particularly didn't like embedded videos. So what I did was flick from my presenting window to a terminal window, and run a quick script from there that called mplayer with the appropriate options.

This worked pretty well, and I was able to do it pretty quickly when I practised the presentation at home.

Unfortunately in practice I under-estimated how difficult it would be to type the name of a file with a microphone in one hand and a presenter's remote control in the other, if you were a member of the audience your patience was appreciated. This bugged me so I now have a solution, ready for the next time. I haven't tested this "live" yet, but I figure if someone else is stuck in a similar position it will get you 95% of the way there.

How to do this:

Firstly - running videos from LibreOffice Impress

You'll need to change the security settings around macros first. Go to Tools, then Options, then in the window that opens go to Security under "LibreOffice". Go to Macro Security and set it to Low. Yes, not ideal, do change it back to an appropriate level whenever possible.

Go to Tools, Macros, Organise Macros, and then LibreOffice Basic. From there select "Edit", and then put in a macro that reads as follows:

shell ("bash -c '/<path to shell script>/script.sh'")

From here it's up to you, either have one shell script that runs all videos by calling them as an option, or use a different shell script for each video. That should work, I believe in the LibreOffice macro you can call a script with options.

For the script, it will say something like:

mplayer -xineramascreen 1 -fs file.mp4

This means you can also use the "-input conf=/<path to file>" option to call a specific mplayer configuration file, which I'll cover later.

I'm expecting that you're using "Presenter View" in LibreOffice, so you might need the -xineramascreen option to ensure the video plays on the correct screen for your audience to see. In my limited experience the options for mplayer were weird, "--xineramascreen=1" might also be accepted, or it might not - experiment if necessary.

If you need to play multiple files then look at the "playlist" option for mplayer.

Then in the presentation itself, where you want to play a video, insert a graphic. Bear in mind you'll be clicking on this graphic during the presentation to run the video, so make it nice and big.

Right click the graphic and select Interaction. Select the appropriate Macro from those you've set up to call the right shell script.

Secondly - how to do this one handed

Ideally during the presentation you'll be standing away from your laptop or whatever you're using to present from, so you want to advance presentation slides, and click on that graphic, using just the one presenting Remote Control. In my experience most presenting remote controls don't include mouse functionality. So for this buy an all-in-one presentation remote control and mouse. I've chosen a "Targus Wireless Bluetooth Presenter Remote Control & Mouse Cursor", model BEU0564C, this should work with your Linux box too. For example you can get it from Amazon.

Sync the Remote Control with your Linux system, which works for me. When you've set your Linux system to scan for new Bluetooth devices you might need to press buttons on your Remote Control to get it to "wake up" and connect.

This now means you can use "presentation mode" to advance slides, then flick the Remote Control to "mouse mode" and click on the presentation graphic to run the required clip, and then flick it back to "presentation mode" to keep controlling LibreOffice Impress.

Thirdly - some mplayer modifications

As I said above, you can call mplayer with a specific configuration file to determine how it manages input. If you put this into the configuration file:

b pause
F5 quit
PGUP seek -8
PGDWN pt_step 1 1

This should mean that on your remote control:

Press the "blank screen" button to pause or unpause a video. Press the "start / stop presentation" button on your remote control to stop a video playing. Press the "next slide" button to rewind the video eight seconds. Press the "previous slide" button to skip to the next video in a playlist.

You can use the program "xev" to see what specific keypresses your presenter's remote control is sending; and of course do experiment and practice before you give the presentation.

And there you have it.

Wednesday 30 November 2016

Notes from "What Happens When A Game About Hacking Meets The Hacker Mindset?"

Thank you to everyone who braved the cold and made it to my presentation at DC4420.

A description of the presentation can be found here; and details about DC4420 can be found here.

A few notes from slides that I probably flew right past during the live talk:

The PDF of Chris Sumner's presentation from HackFest Canada is... around somewhere, I'll check with Chris and update this blog post.

Jayson Street's presentation on global hacker culture and hacker history can be watched here.

J4vv4d's blog post that I grabbed a couple of quotes from is here.

Tanya Snook's article is here.

The presentation by Fraser and I from DevSecCon is here, and I may or may not have generated enough intestinal fortitude to watch that by the time you're reading this.

If you want to ruin your enjoyment of media, go to http://tvtropes.org/.

You really should be watching Scorpion.

The concept of Neo Tactics comes from Mike Bond's "Boom! Headshot!" research paper, the paper is here, and a PDF of the presentation is here.

The manual for the First Earth Battalion is here.

And, er, that's it - which probably wasn't the information you were after. It's been suggested I give the presentation elsewhere, so if I put more work into it I'll put in some links to the YouTube players who provide good examples of hacks, and other references in the talk.

And if anyone can help me understand XBox360 game save file formats, or help me track down a copy of Raven's Cry, please respond in the comments...

Saturday 26 November 2016

Tuesday's forthcoming DC4420 presentation - What Happens When A Video Game About Hacking Meets The “Hacker Mindset”?

With the very recent release of WATCH_DOGS 2 it’s timely to look back at the original WATCH_DOGS video game. Set in a fictionalised Chicago, in WATCH_DOGS you play as a “brilliant hacker” who uses his hacking skills to manipulate ctOS, the “Central Operating System” that runs the city. The game was similarly forward looking in its design, combining an open world single player mode with an “always on” feature, meaning the player’s game could be surreptitiously invaded at any time by an online rival.

But for a game that should be saturated with an understanding of hacking, what happens when it meets players with the “hacker mindset”? This talk will take you, Inception like, through the different levels of a player’s understanding of the game, and how they can use that understanding to gain a disproportionate advantage during gameplay.

( Please note, originally this talk was entitled “What Can WatchDogs Teach Us About Cyber Security?” but the presenter realised that there wasn’t that much to learn; also after fighting and losing against Linux display drivers at the October meeting the presenter will be bringing at least two different presenting platforms to the meeting and is currently watching several Overhead Projectors on eBay. )

More talk description is here , venue details are here.

Monday 21 November 2016

How to replace sux functionality on Arch Linux

( Apologies, this is just search engine fodder. )

If you're someone else who mourns at the demise of "sux" then note that this solution works, for me, on Arch Linux:

In /etc/pam.d/su, to forward xauth keys between users when calling su, add

session  optional  pam_xauth.so

and then a simple "su <username>" from the logged-in user to the user you want to run the X program works.

Full credit to http://askubuntu.com/questions/428284/what-is-a-good-alternative-to-the-sux-command for this.

Saturday 1 October 2016

Technical Notes from my DC4420 presentation in September 2016

On Tuesday 27th September I presented on my home computer setup at the DC4420 meeting. This setup has taken me some time to establish, has been through many iterations, and features a considerable number of monitors and KVMs - and so I hoped I could serve as an example, or as a warning, to others.

The presentation was well received, with the friendly audience showing joy, concern, enthusiasm, and despair.

While I like the practice of writing up blog posts of talks my preferred method of delivery owes more to my very, very shallow knowledge of the PechaKucha style of presenting... and less pretentiously, a lot of watching the PBS Idea Channel, and so doesn't really suit this written medium.

So rather than try and write up the whole thing, below I've listed a summary of the technical advice, and technical issues, that I've discovered along the way. For the full version, maybe you just had to be there.

KVM notes:

Aten CS533: This is the Bluetooth KVM I use, also called the Aten Tap. The IOGear GKMB01 appears to be the same thing. It supports two bluetooth devices. Do note that sending commands to it requires using the Alt key combined with F1 to F6, and that can't be changed, which might clash with other keyboard shortcuts you've got. For unknown reasons this device didn't work for me when I plugged it in front of the Avocent Switchview listed below, but does when I use it in front of the Raritan.

Aten Masterview CS-9138: This is the 8 port KVM I currently use. It has a small choice of HotKeys, and thankfully doesn't have a buzzer. For unknown reasons the keyboard indicator lights don't work when I'm working through this, but bear in mind it's "behind" an Avocent KVM, and at least one USB to PS2 adapter... I think. so that's probably why.

Avocent Switchview 4SVPU20 MM2: This is the 4 port KVM I now use, I have two. It takes USB or PS2 input along with VGA, but doesn't need the VGA port to be used to work. This device has a relatively massive choice of HotKeys, and using the command "<HotKey> <HotKey> <B>" you can completely disable the buzzer... the KVM won't make a sound unless it's powercycled. It has independent KVM, USB hub, and audio allocation - so you can move the audio to a different system without moving the other functionality at the same time. Also the audio ports have no "direction" and are just physical connections, so by putting the audio ports of two of these KVMs in line, and connecting audio inputs to one and audio outputs to the other, I can direct any of four inputs to any of four outputs.

Belkin F5U119-E: Unlike some of the cheaper USB to PS2 adapters I've used, this adapter tends to work with everything I connect it to.

Belkin Omniview F1DS104U: the original 4 port KVM I used. Bear in mind it will beep when you change screens using hotkeys, and doesn't like being chained. Also the firmware upgrade to make it silent is difficult to find, requires a bespoke cable, and doesn't work.

Belkin PRO2 OmniView 8-Port KVM Switch F1DA108T: The original 8 port KVM I used. It will beep when you change to a different device, and removing the speaker ( known as a "speakerectomy" ) appears to cause electrical problems. Also it has male VGA ports, which is quite unusual.

HP ChromeBook 11: this uses a SlimPort connection for video output and for power simultaneously. If a SlimPort to VGA, or SlimPort to HDMI, adaptor is used, this device will drain its battery even if the power supply is plugged in.

Raritan SW4-USB-Combo: This is the other type of 4 port KVM I now use. As well as independent KVM, USB hub, and audio - as per the Avocent above - it has a small choice of HotKeys, and "<HotKey> <HotKey> <S>" turns off the buzzer for most functions, but it'll still beep if you make an error.

Sivitec Black 8 Way SURGE Protected 5m Extension Lead Switched NEON 8 Gang: this is the only 8 socket gangplug I've found with a cable longer than 2 metres.

Other notes:

Monitors: if you have the money, and the time to look up the different options, do buy monitors with the best capability, i.e. VGA input, DVI input, HDMI input, an audio jack, a VESA mount, and with the configuration buttons located somewhere accessible.

Peripheral Sharers: The USB peripheral sharers I found that were "too clever" were the StarTech 4-to-1 USB 2.0 Peripheral Switch, the Kensington ShareCentral5 K33901EU, and the Aten US421A.

Synergy: I'm still suitably suspicious of this software, but at least one person came up after the presentation and explained that they found it reliable and useful. If it looks like what you need do check out http://symless.com/synergy/ .

Window Managers: The Tiling Window Manager I use, with flexible mapping of virtual screens to physical screens, is Xmonad. If you want to look at alternatives then try i3, dwm, or spectrwm.

Xorg: It's a very high level summary of what I've done, but to get X working on four independent screens my configuration was built using the following incantation: run the command "nvidia-xconfig –enable-all-gpus –separate-x-screens", your xorg.conf file should only have a single “screen” section, and use the line Option “BaseMosaic” “on”

Thank you to the audience for getting into the spirit of the presentation, and if you've any questions do ask them in the comments below.

Friday 10 June 2016

How To Turn Wargamers Into Red Teamers, and Red Teamers Into The Actual Enemy

Earlier "today" ( Thursday 9th June ) I had the pleasure of listening to a free "Red Teaming 101 Webinar" by Mark Mateski of the Red Team Journal. ( The next event is on the 7th of July, and is listed here: http://redteamjournal.com/events/ ) This was an enjoyable high-level webex seminar about the idea of red teaming in general, very much on the "contrarian perspective" being a useful and under-used tool by organisations, and a quick run through of the overall concepts.

This inspired me to finally get down this idea that I've been ruminating on for a while. This piece is a drastically modified version of the article "Serious Wargames Needs Serious 'scout team' Wargamers" that appeared in issue 289 of The Nugget, "The Journal of Wargames Developments". Wargames Developments is a "loose association of like-minded wargamers dedicated to the continued development of wargames of any type whatsoever".

That original piece was in reply to Tim Price's piece in the previous issue: "Red Teaming, Black Games and Failure in our Wargames", lamenting the lack of diversity in professional wargaming meaning that the play of the "red team" was unhelpful. However I was inspired to modify my article, and publish it in a wider context, due to the Red Team Journal blog post "Operational Code Analysis for the Real-World Red Team, Part I" ( http://redteamjournal.com/2016/04/operational-code-analysis-for-the-real-world-red-team-part-i/ ). When announcing that piece via Twiiter, the author Mark Mateski quoted his article "Know thy enemy? Good luck with that! ( Yes, I'm exaggerating, but only a bit. )".

In the article Mark enumerates a very useful list of 37 questions to ask yourself, or your on-hand experts, about the opponent you are modelling in order to create a model of their "operational code", the operational code being that opponents way of working, of thinking, of fighting. That way you can simulate that operational code within your red team exercise, and effectively emulate the opposition.

Which brings us back to the original article by Tim Price. In this article Tim highlighted the lack of an effective opposition within the serious games he'd been involved with, where the people playing the opponent clearly were thinking and acting in the usual way for their standing, culture, and the situation - which considering that this was a military simulation was usually in a similar way to the organisation they were attacking. While it might win the game this approach isn't very useful when trying to understand the enemy, which is the point of playing the wargame / simulation in the first place. Tim Price pointed to the use of experienced amateur wargamers as a solution to this, players who've spent a great deal of time looking for winning strategies outside of the "rules", players who have little regard for any artificial constraints to victory.

However I put forward that Tim is correct only up to a point, and considering his experience this wasn't a decision I made lightly. Partly serious wargamers are ideally suited to this situation, people who are used to adversarial situations and everything that goes with them, from the importance of a reserve force to the necessity and value of logistics. Those serious wargamers are who you want, as Tim said, "they are programmed to seek winning strategies" However I think Tim omitted an equally valuable characteristic of the right kind of wargamer, which the members of Wargames Developments brings to mind... the wargamers needed must be more interested in understanding the game, they must be most interested in solving the puzzle the game represents, than in winning the game. For those wargamers representing the opponent, for those wargamers playing the red team, their overall aim needs to be to determine how to win this kind of game, rather than winning this particular incidence of it. They need to be a true OPFOR, the aim is not to win this game but to win all games against this opponent, and ideally to understand how this particular type of game can be won.

Now I'm only on the periphery of serious gaming, it's one of the career options I'm currently considering, but I was initially astounded that imitating the opponent isn't seen as best practice, and a diverse set of players and experts seen as a way to achieve that. To me it seems obviously non-sensical that putting forward the imitation of the enemy as the main pre-requisite is seen as some kind of underground or iconoclastic point of view. But then, taking a step back to consider the situation for a moment, there has been a similar discussion going on for some time in my field, the world of Penetration Testing. Penetration Testers are hired to attack a company's systems to look for security vulnerabilities, with the aim of illustrating and describing those security vulnerabilities before they're exploited by genuine attackers. However it's becoming increasingly clear that penetration testers tend to illustrate the security issues that penetration testers would exploit, those issues that are more intriguing to investigate or more exciting to describe, whereas a criminal hacker will pick on easy targets to make money; the opponents penetration testers are meant to be representing don't have time to play with puzzles, they are not looking for stories to tell - they have a job to do and money to make.

( If you're interested, this slide deck from a recent presentation at the RSA Conference is a good summary of the arguments: http://www.rsaconference.com/writable/presentations/file_upload/asd-w02-intelligent-application-security-rsa.pdf )

So if Serious Gaming doesn't get this, and neither does Penetration Testing... neither industry being notably short of smart people... does anyone have what I believe is the right point of view? In my experience the best example came from one of my other interests, American Football. To over-simplify there are two sets of players on a team: Offense - who play when you have the ball, and Defense - who play when the opponents have the ball. Team rosters are huge, partly due to how common injuries are in the game, therefore there are definitely "starters" on Offense and Defense, backed up by "second string" and "third string" players. Due to the wide variety of styles of play in the sport, the starters need to practice against the specific playing style of the opponent they'll face that week, and this is where the "scout team" comes in. The scout team consists of the second and third string players on your team imitating the style and plays of that week's upcoming opponent, for the benefit of the starters. As well as their ability to play the sport overall, scout team players are graded on their ability to imitate opponents, and this is what serious gaming needs.

I should stress, this is where players willing to be a "scout team" are required, rather than those with knowledge of all possible opponents or combat environments. And it is these "scout team" players that serious games need. They need open-minded wargamers who are more interested in winning the game than winning the battle the game represents, understanding the difference between the two is crucial.

Overall, it is those rare players capable of and willing to emulate an opponent that serious wargaming needs to make up a "scout team", which to me is taking the profession much more seriously that merely winning or losing whatever battle is being played. So while my angle was different to Tim Price's, my conclusion was the same... serious wargames need serious hobby wargamers.

Back to Mark Mateski's piece on operational code. As I say, there's a comprehensive set of questions in that article, but after that Mark appears to hit something of a block. He suggests a couple of techniques for helping the red team work under that operational code, but these are quite general and designed to suit every situation.

Sticking to the imagined scenario of my original piece, looking at serious games, expected to be an exercise of a few days, and military in nature and therefore directly confrontational, I see two useful ways to turn the answers from Mark's 37 questions directly into something a red team can use:

Firstly - "trait cards". Each of Mark Mateski's questions should elicit several statements on the operational code of the opponent that the red team is looking to emulate, anything from "use deception whenever possible" to "prefer indirect over direct fire" or "sacrifice soldiers rather than ground" and so on. Eachanswer to those 37 questions should be distilled into a trait and written on a card, and assigned a number of points by the red team in conjunction with the experts being used to provide information on the operational code of the opponent. Whenever the red team carries out an action during the engagement, and I'm thinking of a wargame with something of a turn-based structure when actions are put forward by player teams and resolved by a combination of the wargame's system and its umpires, the red team can play appropriate trait cards in order to score points. Therefore the more successfully the red team emulates the opponent by following the cards, the more points they'll score.

This is a version of the idea from roleplaying games of "XP", or experience points, that I referred to in my original tweet displayed above. Expereince points are awarded by the person running the game, usually a GamesMaster ( GM ), in return for completing objectives, but most importantly in this context, they are also awarded for successful roleplaying, for a player acting in the same way that the character they are playing as would act. These trait cards would formalise that role-play aspect, and enable to red teamers to judge what kind of action they should take to emulate the opponent.

Secondly - a CARVER matrix based on the perceived operational code of the opponent. A CARVER matrix, to quote directly from Wikipedia, "was developed by the United States special operations forces during the Vietnam War. CARVER is an acronym that stands for Criticality, Accessibility, Recuperability, Vulnerability, Effect and Recognizability and is a system to identify and rank specific targets so that attack resources can be efficiently used. CARVER was developed in WWII by the OSS for the French field agents as a simple, uniformly and somewhat quantifiable means of selecting targets for possible interdiction. CARVER can be used from an offensive (what to attack) or defensive (what to protect) perspective." This matrix could show the value, to the red team, of destroying different assets being operated by the blue team. Therefore the red team can now prioritise goals through the CARVER matrix, and choose which actions to use to reach those goals through which trait cards they can play.

This method is relatively simple, and stops the red team trying to win the game... it's now intuitive for them to act with a single objective in mind: accumulating points. This gives the red team a method to turn the answers to Mateski's 37 questions into actions, and gives the blue team in the wargame a version of the opponent that is in some way following the real world opponent's operational code.

As with all attempts at gamifying a process in order to improve adherence to it, there will be a gap between the actual operational code of the opponent and how that is portrayed by the red team in the wargame. Turning a vague statement that the enemy will employ deception whenever possible depending on available time and resources into a card stating "employ deception in an attack, score five points" means assigning complex decisions a value on a linear scale, but I think what you would lose in complexity you gain in focus.

And if the trait card points or CARVER matrix turn out to be wildly incorrect, to the extent that the red team aren't emulating the opponent in the wargame, then just change the values. Red teamers, especially the leaders, and especially if they have ready access to experts on how the opponent being emulated thinks, should be able to spot when the numerical model has too great a gap from the perceived operational code of the opponent, or the actual operational code of the opponent, to be useful; and therefore they will modified the scoring on the cards and in the matrix.

Unfortunately I've yet to have an opportunity to practice this idea, but I see this as the way to turn the perception of an operational code into an actionable set of ideas that a red team can use during an exercise, and therefore this will effectively guide the red team into achieving their true aim: emulating the opponent. Also it gives wargamers, acting as a red team, a way to naturally and intuitively play a wargame in a way that is of use to the blue team, while naturally and intuitively using their desire to win.

And one last thought, considering the expected competitive nature of red teamers... have two red teams in play, neither knows the constituents or deliberations of the other team, just what actions they've taken and how many points they've scored.

Tuesday 17 May 2016

"although it's unpleasant, you do want to have nay saying voices involved in any sort of decision that you make"

As a former penetration tester, and sporadic wargamer, I am completely sold on the "red team" concept. For those of you not familiar with the area, I'd describe it as "having someone or something with an adversarial mindset examine your nascent idea or project or hypothesis for flaws from the point of view of sentient opposition, and also to extrapolate the second and third order effects from the implementation of that idea". I am still surprised at how rare this point of view is, although I realise that I might be preaching to the converted.

I'm still working on having the kind of reputation where you can now quote me to your managers and get the resource for the Red Team Department you want to set up... but if I can't help, how about Professor David Dunning? David Dunning is "Professor of Psychology at Cornell University. As an experimental social psychologist, Dr. Dunning is a fellow of both the American Psychological Society and the American Psychological Association. " His full details are here: http://socialsciences.cornell.edu/david-dunning/ , he's most well known for his work on the Dunning-Krueger Effect. I had the pleasure recently of listening to him being interviewed for the "You're Not So Smart" podcast, this was episode 72: https://youarenotsosmart.com/2016/04/08/072-why-we-are-unaware-of-how-unaware-we-are/ - it's well worth your time, and these are a couple of particularly useful quotes:

"There are some helpful points that psychology suggests in order to avoid overconfidence that leads you over the cliff, if you will. The first is that, although it's unpleasant, you do want to have nay saying voices involved in any sort of decision that you make. That is, you want someone to play devil's advocate. Basically to poke holes in what the group or the institution might be thinking about what it wants to do. The reason for that is, having a devil's advocate can help the organization spot when it's being overconfident. Or, sometimes just improve the decision that the institution’s going to do. So you want that."

"Having a devil’s advocate is unpleasant ... but what it does do is it does insulate you against unknown incompetence. And you just know that it’s going to show up sooner or later, you just don’t know where. So you might as well just have these policies that help you address the problems that you can’t anticipatewhen they finally rear up and try to bite you."

Episode 72 was a re-broadcast of episode 36, and these quotes are taken from the transcript of episode 36 of the "You Are Not So Smart: A Celebration of Self Delusion" podcast with some minor editing for clarity. The transcript is here: https://youarenotsosmart.com/transcripts/transcript-interview-with-david-dunning-from-episode-036/

Monday 2 May 2016

Books I have read recently that you should read too.

Of course I was planning to go into slightly more depth for each one, but then they sat in a "to do" pile for several months:

Can't Be Arsed: 101 Things Not To Do Before You Die - Richard Wilson; the description from the inside flap tells you all you need to know: "who cares about swimming with dolphins, walking the Great Wall of China or bungee jumping in New Zealand, when there's an armchair to sit in and windows to stare out of?"

Horrorstor - Grady Hendrix: I never really read horror before, and it's not a genre I usually like... but this was a particularly well written book. You will never look at IKEA in the same way again.

In the Land of Invented Languages: Adventures in Linguistic Creativity, Madness, and Genius - Arika Okrent - this tackles some intriguing issues around language, i.e. the Sapir-Whorf Hypothesis, while also taking a tour with the kind of people who try to establish their own language. If you're intrigued rather than bemused by Esperanto and Emojis, this is the book for you. ( Warning, contains no emojis, but do see the chapters on Blisssymbols )

Moonwalking with Einstein: The Art and Science of Remembering Everything - Joshua Foer; a well written and entertaining summary of the author's journey to competing in the US Memory Championships. Some interesting points about memory are made, especially so now we're offloading so much of our own memory to smart devices; and I realise it's a cliché, but he meets some genuinely interesting characters along the way.

The Great Casino Heist - Richard Marcus; if you're interested in some of the technical detail behind committing fraud against casinos, but also want an entertaining read, this is recommended. Particularly interesting in that the techniques are relatively simple, and obvious in retrospect, it all comes down to execution, practice and confidence... and the kind of people capable of all three.

V for Vendetta, and The Watchmen, both by Alan Moore - I haven't read comics since reading 2000 AD many years ago, but I really enjoyed these. Maybe my reading skills have been blunted by all the interactive entertainment I now have access to, but sometimes I struggle to get into a book late at night - graphic novels might be an intermediate step where some of the imagination required is done for me right there on the page.

- page 1 of 2