- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
If it was hashed then it would be totally useless for making comparisons to the system clock except for ==. A hash, by definition, is not a monotonic function. Maybe you meant "obfuscated".
me=crusader to teach TDWTF readers WTF a hash function is
Admin
All the articles are anonymized so Alex doesn't get sued.
I'm still waiting for the day when things get posted verbatim. It will never happen, but it would make the site a lot more fun.
Admin
Wait, you played Starcraft in the college computer labs?
Now I'm feeling old too.
Admin
Admin
"Sorry bud, I don't do that any more. Can't offer ya' any help with it, either. Gotta run. Adios!"
Poor Brian, his hard drive crashed a while ago, and without any backups, he lost his key generator. And since it was so old, he couldn't remember how it worked. And so, what was meant as a steady flow of income for years to come suddenly stopped. And every call reminded him of that.
Of course, he didn't remember that debug message neither, that was for debugging anyway.
Could someone please tell him that there is a way back to the sunny side of life?
;)
Admin
My guess is that Brian put his number in there himself along with the "Expected" value for the license key right before he quit. That way he gets a good chuckle whenever he gets a call because he will know that there is yet another person who is going to get free use of the software by figuring out what was described in this WTF too. He gets his alert and there is plausible deniability about what he did. That's my theory.
Admin
Most WTF worthy here is the link from the "ETTE" link.....that M$ has a "Guide to LeetSpeak"
as if they have any idea.
Now all the h4X0r mommies and daddies can be hip to the scene, man. Groovy.
Admin
Trying? TRYING?!?
Thanks for this one, Alex, it really made me laugh. In fact, after seeing the second dialog box with the Expected: value, now I have to clean off my monitor!
Cheers!
Admin
I recall seeing 1337 in the text files accompanying demoscene releases in the BBS days, before ISPs were big. At that point, most keyword searching was done in university library catalogues.
Admin
What's all this 'captcha' stuff about?? Am I supposed to know what it means? I think I've only ever seen it on this site!
Admin
I remember the first program I ever cracked. ZZT.
The level files you weren't allowed to edit, when looked at with a hex editor, contained the word SECRET. I just blanked it out with nulls, and suddenly all the built-in levels became editable.
Admin
Remember older Microsoft cd key systems.. any number worked if the sum was 27. .. funny times.
Admin
I suspect anyone who claims to know the 'real' origins of 1337.
And real gamers use RDFG ;)
Admin
Took a while until the penny dropped...
Of course, Alex was obviously making the point that you don't have to be an 1337 cr4x0r at all to defeat that l4m3, inept "Leet" licensing scheme.
--
"It was deliberate," said the dwarf as he fell from his horse.
Admin
Wow, there's a lot of kind of weird posts in this thread. Let's just cut to the chase and make things absolutely clear: It is impossible to secure the integrity of any program. Not just the "practically impossible" kind of impossible, but the hardcore "mathematically proven to be impossible" kind.
Well, first, I'm a bit doubtful the encoding really was that hard; most likely it was just the data XORed against some key-string, which is the most popular and obvious way when you want to obfuscate something and don't really care too much about security. XOR has the symmetric property you describe. Had they really cared about stopping modification, they could have signed the data files with an assymetric key. (Which is still more breakable than it may seem*). But I disgress.Okay, while I haven't actually seen a formal proof (one probably exists though), it's a fairly intuitive consequence of Turing-completeness. (To put it in less abstract terms, it means I can always create an emulator that runs your program and tricks it or modifies it to do what I want, and the program can never detect it doing so because the emulator can fool or modify that behaviour. Et sic de similibus.)
So don't be too high-and-mighty over how 'crackable' programs are. It's all just a question of practicality, after all. As some people have pointed out, (and I've experienced personally) this program isn't even the most easily-defeatable scheme out there, either. However it's still wonderfully stupid, since the hash is rendered utterly pointless by displaying the expected value.
Now a few responses to 88831 , who says:
The statement above is very wrong. (and makes the poster look bad, since he seems to think he knows what he's talking about).
The first misconception: Having an algorithm where encryption/decryption is performed the same way has little relevance to the security of the encryption method, and is certainly not a "fatal error". This is very simple to demonstrate: XOR the cleartext/cyphertext against a one-time pad to encrypt/decrypt. This is unbreakable. Unless, of course, you have the key. You always have the key. The key is in the software. So is the decryption algorithm. So while they may have made it particularily easy in this case, it's never really very hard either.
*Ah, but what if they don't need to modify the data, and use an asymmetric method? Also very simple to defeat. You can always obtain the cleartext, either by finding the key in the software, or simpler, by using the program itself to do the job and obtaining the cleartext from the program's memory, through ordinary debugging/cracking techniques. Then you can modify the software to skip decryption of the data files and replace them with their cleartext versions.
The second misconception: That the first misconception is the reason why ROT13 is insecure. All Caesar ciphers are insecure for all the well-known reasons monoalphabetic substitution ciphers are insecure, and they have a unicity distance of 1.0, meaning you only need one character of cleartext to break it, as opposed to ~27.6 for English monoalphabetic ciphers in general. That's the worst possible case (brute forced in 25 attempts at worst, should you choose that method) and ROT13 isn't worse off than any other. ("Double ROT13!" jokes aside).
Of course, in this case the intent is only to make sure that the data isn't easily and casually modified. For that intent, their method was probably sufficient. Of course, that's all changed alot in the last decade now that game devs have realized that 'modders' are nothing to be feared, but rather encouraged.
Admin
You'll probably get sued for "violating" the DMCA.
Admin
I'm Noah's wife and the lucky user of "LegalEase" and I couldn't help but comment... this wonderful program is made by one of the main legal publishers - 2 national offices with distribution in every state. Also, sadly, it continues to be sold for $80 a pop. Before getting in contact with Brian we had to talk to 8 different people and then wait 2 days for him to call us back with his shining jem of helpfulness. An independent developer would have known his product and cared about customer support. Brian did neither, but he assured us if we wanted to buy a newer version of the software he could have it at our doorstep in 24 hrs.. I'm pretty sure he was just some bottom-of-totem-pole sales guy charged with making us go away.
Admin
That's funny, my girlfriend had a subscription to 3773 magazine, apparently it has lots of fashion ads in it for some reason. I just love it when a security dialog says basically, "wrong password, the right password is 12345, (but don't tell anyone) click OK to retry."
Admin
Noah! The program will expire in less than two weeks now!
Admin
Hello Guys, Glad to Join! :)