hacker.org

Posted: **Wed Mar 18, 2009 3:41 pm**

Nice challenge!
It is quite easy if you use the right tools.

import os
f = open("img.png","wb")
for path,dir,files in os.walk("manyfiles"):
	for file in files:		
		f.write(chr(len(open(os.path.join(path,file)).read())))
f.close()

Posted: **Wed Mar 18, 2009 6:29 pm**

My solution is similar, only a different tool

Code: Select all

irb(main):066:0> File.open("../r.png",File::WRONLY|File::TRUNC|File::CREAT){|ofile|
irb(main):067:1* Dir.glob("**/*txt").sort.each{|filename| 
irb(main):068:2* ofile.putc File.size(filename)
irb(main):069:2> }}

Posted: **Wed Mar 18, 2009 6:57 pm**

Nice idea to hide two images... (did you all see the second image?)

Solved it by using basic unix tools:

Code: Select all

unzip -l manyfiles.zip | 
  sort -k 4 | 
  perl -n -e "$i++;m/^ +([0-9]+) /;$n=$1;printf """%2.2x""",$n;printf"""\n""" if (($i+1)%32==0)" |
  hex2bin.pl - img.png

Posted: **Thu Mar 19, 2009 12:23 am**

Yes, I've seen the second image.

I wrote a bash script, and used 'xxd -r' to convert the output.

Code: Select all

#!/bin/bash

a=0
k=0
for i in manyfiles/*/*/*/*/* ;
do
        s=`ls -al $i | cut -d" " -f5`

        if [ $k -eq 0 ] ;
        then
                printf "%06x:" $a
        fi

        printf " %02x" $s

        k=$((k+1))
        a=$((a+1))

        if [ $k -eq 16 ] ;
        then
                k=0
                echo ""
        fi
done
echo ""

Posted: **Sun Mar 22, 2009 3:36 pm**

Another funny challenge. This guy knows how to hide things

I stepped in every trap e.g. decoded the (hidden) image from the filenames to find out it was the wrong one.
Nearly no scripting involved. I used UNIX command line tools like find, wc, sort, sed, awk and a bit perl.

Posted: **Tue Mar 24, 2009 7:08 pm**

hah!
finally solved it, after efe said to me that my idea with the length of the strings is correct.
Coding was only a bit C#:
find all files
open files
do something with the content

I was so proud after finding the first image pretty fast...til i took a look at the image-.-

Posted: **Mon Mar 30, 2009 11:04 am**

I used Java and worked directly on the file ...

Code: Select all

	static HashMap<String,Integer> _len = new HashMap<String,Integer>();
	public static void main(String args[]){
		try{
			 ZipFile zipfile = new ZipFile(new File("c:\\hacker\\manyfiles.zip"));
			 Enumeration ez = zipfile.entries();
			 List<String> paths = new ArrayList<String>();
			 while(ez.hasMoreElements()){
				 ZipEntry ze = (ZipEntry) ez.nextElement();
				 paths.add(ze.getName());
				 java.io.InputStream is = zipfile.getInputStream(ze);
				 byte[] buf = new byte[is.available()];
				 is.read(buf);
				 is.close();
				 _len.put(ze.getName(), buf.length);
			 }
			 Collections.sort(paths);
			 FileOutputStream fo = new FileOutputStream("c:\\hacker\\test.png");
			 for(int i=0;i<paths.size();i++)
				 fo.write((byte)(int)_len.get(paths.get(i)));			 
			 fo.close();
		}catch(Exception ex){}
	}

I found the first image too ... this code is just for the 2nd.

Posted: **Mon Mar 30, 2009 5:16 pm**

All of you found two images?!
Are you talking about two in summary?

Haven´t you found the third one?

1st PNG in Filenames
2nd PNG in Filelength
3rd: After Position 0x00229622 (around the middle of the file) there is an invalid zip-envelope/header, so normal zip-decompression ignores this part. Inside you will find the identical PNG to the 1st PNG with the hint "You are on the right track"

Posted: **Mon Mar 30, 2009 8:10 pm**

Broker wrote:3rd: After Position 0x00229622 (around the middle of the file) there is an invalid zip-envelope/header, so normal zip-decompression ignores this part. Inside you will find the identical PNG to the 1st PNG with the hint "You are on the right track"

No, there are only two PNGs. The "central directory" of the zip file starts at this position, of course you can decode both images from it.

Posted: **Tue Mar 31, 2009 9:07 am**

Ahh i see. Thanks for the Info.

Posted: **Tue Apr 07, 2009 10:50 pm**

megabreit: By the time you've used "a bit" of Perl, you might as well have done the whole thing in Perl.

efe: did you know about os.stat(filename).st_size?

Posted: **Wed Apr 08, 2009 3:27 pm**

gfoot: using the stat system call would be of course more efficient ...

...and the code gets even smaller:

Code: Select all

import os
f = open("img.png","wb")
for path,dir,files in os.walk("manyfiles"):
   for file in files:      
      f.write(chr(os.stat(os.path.join(path, file)).st_size))
f.close()

Posted: **Wed Apr 08, 2009 10:09 pm**

I've created a text file via

Code: Select all

dir /s > manyfiles.txt

Then i wrote this small program:

Code: Select all

f_out = open('c:\manyfilesout-2.png', 'w')
for i in lines:
    if i[17:26] == "Datei(en)":
        ## print int(i[38:41])
        f_out.write (chr(int(i[38:41])))
f_out.close()

What i don't understand is, that whenever 0x0A should be written to the out-file, the program writes 0x0A 0x0D instead.
If i print the results to the screen (using print int(i[38:41]) instead of f_out.write (chr(int(i[38:41]))) ), it shows the results correctly.

So in the end i had to use a Hex-editor and search all 0A0Ds and replace them with 0As.

I have to admit, that i'm not a great programmer ( i started programming in Python when i joined hacker.org in november), so possibly this question is a little stupid, but i have no explanation for this behaviour. Can anybody give me a tip?

Cheers ...

Posted: **Wed Apr 08, 2009 11:57 pm**

Different systems have different conventions about line endings in text files. On Windows in particular, when you write 0x0A it will automatically also write a 0x0D because that's the convention there, for some odd reason. On Unix it won't do that. On Macs I think it will just write 0x0D, without the 0x0A you actually asked for.

In any case, to be portable you should open the file in binary mode, by adding a "b" to the open flags (e.g. "wb"), which disables this behaviour.

Posted: **Thu Apr 09, 2009 5:59 am**

Cool, this really works! Thank you!

hacker.org

rangearmentRe

rangearmentRe