Lily FLAC Writeup (Boston Key Party CTF)


Category: Misc Points: 2

Description: Its more than just a few bleebs 😉

This challenge gave us a Free Lossless Audio Codec (FLAC) file.


I played the file in a audio player and can hear a lot of static bursts  at the beginning and middle of the track. This static bleeps would generally refer to data. So I thought it could be audio steganography using LSB encoding. In order to retrieve the data chunks, first I converted the flac file in to .wav format.

Then wrote a ruby script to decode the LSB encoding:

require ‘rubygems’
require ‘wav-file’

wav = open(“Converted_file_658ef39d.wav”)

format = WavFile::readFormat(wav)

chunk = WavFile::readDataChunk(wav)

# format is 16 bit so using s* to unpack

wavs =‘s*’)

# Read lowest bit and put them all together

lsb ={|sample| sample[1]}.join

# Find the first 1 in the lasb output and pack it back for output

flag = lsb[(lsb.index(‘1’))..-1]

puts [flag].pack(‘b*’)


The output was quite unexpected, it essentially gave me a bunch of random data and mostly just zeroes. So its not LSB encoding. My next hunch was visualizing the frequency waveform and spectrogram for the flac and see if there is any data there.





As can be seen from the images above, there wasn’t any sight of visible data and so another fruitless attempt. I went back to hearing the audio and since the static was irregularly spaced in time, opened it up in hex editor to have a look.

hex editor view


Taking a closer look at the start of the hex file we see the letters “E. L. F” hinting us that its an executable and linkable format (ELF). I immediately converted the flac to its raw format file (should have been the first thing to do but better late than never) using the command:

sox 87582357ff1a7c3e8d11c749ac12ad819f8f7d4b.flac output.raw

Once I had the raw file I got an object dump for it and analyzed it using the command:

objdump -S output.raw

Looking at the assembly code it was apparent that the program runs and gathers bits of data from various parts within itself and displays a string as output. So just ran the executable as follows:

chmod +x output.raw


And Voila ! Result was the flag:

BKPCTF{hype for a Merzbow/FSF collab album??}

DES-OFB Writeup (Boston Key Party CTF)


Category: Crypto Points: 2 Description:

Decrypt the message, find the flag, and then marvel at how broken everything is. The challenge gave us a Cipher text file and a python script implementing Data Encryption Standard (DES) in Output Feedback (OFB) mode as shown below:

from Crypto.Cipher import DES

f = open(‘key.txt’, ‘r’)
key_hex = f.readline()[:-1] # discard newline
KEY = key_hex.decode(“hex”)
IV = ‘13245678’

f = open(‘plaintext’, ‘r’)
plaintext =

ciphertext = a.encrypt(plaintext)
f = open(‘ciphertext’, ‘w’)


This overall was a fairly straightforward crypto problem requiring a little maneuvering. There is a little math involved but I promise it ain’t too hard and makes solving the problem so much easier. In order to make this comprehensive, here is a brief about DES in OFB:


Mathematically, this could be written as:

 Cj = Pj ⊕ Oj            —— (1)

Oj  = Ek(Ij)             —— (2)

Ij = O(j-1)                —— (3)

I0  = IV                    —— (4)

where  Cj  = jth ciphertext block, Pj = jth plaintext block, IV = Initialization vector

and Oj = jth encrypted input vector.

Using (2) and (3) we can also get:

Oj  = Ek(O(j-1) )       —— (5)

Now since we know that an xor (⊕) operation is symmetric in nature, from (1) we have:

 Pj=  Cj ⊕ Oj            —— (6)

Again using (2) and (6) we have:

 Pj=  Cj ⊕ Ek(Ij)       —— (7)

Lets consider (7) for j =0 and using (4):

         P0=  C0 ⊕ Ek(IV)       —— (8)

Again consider (6) for j =1, then using (5), followed by (2) & then finally (4):

         P1=  C1 ⊕ O1   =  C1 ⊕ Ek(O0)  =  C1 ⊕ Ek(Ek(I0))  =  C1 ⊕ Ek(Ek(IV))   —— (9a)

Again consider (6) for j=2, similarly we have:

       P2=  C2 ⊕ O2   =  C2 ⊕ Ek(O1)  =  C1 ⊕ Ek(Ek(Ek(I0)))  =  C1 ⊕Ek(Ek(Ek(IV)))   —— (9b)

Using (8), (9a) & (9b) we can generalize the formulae for odd(starting with 1) blocks and even(starting with 0) blocks:

Peven =  Ceven ⊕ (odd number of times Eof (IV))      —— (10)

Podd   = Codd  ⊕ (even number of times Eof (IV))      —— (11)

Considering the clue in question as to marvel on how broken everything is, I assumed DES weak keys, meaning the encryption and decryption operation are identical. Hence (10) and (11) could further be reduced to:

Peven =  Ceven ⊕ E(IV)

Podd   = Codd  ⊕ IV

Since from the given python script for the challenge we know IV = ‘13245678’, thus we can solve and get the value plaintext blocks for all odd(starting with 1) blocks. Since we don’t have the key value, we cant just yet get even blocks but its a start. So I quickly wrote a script for the same as shown below:

from Crypto.Cipher import DES, XOR
import operator
block_size = DES.block_size

IV = ‘13245678’
f = open(‘ciphertext’, ‘r’)
ciphertext =

plainblocks = ”


while True:

cj = ciphertext[(i*block_size):((i+1)*block_size)]
if not cj:                                                 # the last iteration was the last block

xor =
if (operator.mod(i+1,2)==0):
plainblock = xor.decrypt(IV)
plainblock = cj

i = i+1
plainblocks = plainblocks + plainblock

print plainblocks

Running this python script using the ciphertext gives us the following broken output:

p+{��’S�r not to&>��t is the5.��n:
WhethA6{��b�Nobler iJd/��+�nd to suB”>��_� Slings E*?��y�ws of ouP6:��d� FortunN��take ArmWd:��b�t a Sea K”{��d�les,
And&”��{�sing end03��1S�o die, tKd(��n�No more;%5��i
�a sleep,04��j
�we end
TL!{œj�-ache, aJ {��nS�housand j%/��j�shocks
TL%/��g�h is heiVd/��+T�is a conW16��n
DevoutH={��+� wished.4��b� to sleeThQٙ+�eep, perG,:��nS�o Dream;%”��+�ere’s thAd)��’y�or in thE0{��n� of deatLh{��j�dreams mE={��f�
When we,:��+�uffled oB”{��b�mortal cK-7��F�t give uWd+��x� There’s03��y�pect
ThaPd6��n�Calamity+=��dS�ong lifeN��+�o would F!:�� Whips aJ {ޕd�s of timAhQٞnS�ppressor7{��d�, the prK1?��j�s ContumA(“��_� pangs oBd?��{�ed Love,03��G�’s delE=w��c�insolencAd4��D�ice, and03��X�rns
That4:��n� merit oBd/��+�worthy tE/>��$�en he hiI7>��+�ght his u12��~�make
WitLd:��j� Bodkin?3��|�ld FardeH7{��j�
To grunPd:��+�eat undeVd:��n�y life,
f1/��c� the dreE {��+�mething E”/��+�ath,
The15��x�vered CoQ*/�S�rom whosAd9��y�No TraveH(>��y�urns, Pu^>7��+�e will,
e*?��j�s us ratL!)��n� those iH((��nS�ave,
ThaJd=�� others P,:��|�know not+=��_�s ConsciA*8��o�s make CK3:��xS�f us aN��+�us the NE02��+�e of ResK(.��d�Is sicklM!?��,�, with tL!{��g�cast of p,4��c�
And entA6+��x� of greaPd+��h�and momeJ0w��b� this reC%)��ir CurreJ0(��~� awry,
AJ {��x�the name+=��h�on. Soft=4��e�,
The faM6{†c�ia? NympLh{��+�y OrisonWN��j� my sins6>��f�red. BKPg��d,�ts_just_E�y�repeatinC4��*�

Considering it closely this is text from the play Hamlet Act 3 scene 1. And its start aligns with “To be, or not to be?” from original text. Using this information I now have P0 and C0 blocks and thus can calculate the value of Ek(IV). Hence I can decrypt all the even blocks as well. The refined final python script highlighting the update is given below:

from Crypto.Cipher import DES, XOR
import operator
block_size = DES.block_size

IV = ‘13245678’
f = open(‘ciphertext’, ‘r’)
ciphertext =

hint = ‘To be, or not to be? That is the question’

p0 = hint[:block_size]

c0 = ciphertext[:block_size]

xor =

ek = xor.decrypt(p0)

plainblocks = ”


while True:

cj = ciphertext[(i*block_size):((i+1)*block_size)]
if not cj: # the last iteration was the last block

xor =
if (operator.mod(i+1,2)==0):
plainblock = xor.decrypt(IV)
plainblock = xor.decrypt(ek)

i = i+1
plainblocks = plainblocks + plainblock

print plainblocks
f = open(‘output’, ‘w’)

And when we run this script, Voila !  (#flag is write at the end).

To be, or not to be, that is the question:
Whether ’tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles,
And by opposing end them: to die, to sleep
No more; and by a sleep, to say we end
The Heart-ache, and the thousand Natural shocks
That Flesh is heir to? ‘Tis a consummation
Devoutly to be wished. To die, to sleep,
To sleep, perchance to Dream; aye, there’s the rub,
For in that sleep of death, what dreams may come,
When we have shuffled off this mortal coil,
Must give us pause. There’s the respect
That makes Calamity of so long life:
For who would bear the Whips and Scorns of time,
The Oppressor’s wrong, the proud man’s Contumely,
The pangs of despised Love, the Law’s delay,
The insolence of Office, and the Spurns
That patient merit of the unworthy takes,
When he himself might his Quietus make
With a bare Bodkin? Who would Fardels bear,
To grunt and sweat under a weary life,
But that the dread of something after death,
The undiscovered Country, from whose bourn
No Traveller returns, Puzzles the will,
And makes us rather bear those ills we have,
Than fly to others that we know not of.
Thus Conscience does make Cowards of us all,
And thus the Native hue of Resolution
Is sicklied o’er, with the pale cast of Thought,
And enterprises of great pitch and moment,
With this regard their Currents turn awry,
And lose the name of Action. Soft you now,
The fair Ophelia? Nymph, in thy Orisons
Be all my sins remembered. BKPCTF{so_its_just_a_short_repeating_otp!}

Anatomy of “includeSubdomains” directive in HTTP Strict Transport Security Policy

In my previous post, I gave a general introduction to HTTP Strict Transport Security (HSTS) and this post would be a follow up to that, talking specifically about “includeSubdomains” directive used in HSTS policy. If you are not familiar with HSTS, I suggest you read the previous post here, before reading this post.

What is the significance of “includeSubdomains” ? (references RFC 6797)

In the absence of “includeSubdomains” directive the web application would be unable to protect its “domain cookie” in an adequate way, even though the host has its secure flag set. To understand this lets consider the following use case examples:

  • Using HSTS without “includeSubdomains” directive

Suppose there exists a top-level DNS domain name for a website which is “” and a cookie is being set for the entire “”, this cookie is termed as “domain cookie”. Also, assume that the secure flag is set by the website (which actually means cookie can be sent only for HTTPS requests).

Now, here if an attacker manages to register a non-existing domain say and manages to point the DNS entry to an existing  HTTP server under his control; this would mean the following:

    1. The user’s browser (user agent) is unlikely to have any HSTS policy set for the domain, as it is some random sub-domain name introduced by the attacker.
    2. And if the browser makes a request to the “”, this will send an HTTP request and also include the secure flagged cookie (as the registered domain is HTTPS).
    3. Assuming “” presents a TLS certificate and the user clicks through it, this would lead to attacker obtaining the cookie [1].
  • Using HSTS with “includeSubdomains” directive

Here, the web application at “” domain, makes use of HSTS policy along with “includesSubdomains” directive. As a result, the browser will enforce any subdomain, even attacker’s “” to operate over HTTPS.

Thus, this would ensure adequate security for domain level cookie.

Issue of removing/disabling HSTS policy for sub-domain (references IETF draft message by Adam)

The usage of HSTS “includeSubdomains” lacks some clarity in terms of removal of HSTS policy for sub-domains. Consider the following scenario as depicted in figure 1:

figure 1: Removal of HSTS  policy for sub-domain

figure 1: Removal of HSTS policy for sub-domain

  • As shown in the figure 1, imagine the HSTS policy is first set for “” along with the “includeSubdomains” directive, this will mean that all the sub-domains for including “” needs to follow the HSTS policy.
  • Now, following this if the subdomain “” sets the max-age = 0 header, it basically means remove any HSTS policy for ““.
  • There are basically two course of action, firstly go for the MAX of expiration time {parent domain, sub-domain}, which would mean HSTS policy for the “” cannot be disabled and it would remain HSTS domain forever. (This might be a problem, if a sub-domain decides to move from HTTPS to HTTP but the naked domain is still HSTS.)
  • Secondly, letting the sub-domain max-age =0 to act as “do not include in sub-domain inheritance”, which though seems to be reasonable but is not. As essentially the policy is set at parent domain i.e. the naked domain and not at  sub-domain level. And letting the sub-domain to change the parent domain policy is not an appropriate approach.

Currently, Chrome’s implementation takes the first option; though there are possible work around to avoid sub-domain from being HSTS forever, there is no clean/clear way to handle it (even RFC doesn’t specify anything directly).

PS:- I am not sure how this is handled in Firefox or Safari, if you have any references please leave it as a comment.

——————————-End of Post ——————————————————

[1] It is possible, but not certain, that one may obtain a requisite certificate for such a domain name such that a warning may or may not appear.

HTTPS Everywhere :: Using HTTP Strict Transport Security

The concept of HTTPS, that is having the web traffic from your browser to the web server over an encrypted channel is widely used over the web. It ensures that no attacker in the middle can grab or modify transmitted information like your cookie data; hence preventing the hijacking of your web session. So, enabling HTTPS limits the capability of an attacker in the middle.

How can Man-in-the-middle (MITM) attacker work around HTTPS ?

Mostly when users wants to browse a website, for instance say bank of america website, they would generally type “bankofamerica” or “” in their browser address bar. On this browser would basically make an HTTP request to i.e., even though bank website operates as So, to rectify that bank website can redirect the HTTP request to HTTPS (by issuing a 302 re-direct), but it still leaves your HTTP request to the bank, vulnerable to attack by MITM before the actual redirection happens. The SSL-stripping MITM attack introduced by Moxie Marlinspike in his 2009 BlackHat Federal talk “New Tricks For Defeating SSL In Practice“, exploits this vulnerability. It would be much more safer if the HTTP request can be totally avoided and the browser itself knows that it should connect to the website over HTTPS. This is exactly what HTTP Strict Transport Security (HSTS) is meant to address.

(See the pictorial representation of above explained vulnerability in the figures 1 and 2. Figure 1 shows the normal redirect mechanism of the browser request from HTTP to HTTPS and figure 2 shows that attacker can intercept the initial HTTP request before the redirect to establish himself as MITM)


figure 2: URL redirect with MITM


figure 1 : 302 URL redirect scenario

How does HSTS operate?

HSTS support is implemented by adding a “Strict-Transport-Security” HTTP header to the server’s response, which will inform the browser that this website would connect only over HTTPS. Henceforth, any further HTTP request to website would be transformed at the client side/browser side itself into HTTPS, hence no network traffic goes over HTTP. So, sending:

Strict-Transport-Security: max-age=31556926;

would instruct the browser that the website sending this header should be accessed only over HTTPS for a year (as per max-age). Thus, the use of this header reduces the attack surface drastically: provided that the initial response (bootstrapping response) by the server reaches the browser without interception.

The website can take another step ahead and specify that all its sub-domains as well would be using HSTS by the use of “includeSubdomains” option as shown in the following example (though use of includeSubdomains is optional)

Strict-Transport-Security: max-age=31556926; includeSubdomains

Currently, HSTS has been implemented in Firefox, Chrome and Opera; though it is still to implemented in IE and Safari. The updated browser trends for HSTS and other features can be seen at BrowserScope.

(Apart from making the sub-domains oblige to HSTS policy, “includeSubdomains” has much more significance attached to it. This is covered in the next post here.)

Can we do something about HSTS Bootstrap MITM problem?

As we have seen that initial response from the web server which has the HSTS header should reach non-intercepted to the browser, in order to ensure complete security from adversary. This problem is referred to as Bootstrap MITM Vulnerability.

  1. One possible solution is to have a pre-loaded list of hosts in the browser for which HSTS would be on-by-default. Firefox and Chrome already support a pre-loaded list of hosts which want HSTS on by default. Chrome’s pre-loaded list can be seen here.
  2. Another potential solution is to include the HSTS information with DNSSec requests itself. Though, I have not come across any references which implement or mention details about it.

What HSTS is not meant for?

HSTS is not meant to prevent against:

  1. Phishing Attack: Rather, it complements many existing phishing defenses by instructing the browser to protect session integrity and long-lived authentication tokens.
  2. Malware: As malicious code executing on the user’s system can compromise a browser session, regardless of whether HSTS is used.

Note:- The HSTS specification published as RFC 6797 is based on the original work by Collin Jackson and Adam Barth as described in their paper “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks.

The Moulded Web :: Copyright Infringement

In an era of rapidly growing content on the web, along with the ease of organizing and retrieving it using massive content facilitators like Google, Copyright Infringement is freaking content providers out. More and more ordinary people are now mashing up music and videos or modifying the existing ones and publishing them online. Simultaneously, the powerful upcoming of Peer to Peer (P2P) technology is enabling supersonic distribution of these content and the fact that P2P are distributed systems, makes it even tougher for the content owners to track and take action against them. To put it in very simple terms, today there is technology to efficiently find content and also to rapidly distribute it, which is a nightmare for content owners.

Content owners have actively looked for ways to impede Piracy and have taken subtle steps over past few years to stop the same. Major ones are-

Targeting the P2P networks:
P2P networks basically are build upon two fundamentals: indexing, which indicates where the content is located and secondly sharing, which is the way of acquiring the content from the peers. So, in order to impede the successful operation of P2P networks, Content providers have targeted the indexing servers by techniques like denial of service. Also, another means used was to drench the actual information within a pool of injected extraneous or undesired information.

Million dollar question is:
How legal and moral are the ways and means used above? Some say its debatable but do these techniques really hold legality? [Left to the readers to answer]

Holding ISP Providers responsible:
Content owners initially called upon ISP providers to be primarly responsible for any sort of copyright infringement on their networks. This meant they should monitor the content floating on the network and actively blocking content which caused infringement. One of the techniques ISP’s adopt is a deep packet inspection (DPI), which involves analyzing actual packets over the network irrespective of whether the content is P2P exchange or an email or any other application content.

Does that ring any bell? It means ISP’s will peep into the privacy of the users of the network (that’s us)? Isn’t that violating Wiretap Act? [Ponder over it]

Though, the ISP providers have loosened out of the claws a bit after the upcoming of DMCA in 1998, which puts them now at secondary liability under certain conditions, but end-users privacy is still at stake.

Pressure on Content Facilitators:
As giants like Youtube, Google etc, act as a massive facilitator of digital content to the people on the web, content providers have constantly put pressure on them to block or remove content which are copyrighted.
So, on one hand Youtube has come up with a video filtering system which filters out all copyrighted content from being uploaded to the website in the first place. Some time back Youtube rolled out a beta version of the same.
On the other hand Google has been excluding copyrighted pages from its indexes and has come up with a future plan of further purging the content, which includes: Ensuring that Auto-complete doesn’t fill in words for copyrighted content, making authorized content more readily available, Reliable implementation of copyright take down requests within 24 hrs and improvising the adsense anti-piracy review.

Is this not moulding and restricting of actual information to entitled end-users?

After all web is all about content and if that is moulded, twisted and hidden from the users of the web, then in my opinion web looses its whole and sole purpose. The above discussed actions are not only invading our privacy but also robbing us off our democratic right to information.

Asymptotic Analysis

In algorithm analysis, the most general problem that is faced is that different algorithms to be compared work on different hardwares having entirely varied platforms. Hence, its very difficult to compare.

This problem at hand is solved by using the idea of asymptotic analysis. The idea behind the same is as follows –

1) Look at the growth of running time that is T(n) rather than n itself.

2) Ignore machine dependent constants.

As a result of the above, this analysis can be used for comparing both relative and absolute speeds irrespective of the platforms. Thus, asymptotic analysis is a vital concept which is a bigger picture of the comparison rather than a closer lookup of the same.

For example consider –

1) Algorithm 1 having a Theta(n^3)

2) Algorithm 2 having a Theta(n^2)

So for n -> infinity, Theta(n^2) is always going to be faster than Theta(n^3), no matter even if we run algorithm 2 on a slower computer and algorithm 1 on a faster one.

So, we see how using Theta notation of asymptotic analysis enables us to compare two algorithms irrespective of platforms.