BSides Leeds Challenge Flag Guide

One of the many many awesome things @LargeCardinal and co did for BSidesLeeds this year was a challenge to collect as many hidden flags as possible. Sadly nobody reported collecting any flags on the day (probably because there were so many other things for people to do and see) so they decided of offer an additional week for people to find them.

I found out at the closing ceremony that not only had I found a flag, because I didn’t recognise it as such I’d displayed it all lunchtime to the entire dining room and also unwittingly tweeted it out. I decided as I’d stumbled across 1 flag, I’d spend my weekend looking for the remaining ones.

Here’s where I found them.

Flag 1 – “The Programme Polyglot one”

The day before the event, the BSides Leeds website was updated with a link to the event programme, When viewed as a PDF the file works as expected, but if you download it and run strings against it, it reveals some interesting secrets

Hum, an interesting couple of filenames found after the %%EOF marker that normally indicates the end of a PDF.

Those people at the BSides Leeds 2018 closing ceremony with exceptional memories may remember that the challenge prize was POC || GTFO , which I was lucky enough to already own. However, I remembered one of the articles in there was was on a ZIP/PDF polyglot.

Unlike last time I came across this puzzle, where I wrote a lot of code to extract the zip file from the pdf, I now knew the true power of a polyglot file format and just unzipped it and viewed the contents to get the first flag!

Flag 2 – The Bandersnatch One

So, whilst the obvious intention was to find it via the programme, LargeCardinal had obviously realised nobody was looking for Flag 2, so tweeted out the link.

The website was obviously riffing on the excellent Netflix Black Mirror “Choose Your Own Adventure” retro gaming episode Bandersnatch, but seemed to have no hidden features, so instead I started examining the linked .wav file.

Now, whilst the BBC Master and classic Microvitec CUB monitor I’d spotted downstairs and the fact Tom Hargreaves was talking about Acorn Hacking, should have been an obvious clue, I genuinely recognised the wav file as probably a BBC B tape image from it’s sound alone (whilst most 8 bit micros had similar tape formats the all had distinctive “noises”).

Over lunch I returned to the BBC Master (the enhanced version of the BBC C) disconnected the mp3 player that was connected to the tape port and hooked up the headphone socket on the MacBook.

Despite it being nearly 3 decades since I’d last used a real “Beeb”, muscle memory took over and all it took was

Ctrk+break (hard reset the machine*)
*TAPE (disable the default floppy disk system and instead use the tape input)
*LOAD “” (load from tape, but do not run)

Once I’d actually loaded the software, I realised that CHAIN “” (load and run) would have been more efficient, but it was job done, regardless.

The software then loaded this amazing image and some wonderful 8-bit tunes from the tape.

Now, what I hadn’t realise when I tweeted this picture and left in on display to everyone over lunch, was the the Herman Houser quote above the owl was in { braces } and there actually a flag!

You can see and here the full thing in all it’s glory at

*The speed at which is rebooted had my colleagues believing it was only a BBC Master case, but had much more modern hardware inside. The didn’t realise that in the 8-bit world sub-second boot times were the norm

Flag 3 – “The first BLE One”

This years conference badge was designed to house an ESP32 LoRa dev board. As SBG were doing a badge flashing station, I’d seen an early version of the software, but it seems LargeCardinal added a bunch of hidden features and most importantly FLAGS in the version we didn’t get until the very last minute.

The firmware was available from
and from the filenames and sizes it looked like bsides-bade.ino.bin was likely to be the most interesting, so as normal I started with strings and immediately hit some interesting stuff.

So, by just hooking the badge up to a terminal by doing screen /dev/ttyUSB0 115200 and using the chat functions of the software, a number of the strings we found were triggered, but as few more stood out as NOT things we’d seen on screen including

  • deadbeef-1337-h44x-f1a9-b51d3sb1ef1g
  • HiddenFlagIsNotAFlag
  • Bluebird
  • beb5483e-36e1-4688-b7f5-ea07361b26a8
  • SNEK
  • LargeCardinalFeelsBlue
  • … and something referring to Bluebird/Blue stuff.

It also showed the output of the help command

Supported Commands:
? – this message…
n – change Tx nickname…
d – print Tx nickname…
c – [TODO – put what c does here…]

The first two I discounted as intentional red herrings, the fourth one a little googling told me was a common string used in Bluetooth low energy (BLE). So lots of Blue references and 2 Snakes.

It didn’t take long to realise that typing either SNEK or SNAAAKE! caused the badges of everyone in radio range to turn into a game of snake! Very very cool (and quite annoying I’m sure) but ultimately, no flag.

So, one of the features of the board is it’s a BLE transmitter and we have a load of Blue reference, so l decided try and find something to start it.

/c (as hinted at in the help) doesn’t seem to do much, but some experimenting showed /b outputted a different error message to other commands and a little more experimentation led me to trying

/b LargeCardinalFeelsBlue

which worked and started a BLE server

Now, as the only BLE stuff I had handy was a BlueFruit board that wasn’t soldered up, I took a bit of a short cut and purchased an iPhone app the scanned for BLE. It was money well spent as I got the following

I have to admit, it took me far too long to realise that Blue DA BA D33 DA BA DA 1 was a reference to the Eiffel 65 tune

Flag 3 – “The Second BLE one”

I also have to admit that whilst I was one click away from the next flag, I missed it for quite some time. If once you discovered the BLE Service, you attempted to connect to it an enumerated the services, another key would jump out at you.

Flag 4 – “The Easy One”

A couple of people had mentioned on twitter that they found “the easy flag”, but do far I’d not found a flag that stood out as particularly easy.

It took me far far too long to notice there was one command on the badge I’d missed.

Simply entering /flag (or even just /f) rewarded you with {Easiest-flag-ever}

Flag 5 – “The One that nearly sent me blind”

On the day a few people noticed some tiny black on black writing on the badge and text on the back that hinted towards an XORing against a hex key

The text was incredibly hard to read by a old guy like me, but after trying dozens of light sources, magnifying glasses, etchings, high res cameras, play-doh and pestering family members to have a look, I eventually caught the light at just the right angle to give me a hex string, when when XORed against 0x5ca1ab1e give the final flag!


I can’t finish this without a massive Thank You to LargeCardinal and all his helpers, the challenge was very very fun and was very much the cherry on top of an awesome con.


LargeCardinal has told me I missed a flag, not just me, but EVERYONE did. Apparently the Black Badges worn by Mark and award to Chloe and Emlyn for their help over the last 2 years, actually had a different challenge on them to the white badges, but nobody thought to check them!

BSides Leeds ESP32 LoRa Badge – Flashing Guide

Firstly Install the Arduino IDE from

Once installed go to Files -> Preferences under “Additional Board Manager URLs” add

Then go to Tools -> Board -> Board Manager and search for ESP32. You should have ESP32 by espressif, install this set of boards.

You should then be able to go Tools -> Boards and select “Heltec_Wifi_LoRa_32”

Next to to Tools -> Port and select the apropriate port the dev board is connected to (Windows users will probably need to installed the USB to UART drivers from

Note the board will normally need to be plugged in for the serial port to be present.

Next go to Tools -> Upload Speed to 115200.

Finally got to Sketch -> Manage library and add
ESP8266 and ESP32 Oled Driver for SSD1306 by Daniel Eichorn, Fabrice Weinberg and LoRa by Sandeep Mistry

This should give you an IDE capable of sending compiling the firmware and flashing it onto the dev board

You can obtain Mark’s firmware from <Check, the final build may move>

Once you have the .ino file open in the UI, select Sketch -> Upload to send it (it’ll compile it first if needed).

A few seconds later, the firmware should be on the device.

If you’re struggling, there is a more complete guide at (just remember to select the LoRa board).

BSides Leeds LoRa Badge Guide – Usage

This Info is also available online at<insert URL>

First get yourself a ESP32 LoRa board (details, including a link to get the next-day via Amazon Prime can be found <link to SBG Engineering Blog for page for Quick Start Guide>) and pop along the the SBG Flashing Station to get BSides Leeds 2019 custom Challenge firmware on it.

Receiver Only

To receive broadcast messages (both from BSidesLeeds and other attendees) just apply power to the USB connector and watch the messages appear on the mini OLED screen.

Transmitter & Receiver

Connect the USB port to some kind or serial terminal. The guide assumes they’ll be some kind of Windows, Mac or Linux host, but we’re sure other people will be more creative.


Start by lugging the board into your computer then :-


Install USB UART driver from and check you have a new port in device manager when the board is plugged in (normally COM3)

Next install PuTTY, from and configure as follows (Connection Type: Serial, Serial Line: <from above, normally COM3>, Speed 115200)

Hit open and you should get something like the screen below

OSX & Linux

Doing screen /dev/ttyUSB0 115200 in a shell should give you something line the screen below

<Insert Pic>


LoRa is a low-power, low-bitrate but very long range radio protocol suitable for sending small amounts of data a long way.

Your badge is a LoRa based chat system. Choose a Nick then type away. Message received will be shown on the OLED screen on the badge.

Look out for special BROADCAST announcements during the day.

Beyond simple chat

The firmware source is available from . Feel free to take it and modify it.

BSides Leeds ESP32 LoRa Badge Quick Start Guide

It’s probably no great surprise that once again the BSides 2018 Badge is also a PCB.

However most people don’t get the chance to have fun with their badges until the get home, but as this years badge is all about interaction, SBG have teamed up with BSidesLeeds to help you actually take part on the day.

What you need?

The heart of the badge is a LoRa ESP32 Board. These were originally designed by Heltec as “ESP32 OLED LoRa Development Boards” intended for IoT device/sensor development. For this badge, an original or any of its 23mm pitch pin-compatible copies are fine.

You can get them much cheaper of Ali Express, but to get them in time for the conference and if you’re an Amazon Prime customer you can get them from here (though any board with a compatible pin-out is likely to work)

You then need need something to act as a keyboard interface and power source, a laptop works fine with a USB cable works fine, but we’re sure some of you will come up with inventive alternatives.

It would be nice to solder them on the day, but the venue doesn’t allow for that, so the good new is, you can actually get it working without the board.

Then what?

The easy way? Just turn up to the SBG Firmware Flashing Station (located in the <insert place> with your LoRa board and we’ll drop @LargeCardinal’s custom firmware on it, pass you some info <link tbc> on how to hook it up to a PC/Mac/Linux box and let the magic begin.

Easy as that!

However, if you want to do it all yourself, see this guide <link tbc>

The Internal Bug Bounty Programme*

Please see this post before reading, for important caveats about the sources of information used to help construct this post.


One of my favourite Security subjects is Bug Bounty Programmes, mainly because I was lucky enough to start work somewhere big enough to already have an internal programme in place and where I was wholeheartedly encouraged to get involved with its operation and help transform it into an external programme by its architect and implementer Dan Adams.

Internal Bug Bounty Programmes

The inspiration for this post came from this post on LinkedIn from the Product Security Engineering Manager of Lyft

As internal programmes are something I have experience with, but aren’t talked about publicly much, I figured it would make a decent blog post to start the New Year.

So, for those new to the idea of internal Bug Bounty Programmes, they are essentially private (invite-only) programmes, where invites are only available to staff members of the company offering the bounty payments (often an implicit blanket invite to all technical staff).

Doing this has some real big benefit and a few draw backs, so lets run through each in turn.

Learn as you go

Getting a Bug Bounty Programme right first time is very hard. An internal programme genuinely lets you develop robust processes and procedures ahead of an external launch.

If you’re upfront about the programme being a learning exercise then internal staff can be much more forgiving of slow triage, poor communication, vague or confusing scopes, and inconsistent or slow payments (all common problems with newly launched programmes). Making your internal hunters an important and valued part of your process can be the dividing line between “they listened to our feedback” and “they constantly keep moving the goalposts”.

Everything from your scope, your rules of engagement and your payment structure may need refining or even completely rewriting once you programme is live. That’s MUCH easier to achieve when it won’t cause disruption outside your organisation.

Flow Control

One lesson I learnt early from both Dan and from Bug Bounty Pioneer Katie Moussouris** is that one of the keys requirements of launching a bug bounty programme (or even knowing if you’re ready for one) is understanding your ability to handle the flow of incoming info the programme will bring. Having the resource to efficiently triage, remediate and pay bounties on new vulnerabilities is often a key differentiator between the launch of a successful programme and an embarrassing, expensive or unproductive one, but for many organisations launching as internal-only can limit that risk somewhat.

If you find you genuinely can’t keep up with the flood of new vulnerability reports, then being internal-only makes it much easier to change which classes of vulnerability are in-scope, refine the process or pause the programme altogether without upsetting the wider bug bounty community.

Unfair Advantage

When planning to launch a programme it’s not uncommon to lose sight of WHY you’re doing this. People try to create a fair and level playing-field so all hunters have the same chance of getting a bounty. If your aim is creating a challenge to find the best bug bounty hunter or simulate specific attacks then great, but it’s safe to say that ISN’T your aim. Most people are in it to collect the high quality vulnerability info they don’t already get from other sources, so why tie hunters hands behind the back.

The most successful internal programmes I’ve seem leverage the home-field advantage of internal hunters to go harder and deeper with less time wasted on dead ends by allow/encouraging hackers to review source code and design documents as well as going and talking with the development teams directly. Remember, even if you only care about public facing vulnerabilities and demand a PoC from a public network, that doesn’t mean your hunters need to be limited to doing their initial investigations from only public networks. It may be your website has a serious inject issue that’s currently mitigated by a WAF rule, but what happens when that rule is updated or you switch to a new vendor with a different vendor?

That said, it’s not uncommon to put the same Bounty Conditions on Internal hunters as you would on external ones, such as the vulnerabilities must be exploitable from the public internet.

Obviously achieving this may vary vastly from organisation to organisation, it’s not unusual for smaller organisations to have access controls that give all engineers the same flat access to all your source code repositories, design documents and network segments etc, but in larger organisations it may be necessary to allow hunters to apply to temporarily gain access to other teams’ resources to aid investigation.

Remember when it comes to paying, the value to you is in the information you receive, not the effort that was put into gaining that info, the fact internal hunters may have an unfair advantage and easier time doesn’t make their information any less valuable, so I’m therefore a big advocate of making internal payment structure identical to any external/public offerings you may have.


One of the big annoyances for bug bounty hunters that has never really been addressed effectively is that of duplicate reports***. Most programmes only pay for the first reported instance of a vulnerability (otherwise not only are they paying for info they already have, but it would be possible for news of the vulnerability to pass from hunter to hunter) and understandably programmes don’t want to share publicly what vulnerabilities have been found but not yet fixed, so inevitably you end up with hunters using their time and talents to hunt down valid vulnerabilities, only to be told that they’ll get no reward as it’s already been reported.

In many cases internal programmes can lessen the pain, either by allowing staff to their internal bug trackers or encouraging communication between hunters and triagers can at least feedback if there have been reports for classes of vulnerabilities in the areas hunters are hunting.

Better Signal to Noise Ratio

Internal schemes can be much easier for internal triagers as the quality of the reports can be much higher and obtaining elaboration on unclear points can be so much easier to obtain.

Never underestimate the time that can be saved when the reporter has a decent understanding of your estate, the technology you use, your internal processes and your organisations general risk appetite. You tend to find that not only will you get high quality reports of the actual vulnerabilities, but often pointers to the source of the vulnerability.

Of course there will always be exceptions, but as a general rule internal reports are generally much quicker and easier to triage, contain much more info helpful to the team doing the remediation and contain far fewer false positives and incorrect assumptions.

Subterfuge and collusion

Whenever I talk about internal programmes the first question is “How do you stop people adding bugs so they can report them?”.

Whilst a rule that nobody can report any problem in a part of the code base they’ve worked on (or in some cases they were part of a team that worked on that area) is common, the real answer is much more cultural. Do you have a hiring policy that would attract people who would risk their employment and their reputation for a few thousand dollars in bounty payments?

The cons

So far I feel I’ve put forward a fairly compelling case that if you are in a position to launch a programme, start it as internal only, but what about the cons?

Over burdening hunters. Bug Bounty Hunting is fun, but it can also be infuriating, stressful and time consuming. Do you want your engineers spending all their free time thinking about finding vulnerabilities in your codebase? Or do you want them to switch off and think about something else entirely? Are you confident they’ll limit their hunting to just their free time, or will they actually be picking up a second job that impacts their first once. However, as with “Subterfuge and Collusion” if you feel this might be a problem, are you hiring the right people?

Rapidly Declining Interest. Whilst a new internal programme may introduce many new people to the world of bug bounty hunting, for the majority of people interest will wane over time and the flow of new vulnerability info will reduce. Things like short term incentives and events like charity hack days can garner increased participation but at some point it’ll stop being the cool and new thing and you’ll have to start looking externally for new participants.

Disillusioning external hunters. Bug Bounty hunters hanker for new programmes where all the low hanging fruit has been hoovered up and everything the find isn’t already reported and therefore a dupe. So, when you’re ready to move from internal to external, having it known amongst external hunters that your programme has already been ravaged by bug hunters and there the effort/reward balance will be more favourable elsewhere

Final Tips

Don’t launch an Internal Bug Bounty Programme, build an internal Bug Hunting Community, with the programme at the heart of it.

Plan for the future, always ask yourself “Would this also be Ok if the programme was a public one?”

Fix problems at source. It’s easy to use the Bug Bounty Programme as a ticket creation factory, but ensure you’re collecting data on the root cause of vulnerabilities and feeding that data back into the SDLC

Define your metrics, goal and reporting from the start. Even internal Programmes are expensive to run, so ensure you can prove the value of the scheme. Remember knowing about 1000 unmitigated make you at no less risk the knowing about 10 unmitigated ones, be able to prove programme is actually lowering risk.

Make the journey from your Bug Bounty Platform as frictionless as possible, so people choose to report things via the bug bounty platform, even if they are not sure if they actually qualify for bounties, rather have them sat on bugs where they can see something isn’t right, but can’t exploit it in a way that would guarantee a bounty

Don’t be afraid to change things. Launching as an Internal Programme gives you more freedom to change things that aren’t working as well as you’d hoped, use that to your advantage.

* You’ll notice that when referring to Bug Bounty Programmes I use the older English (British) spelling of the word Programme, but when referring to computer Programs I use the newer (US) one. This is intentional, though I can’t really justify it, other than I’ve always felt it was correct

** If you’re interested in Bug Bounties and you don’t know who Katie is, stop reading now and go read everything she’s written on the subject first.

*** Whilst it doesn’t really help on-going programmes for their events (where certain sites are put in in-scope to a limited period to an invited set of hunters) HackerOne have an initial window (normally 1hr) where hackers can report all the low-hanging-fruit they found during reconnaissance before the event and they all the share the bounty payment, which is an interesting way to tackle the inevitable dupes where when of the best bounty hunters in the world are given the same target and some advanced warning.