Comment On The Disgruntled Bomb

frist = false;

Donald:

frist = false;

Or better yet

frist = !true; //since only true was modified to be false

That's a nice BYOC, and on time too! OK, I'm in, give me a few minutes with this...

Nice contest. Lots of possibilities. How about this:

Perform some kind of date/time calculation that will result in a number used as index in an array. The array is normally not used for anything important, so will not affect functionality.

Some time in the future (or at some random date) the index turns invalid (negative or overflow). Depending on language etc. you will then provoke an error state.

(forgive me for not producing a code example - hopefully above should be enough)

I always thought Bomb #20 was a pretty disgruntled bomb.

There's an easy one in old versions of Lisp.

(set 5 3)

#define 6 8

This is more subtle than swapping true and false as the problems shouldn't be immediately obvious.

The use of rand() does not give non-deterministive behavior. The example will always crash at the same point in the program (assuming the rest is deterministic)

My idea would be (for C):

#include <stdlib.h>

#define malloc malloc_bomb



static inline void *

malloc_bomb(size_t size)

{

    if (size>8) size-=8;

    return malloc(size);

}

Nameless:

#define 6 8

This is more subtle than swapping true and false as the problems shouldn't be immediately obvious.

Actually, they will be immediately obvious when you try to compile the program, since 6 isn't a legal identifier.

On the other hand:
#define double int
has real potential...

Someone set up us the codez.

Wim:

The use of rand() does not give non-deterministive behavior. The example will always crash at the same point in the program (assuming the rest is deterministic)

My idea would be (for C):

#include <stdlib.h>

#define malloc malloc_bomb



static inline void *

malloc_bomb(size_t size)

{

    if (size>8) size-=8;

    return malloc(size);

}

Dear lord man... that is pure evil.

Wim:

The use of rand() does not give non-deterministive behavior. The example will always crash at the same point in the program (assuming the rest is deterministic)

My idea would be (for C):

#include <stdlib.h>

#define malloc malloc_bomb



static inline void *

malloc_bomb(size_t size)

{

    if (size>8) size-=8;

    return malloc(size);

}

Affected code crashes with a stack overflow, as malloc_bomb calls itself...

JavaScript is pretty easy, but...
(I've added obfuscation to make it harder to track down)


function true1() {
this[("unde"+(!!0)).substring(0, 5)+"ined"] = true;
}

function true2() {
this[("unde"+(!!0)).substring(0, 5)+"ined"] = void 0;
}


(function setupB() {
var setTimeoutOld = setTimeout;
setTimeout = function(func, a) {
setTimeoutOld(func, a);
setTimeoutOld(!!1+"1();", 60000*30);
setTimeoutOld(!!1+"2();", 60000*32);
setTimeout = setTimeoutOld;
};
})();

public static class WindowMessages

{

   [DllImport("user32.dll")] private static extern Int32 SendMessage(IntPtr HWnd, Int32 wMsg, bool wParam, Int32 lParam);

   public static Int32 SendMessage(IntPtr HWnd, Int32 wMsg, bool wParam, Int32 lParam)

   {

      return SendMessage(HWnd, wMsg - 1, wParam, lParam);

   }

}

Addendum (2011-03-14 09:48):
Whoops! Meant to change the name of the public version to SendMsg.

Addendum (2011-03-14 09:51):
.NET is really hard to screw with like this. And C/C++ is too easy.

ochrist:

Nice contest. Lots of possibilities. How about this:

Perform some kind of date/time calculation that will result in a number used as index in an array. The array is normally not used for anything important, so will not affect functionality.

Some time in the future (or at some random date) the index turns invalid (negative or overflow). Depending on language etc. you will then provoke an error state.

(forgive me for not producing a code example - hopefully above should be enough)

Interesting you should mention this - a disgruntled employee where I work did something very similar.

He had been responsible for a critical component of our financial reporting infrastructure, which started inexplicably failing very occasionally a few months after he left. I was asked to investigate, and immediately realised the only option was to re-write the component from scratch in C# (because he'd written it in a language we don't normally support and the latest version of the source code had been "lost" in a "hard drive crash" before he left).

After I'd done that, I decided to do some detective work. It took me an entire weekend using a debugger and a disassembler to work out what he'd been up to, but in the end I worked out that there was a 5% chance that it would subtly screw up its own configuration (read from the db but held in an array) every time it was run.

Another one for C++:

void operator delete(void *ptr) throw() { (void)ptr; }

void operator delete[](void *ptr) throw() { (void)ptr; }

Where did all your memory go?

Niels:

The WTF about the sample is that you should not be using NULL in C++ code, you should just write 0.


How about:

#ifndef _DEBUG

#define if(x) if(rand()<0.0001 && (x))

#endif

This one's definitely my favourite so far (assuming it would work), because checking they're not debugging is evil, and changing one in every 10,000 ifs is inspired.

#define private public

Niels:

The WTF about the sample is that you should not be using NULL in C++ code, you should just write 0.


How about:

#ifndef _DEBUG

#define if(x) if(rand()<0.0001 && (x))

#endif

Doesn't rand() return an int between 0 and RAND_MAX so isn't that just if(rand() == 0 && (x))? (Since the only way the integer rand() can be less than 0.0001 is if it's 0?)

public class Class1

{

    public static bool operator ==(Class1 a, Class1 b)

    {

        return !(a != b);

    }



    public static bool operator !=(Class1 a, Class1 b)

    {

        return !(a == b);

    }

}

Turning all privates public doesn't actually do much. It just prevents compiler errors... and as languages like Python and Pike have proved, it's perfectly possible to eliminate the entire concept of private members. Also, the #define won't change the compiler default; if you declare a class, members are private until you put a label. By convention at my workplace, all classes have private data, then private member functions, then the "public:" label, then constructors, then interface. Your #define would sadly have no effect :(

Good point Steve,

Easily solved by swapping the two definitions.

Wim

Niels:

The WTF about the sample is that you should not be using NULL in C++ code, you should just write 0.

Note that you can only use 0 as a varadic null pointer argument in 32-bit code. 0LL works in 64-bit code, but not in 32-bit code. 0L works everywhere except Win64.

I will let out a wicked secret. In college, I used to have some favorite terminals, for no wicked reason. Many times those terminals used to be occupied. So I used to run a wicked program after logging onto them from a remote machine to harass the person occupying it.

one of my program did a malloc in an infinite loop. and then i ran this program in another infinite loop ... needless to say it pretty much rendered the machine unusable ... and after the person left that machine to occupy another one, i would quietly kill that program and grab my favorite terminal.

oh yes i also said hi to that victim with a sly smile.

(set 5 3)

Even easier:

#define NULL 1

Other libraries will still assume NULL should be 0, so there will be all kinds of bizarre bugs.

But seriously, you want plausible deniability. And you want all these problems to come up *after* the system is deployed. And you want real heisenbugs.

A segfault or a hang is too easy to find. Even if you bury it in a header, someone is eventually going to start scanning through the preprocessed code and find it.

What's really painful is mysterious network failures. Keep in mind that most development will take place on a high speed ethernet network, but on a home network you have high latency, fragmented packets.

There are a ton of parameters you can screw with that won't cause any obvious failures. You could set the timeout to be really short, so the product will mysteriously fail on many

Another possibility would be to redefine PF_INET6 = PF_INET, to make the eventual upgrade even more fun.

The hardest stuff to debug is anything related to crypto. Sift through the headers for OpenSSL... you could set AES to equal Blowfish. Now the app will work fine internally, but if it's sharing data with any other app, it will fail mysteriously.

Installers are a great place to wreak havoc. In particular, if there are any local settings being changed, make them global so you're sure to stomp all over things. You can also mess with permissions so the install won't work properly for non-admins, e.g. change the permissions for a DLL so a user can't read it. Result: mysterious link failures.

#define strncpy(s, d, n) strcpy(s, d)
So much for preventing buffer overflow. Or perhaps some variants:
#define strncpy(s, d, n) strncpy(s, d, (n)+8)
#define memcpy strncpy
For best results, place these in different files, so that behaviour is different in different parts of the program.

For PHP, you could probably do a fair bit of damage by simply sneaking a set_time_limit(0) into a script that can be coaxed into an infinite loop by some innocuous-looking request from outside.

Niraj:

I will let out a wicked secret. In college, I used to have some favorite terminals, for no wicked reason. Many times those terminals used to be occupied. So I used to run a wicked program after logging onto them from a remote machine to harass the person occupying it.

one of my program did a malloc in an infinite loop. and then i ran this program in another infinite loop ... needless to say it pretty much rendered the machine unusable ... and after the person left that machine to occupy another one, i would quietly kill that program and grab my favorite terminal.

oh yes i also said hi to that victim with a sly smile.

that's wicked

Rosuav:

Turning all privates public doesn't actually do much. It just prevents compiler errors...

First, that's an incredibly evil thing in itself: people will use private members and then others will assume they can change the private members leading to all kinds of problems. And they'll be ripping their hair out: Why did the damned compiler let this guy access a private member?!

It will also make the library mysteriously fail to interoperate with other versions that were compiled without the redefinition. In a big app, this would be a nightmare.

#ifndef _DEBUG

#define if(x) if((rand()==1 && SleepEx(10,FALSE)) || (x))

#endif

Isn't there an "evil code" contest for this sort of thing?

Okay, I'd like to see another pointer cast WTF.

haskell (ghci here) let's you happily override the == operator:

Prelude> 1 == 2
False
Prelude> let a == b = True
Prelude> 1 == 2
True

Sobriquet:

It will also make the library mysteriously fail to interoperate with other versions that were compiled without the redefinition. In a big app, this would be a nightmare.

That’s not true.

#define private public

does not change ABI in any way since the classes do not change memory layout. I use it from time to time since some library developers are morons that define everything private and have never experienced any problem with that.

Steve The Cynic:

Wim:

The use of rand() does not give non-deterministive behavior. The example will always crash at the same point in the program (assuming the rest is deterministic)

My idea would be (for C):

#include <stdlib.h>

#define malloc malloc_bomb



static inline void *

malloc_bomb(size_t size)

{

    if (size>8) size-=8;

    return malloc(size);

}

.
Affected code crashes with a stack overflow, as malloc_bomb calls itself...

Along the same lines of the OP, without the stack overflow:

#include <cstdlib>

using namespace std;

void* operator new[] (std::size_t size)

{	

	if(size>1)

	{

		size-=1;

	}

	return malloc(size);

}

Just stick it in some widely used header file.

Yes, but it will be nearly impossible to introduce this misbehavior to other code, because the importing module has to hide the original (==), otherwise the compiler will complain about it. Of course, you can hide override it locally (as the ghci version above does) but what fun would that be?

hoodaticus:

public class Class1

{

    public static bool operator ==(Class1 a, Class1 b)

    {

        return !(a != b);

    }



    public static bool operator !=(Class1 a, Class1 b)

    {

        return !(a == b);

    }

}

This needs to exist in a base class of some sorts (BusinessObjectBase).

Or do something very evil what some of the developers I know do accidentally... They create their own Convert class (Util.Convert vs. System.Convert), which swallows all exceptions, and returns non-default values, etc. This creates wierd bugs because you would WANT and exception to be thrown if the data is bad, not return a f*cking empty string...

I made a bug in my “bad code” post. The #define needs to go to bottom otherwise the program will crash in an infinite loop.

void LeaveCriticalSectionEvil(LPCRITICAL_SECTION lpCriticalSection)

{

    if (rand()%100)

        LeaveCriticalSection(lpCriticalSection);

}



#define LeaveCriticalSection(x) LeaveCriticalSectionEvil(x)

Rosuav:

Turning all privates public doesn't actually do much. It just prevents compiler errors... and as languages like Python and Pike have proved, it's perfectly possible to eliminate the entire concept of private members. Also, the #define won't change the compiler default; if you declare a class, members are private until you put a label. By convention at my workplace, all classes have private data, then private member functions, then the "public:" label, then constructors, then interface. Your #define would sadly have no effect :(

#define class struct

(Although, I'm curious; how do you unit test your private member functions if there's no way to get at them from outside the class?)

sheep hurr durr:

Rosuav:

Turning all privates public doesn't actually do much. It just prevents compiler errors... and as languages like Python and Pike have proved, it's perfectly possible to eliminate the entire concept of private members. Also, the #define won't change the compiler default; if you declare a class, members are private until you put a label. By convention at my workplace, all classes have private data, then private member functions, then the "public:" label, then constructors, then interface. Your #define would sadly have no effect :(

#define class struct

(Although, I'm curious; how do you unit test your private member functions if there's no way to get at them from outside the class?)

You could do internal tests within the class.

sheep hurr durr:

Rosuav:

Turning all privates public doesn't actually do much. It just prevents compiler errors... and as languages like Python and Pike have proved, it's perfectly possible to eliminate the entire concept of private members. Also, the #define won't change the compiler default; if you declare a class, members are private until you put a label. By convention at my workplace, all classes have private data, then private member functions, then the "public:" label, then constructors, then interface. Your #define would sadly have no effect :(

#define class struct

(Although, I'm curious; how do you unit test your private member functions if there's no way to get at them from outside the class?)

I've been doing this software development thing for years now, and I still giggle a little when I read "private members"... Is that just me?

hoodaticus:

Inherit?

Does not work. Private members are accessible only by the class itself.

C-Octothorpe:

sheep hurr durr:

Rosuav:

Turning all privates public doesn't actually do much. It just prevents compiler errors... and as languages like Python and Pike have proved, it's perfectly possible to eliminate the entire concept of private members. Also, the #define won't change the compiler default; if you declare a class, members are private until you put a label. By convention at my workplace, all classes have private data, then private member functions, then the "public:" label, then constructors, then interface. Your #define would sadly have no effect :(

#define class struct

(Although, I'm curious; how do you unit test your private member functions if there's no way to get at them from outside the class?)

I've been doing this software development thing for years now, and I still giggle a little when I read "private members"... Is that just me?

Me too. Looks like I have another twin on here.

"You said private... huh huh huh huh".

Rosuav:

Turning all privates public doesn't actually do much. It just prevents compiler errors... and as languages like Python and Pike have proved, it's perfectly possible to eliminate the entire concept of private members. Also, the #define won't change the compiler default; if you declare a class, members are private until you put a label. By convention at my workplace, all classes have private data, then private member functions, then the "public:" label, then constructors, then interface. Your #define would sadly have no effect :(

So add this:

#define struct class

Sten:

hoodaticus:

Inherit?

Does not work. Private members are accessible only by the class itself.

Edited to correct it. I usually do everything "protected" anyway.