December 2011 TechLife Challenge (Possible Reward)
#1
Posted 13 December 2011 - 02:48 PM
#2
Posted 13 December 2011 - 04:29 PM
#3
Posted 13 December 2011 - 05:39 PM
#4
Posted 13 December 2011 - 05:59 PM
When you find the key, you will know that you have the right one (before you have it, you won't see anything that looks even like a key).
#5
Posted 13 December 2011 - 06:01 PM
B361855A10325CC4CD7CF63044E35C49DC89F302?
#6
Posted 13 December 2011 - 06:17 PM
Yes
#7
Posted 14 December 2011 - 06:33 AM
Please share the key on the thread @TLF.
#8
Posted 14 December 2011 - 08:53 AM
Reward is $10 CAN, payable via my PayPal. Just something exciting for the Christmas season
#9
Posted 14 December 2011 - 09:18 AM
#10
Posted 14 December 2011 - 09:24 AM
#11
Posted 14 December 2011 - 09:30 AM
Can you please share the steps to solve the problem with us?
#12
Posted 14 December 2011 - 09:49 AM
I opened the file in a hex editor and quickly identified the target as a broken zip file. Instead of rebuilding the zip structure by hand, I just decompressed the raw content.@joakim/Icecube,
Can you please share the steps to solve the problem with us?
#13
Posted 14 December 2011 - 08:51 PM
I opened the file in a hex editor and quickly identified the target as a broken zip file. Instead of rebuilding the zip structure by hand, I just decompressed the raw content.
I thought you rebuilt it by editing the signature to a valid PK zip signature, but I suppose that would work too, i've not too much knowledge in doing it the way you claim to have done it, but it obviously works too
#14
Posted 14 December 2011 - 10:03 PM
There are 2 ways of solving it. One is to recreate the zip structure so that regular zip libraries can unzip the content. The other way is to use zlib in raw mode, ie no zip structure or headers needed. Just deflate the raw data (which is what I do in one of my stegotools).I thought you rebuilt it by editing the signature to a valid PK zip signature, but I suppose that would work too, i've not too much knowledge in doing it the way you claim to have done it, but it obviously works too
#15
Posted 15 December 2011 - 05:30 AM
Can you please be a bit elaborate or provide us with some links to learn the structure of deflated ZIP file format?There are 2 ways of solving it. One is to recreate the zip structure so that regular zip libraries can unzip the content. The other way is to use zlib in raw mode, ie no zip structure or headers needed. Just deflate the raw data (which is what I do in one of my stegotools).
#16
Posted 15 December 2011 - 08:40 AM
OK. The ZIP format can be read about here;Can you please be a bit elaborate or provide us with some links to learn the structure of deflated ZIP file format?
http://en.wikipedia....ip_(file_format)
http://www.pkware.co...ies/APPNOTE.TXT
Since compression method can vary, the deflate method is just one of many and comes from zlib. Read the doc above and you will see where in the zip structure this information is found. Since we know compression method is deflate (opposite is inflate for decompression), which it usually is in a zip archive anyway, we move on the zlib site and dig; http://zlib.net/manual.html By careful inspection and extensive searching, we can dig up some tiny comment like this;
windowBits can also be –8..–15 for raw deflate. In this case, -windowBits determines the window size. deflate() will then generate raw deflate data with no zlib header or trailer, and will not compute an adler32 check value.
A little bit of thinking later we conclude that since zlib can compress/decompress data without header (ie information about about data size, checksum etc) by setting windowBits to unusual values, we should in theory be able to do so for certain zip archives too. And honestly it took me a lttle bit of time to make this connection and draw the lines between this information. That means you should also be able to attempt brute force decompression of raw data by moving the filepointer byte for byte. I created some apps for this, which can be found here; http://www.mediafire...gzmxu17gspxuymx (check out the readme) And by running the tool inflate_raw_loop.exe on this challenge you will have the decompressed and fully functional exe in a second. So most of the time it took me to solve the challenge was actually in getting the missing dll's. Note that when working in raw mode without header, there exist no name to give the output, and abviously also no extension. For that reason I added a very simple signature identification to give the output an extension. You get the point now. But this information is not very well documented or otherwise described. Google yourself..
#17
Posted 15 December 2011 - 03:50 PM
A bunch of info indeed. Let me find some time to digest.
#18
Posted 15 December 2011 - 07:46 PM
#19
Posted 15 December 2011 - 11:17 PM
Yep, I do like AutoIt. The SessionChange service present in my signature is based on arcker's UDF & written in AutoIt.If you like AutoIt, then this code may be useful for learning purpose; http://www.autoitscr...f-from-scratch/
#20
Posted 16 December 2011 - 01:08 AM
Does anyone have any link to detailed specification of RAR file format?
#21
Posted 16 December 2011 - 06:40 AM
It was detected so because of the header, but the content was not in the header, so it did not matter at all for the challenge. Have no idea about RAR format though.What interesting is, when I tried to repair the broken file using Winrar, it detected it as RAR file.
Does anyone have any link to detailed specification of RAR file format?
#22
Posted 16 December 2011 - 07:58 AM
HEAD_CRC Always 0x6152 2 bytes HEAD_TYPE Header type: 0x72 1 byte HEAD_FLAGS Always 0x1a21 2 bytes HEAD_SIZE Block size = 0x0007 2 bytes The marker block is actually considered as a fixed byte sequence: 0x52 0x61 0x72 0x21 0x1a 0x07 0x00http://www.win-rar.com/index.php?id=24&kb_article_id=162
#23
Posted 16 December 2011 - 08:22 AM
Got it.The RAR signature is not valid. Not all necessary bytes are there (only the first 4 bytes).
#24
Posted 16 December 2011 - 04:40 PM
But the first two bytes are 0x244EThe RAR signature is not valid. Not all necessary bytes are there (only the first 4 bytes).
HEAD_CRC Always 0x6152
#25
Posted 17 December 2011 - 01:49 AM
But the first two bytes are 0x244E
Just to clarify, I think he was talking about the first 4 bytes for the RAR signature, the RAR signature is an invalid signature. Look around the bytes where you see a "RAR" signature in it's ANSI form.
Edit: I quotted you to help out the other member solving this challenge if that's okay with you joakim
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users