Posts Tagged ‘base64’

A closer look at Dine & Discover NSW Vouchers

25 Mar 2021


The NSW Government has launched Dine & Discover NSW to encourage the community to get out and about and support dining, arts and tourism businesses.

NSW residents aged 18 and over can apply for 4 x $25 vouchers, worth $100 in total.

  • 2 x $25 Dine NSW Vouchers to be used for dining in at restaurants, cafés, bars, wineries, pubs or clubs.
  • 2 x $25 Discover NSW Vouchers to be used for entertainment and recreation, including cultural institutions, live music, and arts venues.

The Vouchers

There are two ways to access these vouchers:

  1. Email – Vouchers are initially emailed to eligible participants of the program after they sign up.
  2. ServiceNSW App – Vouchers can be accessed from the ServiceNSW

The initial email contains a PDF attachment that contains vouchers that look like this:

Discover NSW Voucher

Dine NSW Voucher

Each voucher has a few pieces of metadata attached:

  • The voucher type (Dine or Discovery)
  • A 9 character voucher code such as ED04K31MB (omitted from screenshots above)
  • A QR code with embedded data
  • An expiry date (in this case 30-Jun-2021)
  • Value (in this case $25)

Using the vouchers

There are two ways you can redeem your vouchers online or in-person:

  1. You can supply a participating business with your 9-char voucher code such as ED04K31MB
  2. You can show a participating business the QR code which exists to promote COVID-safe contactless interactions.

Email Vouchers vs ServiceNSW App Vouchers Discrepancy

There appears to be a discrepancy between the voucher codes and QR codes sent in the original email and the ones that appear in the ServiceNSW mobile app. The codes sent in the email seem to be the original codes and are “long life”. The codes generated in the ServiceNSW app seem to be generated each time you click on a voucher. They are likely temporary codes that, in the end, are all linked back to the unique identifier for your voucher. So once you use the code in the email or any code generated by the app, your uniquely identified voucher will be marked as used.

ServiceNSW App Dine Voucher

I didn’t test using old codes though but I’ll give ServiceNSW the benefit of the doubt here. 😉

Voucher format

Dine and Discover NSW Voucher Format

Each voucher is 9 characters in length.
Discovery vouchers always start with the letter G. Dine vouchers always start with the letter E.
The remaining 8 characters seem to be random alphanumeric characters (case-insensitive).

That QR code though…

Scanning any of the voucher QR codes gives us some plain text.

Dine/Discover Voucher (ServiceNSW App)

For example here is the output from scanning a Discover voucher from the ServiceNSW app:

This is a Base64 encoded string that represents the following JSON object:

We have a few fields present:

  • v: voucher
    • d: data – the first 8 characters here appended to G or (based on type) to create the voucher code; it is unclear what the last 8 digits represent (checksum or additional code?)
    • t: type of voucher, either CSG (for discovery vouchers) or CSE (for dine vouchers)
  • ts: timestamp – ISO8601 time string representing the time the voucher code was generated
  • m: unknown – as a 64 character hexadecimal hash it may be a SHA256 hash but I am not sure what it could represent (perhaps member?)

Dine/Discover Voucher (Email)

Interestingly, the QR code output from the vouchers in the email is different.

For example here is the output from scanning a Dine voucher from the email:

This is a Base64 encoded string that represents the following JSON object:

We have a few fields present:

  • v: voucher
    • d: data – this appears to be the unique identifier of our voucher in UUID format (which is what the temporary voucher/QR codes from the ServiceNSW app are likely linked to)
    • t: type of voucher, either CSG (for discovery vouchers) or CSE (for dine vouchers)

Notice how the ts (timestamp) and m (unknown) fields are missing here.

Third-Party Validation API

The obvious attack vector here is the participating businesses that accept these codes. There is likely a private API exposed by ServiceNSW and provided to participating businesses to validate and use these vouchers. I discovered that Hoyts (a participating business) was using this API behind the scenes through their own API proxy here:

This API takes a voucher code and returns a few responses based on the result of the validation.

Valid (unused) voucher:

Valid (unused) voucher but the user has already redeemed voucher at this business during this business day:

Valid (unused) voucher but wrong type:

Invalid (already used) voucher:

Invalid (not found) voucher:

Invalid (wrong format) voucher:

Bruteforce attack

Each voucher code is 9 characters long. As the first character is hardcoded, this leaves only 8 characters. It appears that the next 8 characters are random alphanumeric characters. Furthermore, by testing an API we discover we can confirm that upper and lowercase characters are equivalent. In other words, the voucher codes are case insensitive.

This leaves us with a character set of 36 characters (26 letters of English alphabet + 10 digits):

There are roughly 8 million residents in NSW. Modestly assuming 60% of those are adults over 18 and eligible for the NSW Dine & Discover voucher program, there are potentially up to 4.8 million vouchers originally generated and sent to a users email address. However, the total number of unique 8 character combinations with the above character set is 36 pick 8, or 2 821 109 907 456 (~2 trillion). Double that for each voucher type. That means that at best only 0.0001701% of the maximum combinations will be valid voucher codes for each voucher type. We are ignoring the temporary generated voucher codes here as they may expire and are likely not frequently generated until just before they are used.

If this were a password hash, with only 8 characters of entropy and a 36 character set, it would definitely be feasible to brute force the entire combination set. 8 character passwords with a character set this small are not secure and can be cracked offline from a hash within 10 – 30 days with moderately cheap hardware.

Unfortunately, though, we are forced to validate our codes online through the Hoyts API. This is much, much slower than GPU hash cracking due to the cost of networking and has other unwanted side effects:

  • Slow network-based validation technique
  • Raising suspicion by server maintainers through metrics they collect around API usage
  • Bringing additional load onto Hoyts servers and by extension ServiceNSW servers
  • Running into rate limiting issues (severely reducing the effectiveness of our brute force attack)

Bruteforce attempt and results

Nevertheless, in the spirit of giving it a go and in good faith I attempted a hopeless brute force attempt. I started a cluster of AWS lambdas in the ap-southeast-2 region running a simple Python scraping script. For simplicity, I logged any unexpected API responses to Cloudwatch. This code will not be released publically for obvious reasons. Furthermore, I time-boxed this experiment to only 12 hours as I would prefer to not needlessly burn money through AWS fees.

Unsurprisingly, I found no other valid voucher codes and that is good news for everyone.

Now get out there and kick start NSW again!



Posted in Penetration Testing


Hackvent 2019: Day 3

03 Dec 2019
CTF: Hackvent 2019
Link to challenge:
Date Completed: 3 December 2019


HV19.03 Hodor, Hodor, Hodor


At first this looks like it may possible be a hidden code with different variations of hodor mapping to English alphabet characters. However, before we look into frequency analysis we do a Google search for hodor programming language and discover that such an esoteric language exists!

We find an online interpreter/compiler TIO capable of running Hodor code and get this output:

As the hint suggests, we need to base64 decode that last string.

Doing so gives us our flag!

Flag:  HV19{h01d-th3-d00r-4204-ld4Y}

No Comments

Posted in Hackvent 2019


HACKvent 2015: Day 8

08 Dec 2015
CTF: Hackvent 2015
Link to challenge:
Date Completed: 08 December 2015


Link to website (may be down):


I inspect the source of the website and take a look at the background image but that seems to be fine. There is nothing else of interest on the website so I figure this may require a brute-force attack.

I then however find a cookie that is generated once I fail to authenticate with the website. I try to login using the username admin and the password pass. The following cookie is generated for me:

I then replace %3D with =  and decode the above as base64.

Thus it is obvious that the cookie is simply calculated like so:

I then try to tinker with the cookie fields. I figure that the challenge would not be making any database calls and thus the password would be hardcoded. In this case, the PHP code in the authentication script would look like so:

The above uses strict comparison. However, the PHP script may use loose comparison which opens up a vulnerability. This turns out to be the case and the script does something like this:

In the above examples SOMETHING can be anything we want it to be. It does not have to just be a string. We could modify our JSON payload to pass a value like true  as the username and password. This is what we will do as a loose comparison with true is almost always true (unless the true username or password is “0” which is unlikely).

We construct our payload:

Then we encrypt this using base64 (converting all =  symbols back to %3D ):

Finally, we use a scripting language or a web browser extension (I used EditThisCookie for Chrome) to load the cookie for the webpage. Then we refresh the page and are greeted with the following message:

The goodie is our flag!

Flag:  HV15-0Ch0-91zo-m99Y-kxGI-8iQ5

No Comments

Posted in Hackvent 2015


HACKvent 2015: Day 6

08 Dec 2015
CTF: Hackvent 2015
Link to challenge:
Date Completed: 08 December 2015


We are given the following string:


We can deduce by the amount of padding that this is Base32 encoded string. We use an online decoder and get:

Then we try various other things to decode the above string. I will admit I failed to find a proper solution until I received some help from SlEePlEs5 on the hacking-lab IRC. Then I was able to realise that I had to decode the above string using ASCII85. I get:

Great! This looks a lot like our nugget. I guess a simple Caesar cipher is required here and find the offset number to be 13 (as we want U->H for first character in our nugget). We apply the cipher (basically ROT13) and get our flag!

Flag:  HV15-t9P8-QaIV-J0Ar-83F3-M8Dc

No Comments

Posted in Hackvent 2015