|
|
|
| Hurry! Enter The Daily WTF's OMGWTF2 Contest by June 28th! - Prizes! Fame! Trophies! Do your worst: http://omg2.thedailywtf.com/ |
| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7 | Next » |
|
C#:
static SomeCtor() __ Note from Alex: I just tested, and this actually works! |
|
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. |
Re: The Disgruntled Bomb
2011-03-14 10:39
•
by
c2Ft
(unregistered)
|
No. |
Friends can access their private members. |
|
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; 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. |
Re: The Disgruntled Bomb
2011-03-14 10:42
•
by
trwtf
(unregistered)
|
Yep, that's pretty standard for most school kids.
See what I mean? |
Re: The Disgruntled Bomb
2011-03-14 10:45
•
by
MrOli
(unregistered)
|
|
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? |
|
although i would never put this in production, this would be something great to leave on a dev sql server as a "Ha ha! i got the last laugh!". The way to use this would be to create a sql server agent job and put the code in the job, and have the job execute something like once a day, week, month, etc.
Essentially what the code does is it randomly selects a non-system database, and generates a random number for the database and a random number to compare two. if both numbers match it sets the database to offline. so, the result of this is that every so often, at a non-specific interval, a random database will go offline. declare @databases table (name varchar(128), Sm int) declare @database table (name varchar(128), Sm int) declare @number int, @name varchar(128), @sql varchar(max) insert into @databases (name, Sm) select name, abs(checksum(newid()))% (select count(*) from sys.databases where database_id>4 and state=0) from sys.databases where database_id>4 and state=0 select @number=abs(checksum(newid()))% (select count(*) from sys.databases) insert into @database (name, Sm) select top 1 name, sm from @databases order by sm if exists (select top 1 name from @database) begin select @name=name from @database where sm=@number set @sql='alter database [' + @name + '] set offline with rollback after 30 seconds' exec(@sql) end |
Re: The Disgruntled Bomb
2011-03-14 10:50
•
by
C-Octothorpe
(unregistered)
|
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... :) |
|
Hmm... how about this:
#define struct union |
|
Are you sure you want to delete file?
int WINAPI MessageBoxEvil(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) |
Re: The Disgruntled Bomb
2011-03-14 10:52
•
by
Wim
(unregistered)
|
|
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. |
|
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. |
|
|
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. |
|
#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. |
|
My code is nothing but inadvertent bombs due to lack of skill.
Disgruntlement is not a precondition. |
|
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; } |
|
In QuakeC:
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)
Unfortunately too easy to trace: forgetting to close a file descriptor And my favorite: find existing code of the sort
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.
Then, wait for some time, then change MAX_FOOS and disappear. The worst part is: I have seen all this "bombs" in code already. |
|
Surely a bomb which was disgruntled wouldn't explode at all?
|
Re: The Disgruntled Bomb
2011-03-14 11:21
•
by
Steve The Cynic
|
It is guilty of infinite recursion, because the malloc() calls in __builtin_malloc() get replaced with calls to __builtin_malloc()... |
Re: The Disgruntled Bomb
2011-03-14 11:24
•
by
Sten
(unregistered)
|
|
Yes, I noted that in a reply to that post and suggested the #define should be placed at the bottom.
|
Re: The Disgruntled Bomb
2011-03-14 11:26
•
by
Steve The Cynic
|
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. |
Re: The Disgruntled Bomb
2011-03-14 11:26
•
by
trwtf
(unregistered)
|
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? |
Re: The Disgruntled Bomb
2011-03-14 11:27
•
by
anon
(unregistered)
|
Yea, that's just brilliant. OK, a DB went offline at exactly 10:15:32 last night, where should I look to see what happened? Maybe the database logs. Oh, a random maintenance plan I've never heard of was scheduled for that exact time. Well, that has to be a coincidence, so I guess I will not look and see very clearly what that plan does, and thus this "bomb" will definitely go off many times for maximum lulz. |
Re: The Disgruntled Bomb
2011-03-14 11:29
•
by
Childish
(unregistered)
|
Congradulations! You just invented another bomb on pointer size. #define NULL ((char) 0) |
FTFY |
Re: The Disgruntled Bomb
2011-03-14 11:31
•
by
Gary
(unregistered)
|
returns Y2 if the user is "xyzzy", otherwise returns plugh FTFY |
Re: The Disgruntled Bomb
2011-03-14 11:32
•
by
adiener
(unregistered)
|
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. |
|
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; }
|
Re: The Disgruntled Bomb
2011-03-14 11:36
•
by
vitameatahegemon
(unregistered)
|
|
I do not think the preprocessor works the way you think it does.
|
Re: The Disgruntled Bomb
2011-03-14 11:38
•
by
vitameatahegemon
(unregistered)
|
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. |
Re: The Disgruntled Bomb
2011-03-14 11:41
•
by
Sten
(unregistered)
|
It does, defines work from the point they are defined onwards and do not affect anything prior that point. Just checked it. |
Re: The Disgruntled Bomb
2011-03-14 11:48
•
by
Martijn Lievaart
(unregistered)
|
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). |
Re: The Disgruntled Bomb
2011-03-14 11:53
•
by
anon
(unregistered)
|
*confused puppy head tilt* Then... mine must be defective. |
Re: The Disgruntled Bomb
2011-03-14 11:53
•
by
drusi
(unregistered)
|
Shouldn't the "bomb" be something that isn't how companies are already designing their software anyway? |
Re: The Disgruntled Bomb
2011-03-14 11:56
•
by
kastein
(unregistered)
|
somehow I think I have seen this somewhere before... Why did you do this? Company well known for not paying up without a fight?
Evil, but not diabolical. sizeof() will give you away, as will the fact that this breaks everything very quickly. Not subtle enough to survive. My favorite evil code so far (done by me, on my own kernel):
insert into rarely called syscall of choice. Season to taste. You now have a backdoor into your own kernel; if someone gets into your system and changes your root pass but you still have a connection open you can make yourself root and kick them back out. Obviously you need to not leave the evidence in your source tree or tell anyone the specific syscall or obscure conditions you chose, I choose different ones for each of my systems and remove the evidence from the kernel source after rebuild. |
Re: The Disgruntled Bomb
2011-03-14 11:56
•
by
Ori
(unregistered)
|
|
If by "wicked" you mean "sociopathic", then yes.
|
Re: The Disgruntled Bomb
2011-03-14 12:00
•
by
Henning Makholm
(unregistered)
|
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. |
Re: The Disgruntled Bomb
2011-03-14 12:00
•
by
Matt
(unregistered)
|
|
VBA in an Excel workbook where people expect macros.
Application.DisplayAlerts = False |
Re: The Disgruntled Bomb
2011-03-14 12:11
•
by
Sten
(unregistered)
|
It seems so. In order to be precise, I looked this up in ISO 9899:1999 and it is so:
|
Re: The Disgruntled Bomb
2011-03-14 12:15
•
by
Sten
(unregistered)
|
I know better:
And as far as I remember, a similar one even got into vanilla Linux kernel |
Re: The Disgruntled Bomb
2011-03-14 12:16
•
by
nitori
(unregistered)
|
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. |
|
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). |
|
In python, try this:
In summary, changes the metaclass for all classes (within the module and wherever module is imported) so that instances of that class are cached based on creation parameters. First and most obvious is that you only think you are getting new instances but in fact you may be getting a previously-instantiated instance (the class's __init__ gets called every time the instance is requested). Second and slightly more subtle is that those instances never get freed so long as the Class is still visible - so if it is a sizable class that gets created frequently.... Alternatively if you only care about the memory leak, just throw them in a list:
or you can make everything into a singleton:
Or you can do more simple maliciousness like deleting or redefining class methods or returning a different class altogether.
|
Re: The Disgruntled Bomb
2011-03-14 12:38
•
by
Ol' Bob
(unregistered)
|
How much do you want for you first edition of K&R..? |
|
On an Oracle database, do:
INSERT INTO DUAL VALUES ('X'); |
class foo(object): Stir in randomness for more evil to taste. Bonus points for making this happen only in the middle of a long class hierarchy. |
|
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. |
Re: The Disgruntled Bomb
2011-03-14 12:44
•
by
MrOli
(unregistered)
|
|
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.
|
| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7 | Next » |