The Daily WTF: Curious Perversions in Information Technology

ObiWayneKenobi · 2012-09-04 Reply Admin

Gandor:
I guess that the prefix came in after the function was written. With no (or insufficient) unit tests, it is easy to overlook the difference.
Than again - why "ciphering" it with using Hex? Not to mention the obvious WTF of wrong detection...

Didn't you get the memo? Unit tests are worthless wastes of time, as long as the app LOOKS functional, it's good enough. Who cares if it crashes sometimes or if it's dogshit slow?

Erzengel · 2012-09-04 Reply Admin

Zemm:
QJo:
I want to look at the file "DEADBABE" but it keeps telling me it's encrypted ...

I'm not into that stuff. I prefer plain B00B1E5.

I tried C0DEBABE, but it gave me a FILE_NOT_FOUND.

The Bytemaster · 2012-09-04 Reply Admin

Remy Porter:
Which is why I specifically said it was encrypted and represented as a hexadecimal number. To put it another way, it was encrypted and then base-16 encoded (as opposed to base-64). It was not converted into a hexadecimal as if that were encryption.
Although, if it were, that would definitely be a WTF. I've seen people use Base-64 as if it were an encryption algorithm.

That's nothing. I once had someone tell me it was safe because it was sent in Unicode, so it was encoded. See, you open it up in Notepad and it has all those spaces between the letters. Nobody is going to pick this up.

I think he may have just been tyring to CYA, but still... it was medical information.

herby · 2012-09-04 Reply Admin

Cbuttius:
184594917

Very HIGH class. Could almost be "encrypted"!

+1 (at the very minimum)!

2012-09-04 Reply Admin

The Bytemaster:
I once had someone tell me it was safe because it was sent in Unicode, so it was encoded. See, you open it up in Notepad and it has all those spaces between the letters. Nobody is going to pick this up.

Sure, it says right so in the name: Unicode. See, it's a code. Code and encryption is the same. And encryption makes everything safe or secure or whatever you call it. All you ivory tower nitpickers, get on to real business problems!

2012-09-04 Reply Admin

Andrew:
Hexadecimal numbers != encryption

They may as well be to some developers. I was implementing a communications protocol to an embedded system. I was doing the embedded side, a contract house was doing the PC side (in C#, if I recall). Debugging over the phone I told the PC guy that "the next byte should be hex 0A", saying it as "hex zero ay". There was a pause on the phone and the PC guy asked, "Is that upper or lower case A?"

2012-09-04 Reply Admin

(relevant) http://securityreactions.tumblr.com/post/30097432723/we-use-base64-encryption

akismet, i'm not a spam

2012-09-04 Reply Admin

justsomedudette:
B00B1E5h:
0B00B1E5 doesn't work on most systems because leading zero means octal. Try 0xB00B1E5, but that doesn't sound nearly as fun.
0xB00B1E5 also known as udders

An ox is a gelded male bovine.

2012-09-04 Reply Admin

Yonder be Nagesh:
Some Nagesh:
I shall try to recreate the mental process that may lead to such code WTF:
"Oh, I see, some IDs have to be decoded right? Well I'll start with a function that decodes them!"
int decode(sting id){
  if (not id.startswith('0x'))
      throw exception #extra check
  strip_first_two_digits(id)
  return decode_hex(id)
}
"Well that was easy! Now to write the main code. Hmm how can I tell if I should pass the ID to the function or not... it's important not to repeat any code. DRY, always follow that... doing the same thing twice is clearly not efficient. And the other function already processes the 0x, so I'll check if it's an hex directly, by seeing if it has letters! Brilliant! Now what is the best way to implement that..."
I've always hated sting data types...so painful to deal with!

That's why he's the King of Pain.

2012-09-04 Reply Admin

foo:
I've seen (well, not literally) emperors use ROT3 as if it were an encryption algorithm.

Well, be fair now, he wasn't emperor yet when he did that.

-Harrow.

2012-09-04 Reply Admin

The real WTF is "encrypting" an articles ID at all. Why?

Zemm · 2012-09-04 Reply Admin

urza9814:
ROT is an encryption algorithm because it works like an encryption algorithm; you give it a plaintext and a key (3 or 13 in our archtypical examples), and out comes a cyphertext.
BASE64 is not an encryption algorithm because it does not work like an encryption algorithm. You can give it plaintext, and you can call the output 'cyphertext', but there is no key.

So...then ROT is encryption, ROT13 is not? It's encryption until you select a key?

Or...BASE64 is encryption -- the key being 64.

No, BASE64 is encoding BASE256 characters into 64 characters - usually used where certain characters have special meaning or will be corrupted in transit. Characters such as 0x00-0x20 and 0x7f-0xff. The 64 in BASE64 is like the 10 in Base10/decimal numbers.

ROT is an encryption algorithm (albeit pretty much the simplest one you can get) but to make it an "encoding" algorithm it requires the key.

ROT13 is good as a trivial encryption. I remember using it when chatting on usenet about tv shows and movies: you'd put spoilers in it so that the reader wouldn't be automatically be able to read it. These day forums tend to have a code that will put the text in a span with JS to reveal.

2012-09-04 Reply Admin

ROT13 (and ROT other numbers) are encryptions, just like American Standard Code for Information Interchange is actually an American Standard Encryption for Information Interchange with a falsified word Code instead of Encryption in its name.

Such encryptions aren't cryptographically secure, just cryptographically encrypted, using numbers to represent characters.

Just as ROT13 of a character such as 3 or & is indistinguishable from ROT0 of 3 or &, ROT13 of 99% of characters in use in the world is indistinguishable from ROT0. For example there's some key in the Windows registry where Microsoft ROT13'd all of the Italian alphabetics [A-Za-z], but the more numerous Chinese and Japanese alphabetics are ROT0'd. I don't know what secret they thought they were keeping.

Cryptographically secure encryptions depend on completely different mathematical techniques. Codes depend on non-mathematical linguistic techniques.

2012-09-05 Reply Admin

ObiWayneKenobi:
Gandor:
I guess that the prefix came in after the function was written. With no (or insufficient) unit tests, it is easy to overlook the difference.
Than again - why "ciphering" it with using Hex? Not to mention the obvious WTF of wrong detection...

Didn't you get the memo? Unit tests are worthless wastes of time, as long as the app LOOKS functional, it's good enough. Who cares if it crashes sometimes or if it's dogshit slow?

Traditional unit tests won't catch your "dogshit slow" bug. For that you want UI tests in a framework like Selenium, which is almost guaranteed to go wrong if app response is slower, or faster, than expected...

2012-09-08 Reply Admin

I like the "catch { }" part - exception swallowing is a sure tell sign that the author just didn't get it.

Sanhadrin · 2012-09-10 Reply Admin

Chelloveck:
Andrew:
Hexadecimal numbers != encryption
Debugging over the phone I told the PC guy that "the next byte should be hex 0A", saying it as "hex zero ay". There was a pause on the phone and the PC guy asked, "Is that upper or lower case A?"

"Depends. Is the zero being printed in upper, or lower-case?"

Hexed Id

Leave a comment on “Hexed Id”