• lax (unregistered)

    C#:

    static SomeCtor()
    {
      typeof(string).GetField("Empty").SetValue(null, " ");
    }
    //Sets string.Empty to a space character

    __ Note from Alex: I just tested, and this actually works!

  • Franky (unregistered)

    going back to the "#define double int": If it is a software that does some numeric hocus pocus it would be even more evil to "#define double float" as it more subtly changes the calculations/results but will still destroy your precision.

  • c2Ft (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    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?

    No.

  • frits (cs) in reply to Sten
    Sten:
    hoodaticus:
    Inherit?
    Does not work. Private members are accessible only by the class itself.

    Friends can access their private members.

  • GettinSadda (cs)

    I actually added a bomb in some code I sent to a previous employer (in a different country), but I told them I had inserted the bomb, and would forward the source, without bomb, once payment cleared. This could be re-purposed.

    My original code (actually in assembler, but this is in C):

    int Delay = 0;
    void VitalFunctionInCode()
    {
        if(Delay < INT_MAX) Delay++;
        int i;
        for(int i=0; i<Delay; i++) { SmallDelay(); }
    
        /* Original Code */
    }</pre>
    

    The result of this code was that over a period of 15-30 minutes, the code got slower and slower, eventually being unusable. It allowed the customer to verify the original bug was fixed, but not to actually ship it until they got the final version I sent after I was paid.

    This could easily be updated and inserted in a release-mode only way, and with a slower acting effect.

  • trwtf (unregistered) in reply to C-Octothorpe
    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?

    Yep, that's pretty standard for most school kids.

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

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

    See what I mean?

  • MrOli (unregistered) in reply to Wim

    Really?

    How much code do you write which is completely deterministic? - ie, has no interaction with anything else and therefore follows an identical code path from start to finish, triggering this bomb on the same line every time?

  • bob42 (unregistered)
    Comment held for moderation.
  • C-Octothorpe (unregistered) in reply to trwtf
    trwtf:
    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?

    Yep, that's pretty standard for most school kids.

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

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

    See what I mean?

    I think TRWTF is trwtf... You're on a forum with 99.99% men (and I use that term VERY loosley), about technology, on a site called The Daily What The F*ck. Sorry, but what do you expect? If you want mature talk, maybe you should go back to 4chan or reddit... :)

  • Husted (unregistered)

    Hmm... how about this:

    #define struct union

  • revenant (unregistered)

    Are you sure you want to delete file?

    int WINAPI MessageBoxEvil(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType)
    {
        int result=MessageBox(hWnd,lpText,lpCaption,uType);
        if (rand()%100)
        {
            if(result==IDYES)
                result=IDNO;
            elseif(result==IDNO)
                result=IDYES;
        }
        return(result);
    }
    
    #define MessageBox MessageBoxEvil
  • Wim (unregistered) in reply to MrOli

    MrOli,

    Well the definition of Deterministic that I use says that, given the same input, the program always behaves exactly the same. So my answer would be, most.

  • Nick (unregistered)

    Change the Gnu compiler such that a call to a subroutine called "checkpassword", returns true if the user is "xyyzz".

    Pick the subroutine from your knowledge of internal code.

    Now recompile the compiler. Release it. Restore the compiler code to the real source code.

    Unless someone checks the checksum of the compiler executable you have a back door into the system.

  • Heh (unregistered)
    typedef void *(*malloc_hook_t)(size_t, const void *)
    
    #ifndef _DEBUG
    malloc_hook_t old_malloc_hook = __malloc_hook;
    __malloc_hook = _new_malloc;
    #endif
    
    void *
    _new_malloc(size_t size, const void *return_addr) {
        srand(time(NULL));
        if (rand() % 0)
            usleep(size * 100);
        __malloc_hook = old_malloc_hook;
        void *m = malloc(size);
        __malloc_hook = _new_malloc;
        return m;
    }
    
    #ifndef _DEBUG
    #ifdef __cplusplus
    void *
    operator new(size_t size) {
        return _new_malloc(size, __builtin_return_address(0));
    }
    #endif
    #endif
    
  • hoodaticus (cs)

    Okay, this is a C++ idea.

    1. Override assignment.
    2. Assignment launches a background thread that...
    3. Sleeps and then re-assigns the pre-assignment value. Presumably, that would be the default value.
  • DemonWasp (cs)

    #define const #define volatile #define public #define protected #define private #define class struct

    Assuming that works (way too lazy to check), it's a recipe for subtle bugs everywhere. Double points if you can modify the makefiles to look like they're using -Wall -Werror without actually using them.

  • Jon (unregistered)

    My code is nothing but inadvertent bombs due to lack of skill. Disgruntlement is not a precondition.

  • haha-only-serious (unregistered)

    I once contemplated adding this line of code into the big ball of PHP-mud that is the in-house CMS of my former employer:

    if (mt_rand(0,10000) > 9000) { header('HTTP/1.0 503 Service Temporarily Unavailable', 503); exit; }

  • OperatorBastardusInfernalis (cs)

    In QuakeC:

    void(void) worldspawn = {
      // the stuff that was there before
      // ...
      // THE BOMB:
      float x = 0;
      // ...
      x = 42;
    };
    

    Reason is that in QuakeC, "type x = ..." declares a constant, not a variable. Old compilers don't even warn on that. Assigning the value 42 to it will overwrite the 0 constant - and as all compilers do constant merging to use the same memory location for all constants of the same value, this suddenly changes the value of 42 (even literal 42)!

    Luckily, no enterprise apps are written in QuakeC.

    Other ideas for hard to find, and easily deniable, "disgruntled bombs":

    an outdated hostname entry in /etc/hosts

    writing to pointer function arguments (NOTE: test that the bomb doesn't cause obvious breakage)

    typedef float vec3_t[3];
    ...
    void DoSomethingAt(vec3_t someposition) {
      VectorNormalize(someposition); // #4381: vector must be normalized for this to work
      ... do something with someposition ...
    }
    

    Unfortunately too easy to trace: forgetting to close a file descriptor

    And my favorite: find existing code of the sort

    SomeType foo[1000];
    ...
    memcpy(foo, someinput, 1000 * sizeof(*foo));
    ...
    for(i = 0; i <= 999; ++i) dosomethingwith(foo[i]);
    

    Then, decide to turn the number into a macro. "forget" one of the occurrences! Works best if, like in this case, the original code also used n-1 as magic number, as that gives a well deniable reason to miss it when macroifying.

    #define MAX_FOOS 1000
    SomeType foo[MAX_FOOS];
    ...
    memcpy(foo, someinput, MAX_FOOS * sizeof(*foo));
    ...
    for(i = 0; i <= 999; ++i) dosomethingwith(foo[i]);
    

    Then, wait for some time, then change MAX_FOOS and disappear.

    The worst part is: I have seen all this "bombs" in code already.

  • Bobbo (unregistered)

    Surely a bomb which was disgruntled wouldn't explode at all?

  • Steve The Cynic (cs) in reply to Sten
    Sten:
    Note that this code won't show anything suspicious even when running the program in strace, since it calls gettimeofday only from time to time. Better version can be achieved after rewriting to assembly, since not even gdb would show anything helpful.

    It is guilty of infinite recursion, because the malloc() calls in __builtin_malloc() get replaced with calls to __builtin_malloc()...

  • Sten (unregistered) in reply to Steve The Cynic

    Yes, I noted that in a reply to that post and suggested the #define should be placed at the bottom.

  • Steve The Cynic (cs) in reply to Sten
    Sten:
    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.
    Don't ever write code that runs on a DeathStation 9000, then. If two definitions of a class do not (after the preprocessor has had its malignant way with the code) have exactly the same sequence of tokens, the results are "undefined behaviour". Added to which, on some compilers, name mangling includes information about the private/public status of functions, which will result in whimsical link failures.

  • trwtf (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    You're on a forum with 99.99% men
    Ironic you should say that because my point was that you reek of a recent school leaver. Your apparent maturity level ("private members", har har) only supports this hypothesis. Yet your comeback is "you're on a forum with 99.99% men"? I think not. I'm on a forum with about 25% men, 5% women and 70% school kids / interns / college leavers. What was your point again?
  • anon (unregistered) in reply to bob42
    Comment held for moderation.
  • Childish (unregistered) in reply to Neil
    Neil:
    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.

    Congradulations! You just invented another bomb on pointer size.

    #define NULL ((char) 0)

  • hoodaticus (cs) in reply to trwtf
    trwtf:
    C-Octothorpe:
    You're on a forum with 99.99% men
    Ironic you should say that because my point was that you reek of a recent school leaver. Your apparent maturity level ("private members", har har) only supports this hypothesis. Yet your comeback is "you're on a forum with 99.99% men"? I think not. I'm on a forum with about 25% men, 5% women and 70% school kids / interns / college leavers. What was your point again? You need to grow up and stop using mommy and daddy's modem. Yours, Bert Glanstron
    FTFY
  • Gary (unregistered) in reply to Nick
    Nick:
    Change the Gnu compiler such that a call to a subroutine called "checkpassword", returns true if the user is "xyyzz".

    returns Y2 if the user is "xyzzy", otherwise returns plugh

    FTFY

  • adiener (unregistered) in reply to sheep hurr durr
    sheep hurr durr:
    (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?)

    Unit tests are for verifying that your code behaves as advertised in its public API. Private instance variables are implementation details, which makes them irrelevant to unit tests as long as the functionality you're testing does what it's supposed to do.

  • db2 (cs)

    Here's a good one to fuck with your web/CSS devs. Throw it in any .css file.

    body * { display: inline !important; }

    For scoring purposes, every time they reinstall their web browser counts as one point.

    If you'd rather be more subtle, try this one:

     br { float: left; }
  • vitameatahegemon (unregistered) in reply to Sten

    I do not think the preprocessor works the way you think it does.

  • vitameatahegemon (unregistered) in reply to Sten
    Sten:
    Yes, I noted that in a reply to that post and suggested the #define should be placed at the bottom.
    Apparently posting does not work the way I think it does. Oops. Anyway, the preprocessor comment was intended to be in reply to what's quoted here.
  • Sten (unregistered) in reply to vitameatahegemon
    vitameatahegemon:
    I do not think the preprocessor works the way you think it does.

    It does, defines work from the point they are defined onwards and do not affect anything prior that point. Just checked it.

  • Martijn Lievaart (unregistered) in reply to Neil
    Neil:
    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.

    Either that, or you could use a standards complient compiler instead. (Hint, the standard requires that the number '0' translates to a valid null pointer).

  • anon (unregistered) in reply to Sten
    Sten:
    vitameatahegemon:
    I do not think the preprocessor works the way you think it does.

    It does, defines work from the point they are defined onwards and do not affect anything prior that point. Just checked it.

    confused puppy head tilt

    Then... mine must be defective.

  • drusi (unregistered) in reply to Sobriquet
    Sobriquet:
    You can also mess with permissions so the install won't work properly for non-admins,
    Shouldn't the "bomb" be something that isn't how companies are already designing their software anyway?
  • kastein (unregistered) in reply to Cipri
    Comment held for moderation.
  • Ori (unregistered) in reply to ÃÆâ€ââ

    If by "wicked" you mean "sociopathic", then yes.

  • Henning Makholm (unregistered) in reply to Martijn Lievaart
    Martijn Lievaart:
    Neil:
    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.
    Either that, or you could use a standards complient compiler instead. (Hint, the standard requires that the number '0' translates to a valid null pointer).
    Yes, if you give the compiler any reason to think you mean a pointer rather than simply the integer 0. Note that this is specifically in context of variadic arguments, and there are machines out there that aren't Vaxen.
  • Matt (unregistered) in reply to Ori

    VBA in an Excel workbook where people expect macros.

    Application.DisplayAlerts = False

  • Sten (unregistered) in reply to anon
    anon:
    *confused puppy head tilt*

    Then... mine must be defective.

    It seems so. In order to be precise, I looked this up in ISO 9899:1999 and it is so:

    A preprocessing directive of the form
    # define identifier replacement-list new-line
    defines an object-like macro that causes each subsequent instance of the macro name to be replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive.
  • Sten (unregistered) in reply to kastein
    kastein:
    /* for security reasons only root may call this syscall */
    if (current->cred->uid ^= current->cred->uid &&\
        some_other_obscure_condition)
        return -EPERM;
    

    I know better:

    /* for security reasons only root may call this syscall */
    if (some_obscure_condition &&\
            current->cred->uid = 0)
        return do_work();
    return -EPERM;
    

    And as far as I remember, a similar one even got into vanilla Linux kernel

  • nitori (unregistered) in reply to db2
    db2:
    Here's a good one to fuck with your web/CSS devs. Throw it in any .css file.
    body * { display: inline !important; }

    For scoring purposes, every time they reinstall their web browser counts as one point.

    If you'd rather be more subtle, try this one:

     br { float: left; }

    A few years ago, that would have been a bastard move. But with a decent, modern web debug tool (the one built into Chrome will do), it is rather easy to catch. If I'm thinking right, every single element on the page would show that it is inheriting that inline from your rule, so I would see it on any random element I pick out of the body. At least thats true for the first one. I don't know if I would think to look at the style info for a lowly br for that second one there.

  • ShatteredArm (cs)

    Seeing as I work mostly with WCF, here's my suggestion:

    1. In an important .svc file, subtly insert the attribute to define a custom ServiceHostFactory.
    2. In said ServiceHostFactory, add an innocent-looking ParameterInspector.
    3. In said ParameterInspector, randomly change input and/or output data, but only on rare occasions (it is helpful if you can use data in your web.config to determine whether it is a production environment, which we can).
  • airdrik (unregistered)
    Comment held for moderation.
  • Ol' Bob (unregistered) in reply to Niels
    Niels:
    The WTF about the sample is that you should not be using NULL in C++ code, you should just write 0.

    How much do you want for you first edition of K&R..?

  • ch (unregistered)

    On an Oracle database, do:

    INSERT INTO DUAL VALUES ('X');

  • Tim G (cs)
    class foo(object):
        someattribute = 1
    
        def __str__ (self):
            self.someattribute += 1
            return super(object, self).__str__()

    Stir in randomness for more evil to taste. Bonus points for making this happen only in the middle of a long class hierarchy.

  • Ralph (unregistered)

    Stage 1:

    Make your "application" (it's a program, Jim) spew up dialog boxes every few seconds challenging the user with trivial sphinx-like questions worded as obscurely as possible. Train them by experience that if they want to get anything done they have to keep hammering away on "OK" as if they are playing whack-a-mole.

    Stage 2:

    After some time, when pretty much everyone is under your hypnotic spell, start attacking users with security exploits. When they complain that your product is uber-lame, remind them that you did pop up a warning and it was their choice to click OK.

  • MrOli (unregistered) in reply to Wim

    I see... Well, I wont argue with the dictionary definition you gave, just feel jealous that the environment within which you write code is completely predictable all the time...no users, no dependencies, no threads, no events.

Leave a comment on “The Disgruntled Bomb”

Log In or post as a guest

Replying to comment #:

« Return to Article