That’s too easy.
…but how to get the usernames?
edit HAS to be a lookup table!? If not - I give in! It is magic!
[quote]Congratz, you are the first to notice without being told (I guess). It’s magic, and it’s watching you.
[/quote]
Well I was like wtf, did I really saw my user name in that image. So I right click and said show picture in a new tab. Then its url showed it as png, and then it really freaked me out 
(Though maybe chrome supports animated pngs now days too)
Then found out it was really a gif.
I guess it gets the username from the forum somehow, but not totally sure how would it.
I find creating tools to get the most compression the most enjoyable aspect of the competition 
but some might call me strange!
[quote]I find creating tools to get the most compression the most enjoyable aspect of the competition Smiley but some might call me strange!
[/quote]
Yep! Thats strange… Mind you, wont complain if you release version 4 :
Wow… So we have a magician at JGO… Very impressive… However after last refresh I am now pjt33 instead of steveyO… Pretty cool nevertheless… When I get 5mins break, gonna figure out how you do this…
Heuristics do fail every once in a while.
Update: should fail less often now.
I guess one way would be to keep looking at the who’s online list when the image is pulled from the server. Enough polls would get it right.
I was just thinking along similar lines.
I might be wrong, and I’m probably looking at the wrong code, but I think I’m using session hijacking and a zeroday security hole.
I had a look for JavaScript but I couldn’t find any, so I assumed you weren’t actually hijacking the session. Hmm.
Packet sniffing doesn’t show an actual session hijack, but the referrer should allow you to see who’s requesting the image.
You think it’s believable that I am guessing at how I did it? ;D I thought it was obvious I was messing with you 
My Guess: The link to Rivens avatar is a servlet or mapped to a servlet (not an image)… The servlet picks up the user id (this is available from the http request in the referer, ‘Live HTTP headers’ plugin for Firefox is your friend here to see whats going on). Riven has a db/lookup table of usernames/ids… And creates the animated gif in the Servlet and returns that. Very clever!
I seriously cannot ‘pick up a user id’, that would be a major security hole in the browser, so I do not have IDs in my database - I only have your IP, the “Referer: --” header probably… and some other headers like the user-agent.
I also do not have an ip/username mapping in my database.
this is my stdout for a request:
requestReceived: /files/logo4.png
addr: xxx.xxx.xxx.xxx
username-score-1: steveyO (1.3125)
username-score-2: zammbi (0.3125)
username-score-3: thijs (0.2500)
username-score-4: princec (0.2500)
username-score-5: pjt33 (0.0625)
username-score-6: Riven (0.0625)
whois took: 2ms
>> reusing gif for: steveyO
Heuristics.
It is strange, i cannot seem to be able to replicate the results of Riven’s fantastic tool.
I have narrowed it down the the proguard or the java source compilation steps as i am able to replicate the pack 200 step exactly and am able to match the kzip step.
It is not a major issue, i am just a little bemused! I will just use Riven’s tool to produce the .pack version of my entry and then I will create my own gz version as I seem to be able to produce a more compressed .gz version.
My old 4kjo tool is now obsolete as proguard is able to optimise better than any combination of any other optimiser (as well as proguard in conjunction with any other optimiser) but I can leaver the recompression aspect of the tool and will write a tool that takes a .pack.gz as input and then recompress it to achieve better compression. (well most of the time any way!)
[quote=“moogie,post:94,topic:34618”]
Which tool do you use for gzip?
It seems the pack200 is sensitive to the JAR it gets.
I’m creating the JAR with ZipFile and ZipEntry. I bet that qualifies as doMagicStuff()
Edit:
Hm, you say that your .pack is equal in size - nevermind then.
I did some more bruteforcing, and saved a handful of bytes.
old A.normal.7z.pack.gz => 3201 bytes A.progrd.7z.pack.gz => 3036 bytes A.normal.kz.pack.gz => 3078 bytes A.progrd.kz.pack.gz => 2934 bytes
newA.normal.7z.pack.gz => 3201 bytes A.progrd.7z.pack.gz => 3030 bytes A.normal.kz.pack.gz => 3076 bytes A.progrd.kz.pack.gz => 2927 bytes
What amazes me is that 7z is not deterministic.
Nor is kzip. It has an option to randomise it, which it says is useful for running it lots of times and picking the smallest output, but even without that option the size of the file it produces can vary by a couple of bytes.
I already make use of it, since the last update actually
multiple actually
I perform a similar brute force approach as Riven using kzip: multiple of 8 block size between 8 and 1024 and then for the “best” block size perform 30 random runs with the best block size. For each kzip run I then use DeflOpt which can sometimes shave an extra byte or two.
I then perform a brute force using BJWFlate given the same input to compress as kzip choosing split sizes as powers of 2 i.e. 4,8,16…8192. Similarly I use DeflOpt for each BJWFlate run.
The smallest resultant zip file out of all the runs is chosen to be passed to pjt33 zip to gzip converter. And thus the final gz is produced.
From previous years experience (and testing this year) some pack files are better compressed using kzip and some are better compressed using BJWflate.