As long as the birth didn't take any longer than 9 minutes..
5 publicly visible posts • joined 8 Apr 2008
I do this frequently for my office door, the code for which I can never remember. The best thing about most common mechanical door / pin entry systems you see is that they don't even care what order the numbers are entered.
I do not doubt for a moment that they could be that stupid. The one I got from NatWest works in exactly this way.
Out of interest.. Does anybody know why the game logic could not just be implemented on a cheap microcontroller (PIC or something) and graphics instructions sent back to the users PC. Game logic generally accounts for very few ticks and microcontrollers are running in the 100s of MHz these days. I'm sure we'll see games on flash drives before long afterall.
I'm not actually pro-DRM or anything, just interested.
Which OS does it infect :)
Because 600,000 Linux users wouldn't have already disassembled, reassembled, opened up the source, ported, and grudgingly released a Windows binary under GPL by now.
And yes, malformed images will still display in most cases.
copy myPicture.gif /b + mySound.mp3 /b myMonster.gif
Clive and Francis at the back can use:
cat myPicture.gif mySound.ogg > myMonster.gif
This will generate a file that can be loaded in most image editors, web browsers and music players.
The specification for most new formats will often include a lot of optional parts that not all encoders / decoders will bother with. Most file formats have some standard for marking the start of these parts / control blocks / frames / or whatever lingo is in use by their expert groups (groupies?). In JPEG for example I think a string of 12 binary 1's indicates that what follows is an instruction or data table.
The decoder scans the files for these markers and uses the data that follows to build the image. If some data in the file doesn't have a marker that it understands then most decoders will just assume that it's some feature of the specification they (the decoder) don't implement.
A silly decoder may assume that because a marker indicates that "what follows is n bytes of xyz information", to keep reading from the file into memory until the next marker will result in n bytes of xyz being read into the memory location (size n), that it allocated. This is probably the most simple example of a buffer overrun.
Most of the new exploits rely on the fact that so much of this optional stuff is never used because it is too hard to implement, useless, or patented (arithmetic coding and hierarchical storage in JPEG, for example, are never used on the web).
A good place to start looking for new exploits is in an implementation of some feature that most encoders will not use. If you find a decoder that implements it (eg. QuickTime implemented some part of MPEG4 that no-one else bothered with. I believe their patch actually just unimplemented it ;) then you already know that the code to do this will not have been as well used and tested. Chances are if you look long and hard enough you're going to find an exploit.