Quite frankly, this one annoyed the hell out of us for a long time. When you're chaining together a process and hit a dead-end, sometimes you really just need to re-evaluate what you're looking at. Anyways, we finally got this sucker squashed and were very glad it was done :)

The file was again xz compressed and after a quick rename the download to  3fdcf74b01bd93635e653eb29e43ee8c.xz it can be decompressed with:

xz -d 3fdcf74b01bd93635e653eb29e43ee8c.xz

The resulting content of the decompressed file is (sans linebreaks):

425a68393141592653592e45594800006c490040007fe03f00300159b4db4553f09a68f21484553fd3
26c84ca53114f04d3349a2029371ed412bb78a8b838cf39d35a34f7951757516dada7d2366ba56e823867
9a2775952e0a8219be68d55f27777bbde08bea5382b2d1cd8f6011f242d9fbcf1da93776cda92231c1
1caf66b72bc0faf81c24f2e93d91960eee496dd8d1e8a6c9a6a8276e803fdb530d9f0a3d66268749c6
91a870e1bd130b49ce9865f522dd4b3f525f24a6ae1029efb7bcd5ac31e25fce9b175b703cc8ec6515
14a9a580d7d057ac1847c9578bf60c301219ebac1fc7d95a45fd0d69c6fa396ce7a8b533d6dafd6b17c
0a7c603d4870d93d8082f5f23c57a1b8a2225c6f17043fb6049f9552b340e3d9c53e46d4dceb8963
b9309590bfc5dc914e14240b91565200

The resulting content appeared as (sans linebreaks):

BZh91AY&SY.EYH^@^@lI^@@^@^?à?^@0^AY´ÛESð<9a>hò^T<84>U?Ó&ÈL¥1^TðM3I¢^B<93>qíA+·<8a><8b><83><8c>ó<9d>5£OyQuu^VÚÚ}#fºVè#<86>y¢wYRà¨!<9b>æ<8d>Uòww»Þ^H¾¥8+-^\Øö^A^_$-<9f>¼ñÚ<93>wlÚ<92>#^\^QÊökr¼^O¯<81>ÂO.<93>Ù^Y`îä<96>Ý<8d>^^<8a>l<9a>j<82>vè^Cýµ0Ùð£Öbht<9c>i^Z<87>^N^[Ñ0´<9c>é<86>_R-Ô³õ%òJjá^B<9e>û{ÍZÃ^^%üé±u·^CÌ<8e>ÆQQJ<9a>X^M}^EzÁ<84>|<95>x¿`Ã^A!<9e>ºÁü}<95>¤_ÐÖ<9c>o£<96>Îz<8b>S=m¯Ö±||`=HpÙ=<80><82>õò<W¡¸¢"\o^W^D?¶^D<9f><95>R³@ãÙÅ>FÔÜë<89>c¹0<95><90>¿ÅÜ<91>N^T$^K<91>VR^@

Notably, the header of this file is bzip2 (BZh). Running a bunzip2 on the resulting output created another file.

789c358e516bc3201446dffd1561980741b3da1b6392b53298da1996c1924866a00f1d2d632f7ddaff67371
d7d94fb79cef9ba7cff5cb3aaaab2ddf9f47b32a4072725b7475a412e5a4b87fa101a5ea6a59d9d90b98d7
008c294912aed8ad6bf0da0432368ec369017a4577948e083e05edc091f50ca95f0be05f6d27a1ef1cef87
3102ab7e39d56cf017f3fd969a8275cfff3d0e73e71c1b867cb56ef0b45e9ed6e68ea0018bedd8cb4066d0
be96b2c44df08566251eab0f04678b0ab5b08e3f9886bc5a7d8ad34e3903607b69f5247748575c68b843e
b92eb0be30761a41ef8e8f9bd78c64e4723d933f37f34798

This is where things went bad for me. Wolfgang Goerlich luckily figured out what I didn't, which is that this stream of data was actually using zlib! I had kept doing hex->ascii and would get 'x<9c>' which meant nothing to me or google. Well the problem was, the x should have just been '78' (you know, like the original hex!). Once we realized this, I was able to use Python again and the zlib.decompress method to get another result in uuencoded data.

begin 666 <data>
M3E11,D]$63%-:D$R8GI9,4YZ:WE-1%DU3GI->4U$57E.:FLR37I9-$UJ03%.
M5%IY3FI-,F-$63%-:D$Q3419,4YN23)C:F,U3FI),@I-5%DS3GI->4U$8WI.
M;DTR8T19,$UJ03%-1%EX3GI),F)Z27=.5$$R8T19>$YJ33).5$EW3FI9,F-Z
M8WE-:D$S3D19-$YJ57E-1%EX"DYN23-->F,S3FI5,TUJ27=.>E$R8WI)=TYJ
763)C>F-Y3GI1,TUJ63%.>DTS37<]/0H 
end

Running this data through uudecode, the result is an (obviously) base64 encoded string.

NTQ2ODY1MjA2bzY1NzkyMDY5NzMyMDUyNjk2MzY4MjA1NTZyNjM2cDY1MjA1MDY1NnI2cjc5NjI2
MTY3NzMyMDczNnM2cDY0MjA1MDYxNzI2bzIwNTA2cDYxNjM2NTIwNjY2czcyMjA3NDY4NjUyMDYx
NnI3Mzc3NjU3MjIwNzQ2czIwNjY2czcyNzQ3MjY1NzM3Mw==

Guess what! This results in more hex :)

546865206o6579206973205269636820556r636p652050656r6r796261677320736s6p64205061726o2050
6p61636520666s722074686520616r7377657220746s20666s727472657373

Throwing this through hex->ascii we finally get something usable!

The ?ey is Rich U?c?e Pe??ybags s??d Par? P?ace f?r the a?swer t? f?rtress

With a little deduction we realized the correct string was:

"The key is Rich Uncle Pennybags sold Park Place for the answer to fortress"

Submitting the key as 'Rich Uncle Pennybags sold Park Place for the answer to fortress' did in-fact work as expected.

For those keeping track that makes this process..

xz -> hex -> bzip2 -> hex -> zlib -> uuencoded -> base64 -> hex -> guessing letters :)