adding slowness and obfuscation

ME dugan at passwall.com
Tue May 7 16:42:44 PDT 2002


If you have the source code to the application in question, add a little
"extra code" that:
Somewhere in the game code (where a new level begins or whatever) add a
 Check for the existance of a regular file in /tmp (not dev, sym, etc)
 if the file exists and is a regualr file (not dev special or dir)
  then open the file for reading and read one char (0-255) and store that
  as an int.
 Use that value of that char (0-255) as a weighted timeout against
  rated speed from /proc/cpu_info (bogomips entry) with some pause or
  delay. This could be many various kinds of things from idle calls,
  through to "waits" or "sleeps".
 Recompile the game, and check the date/timestamp of the orig.
 Move the orig to a backup file elsewhere.
 Copy the new one to the old location
 Use "touch" to make the timestamp for the file the same.

Now, when you want to slow down his game at the start of any level, you
just add a char to that tmp file. "NUL" has no effect (or very
little) while "0xff" would be the slowest.

Remove the file and when the level ends, the effects seem gone.

(Above is not my own "original" idea. It was stolen from a method used to
slow down games on faster procesors before clocks were available to gauge
speeds - games just ran at the fastest speed possible. This just made them
impossible to play on newer CPUs rathed at speeds higher than 16
MHz. Some would read from a file, or lookup table or just ask the user to 
wait a specified time between pressing a key two times to calibrate a
delay loop timing.)

Can also be done with shells, and you can compile a sheel "just for
him" and then as admin "chsh" his shell or just edit your password file
and change his default shell to a new one that does the same thing. The
same source code mods could also be placed into other bins and you could
add an extra dir to the start of his search path to make many commands
with this slow feature.

I seem to recall a set of bofh patches to bash, but never looked into
them. They *may* be filled with mean things to do to users, or they could
be strictly security patches for logging stuff. (I read about it in a
security list, so it is probably security related even though the "BOFH"
sounds like it could be the former.)

Of course, you do realize, if you were to pull this prank on someone like
me, the resulting prank (though not life threatening, or risking personal
injury, or loss of data or any kind of physical vandalism) would be
serious. Say, a kernel based modification based on UID, or something far
worse...) ]:>

<Lecture blah blah blah your ignoring this aren't you?>
Problem with pranks, is some people don't know where to draw the line as
the "game" escalates into something too risky. (Writing viral code is not
only "risky" but can lead you to criminal and civil liability - as one
example for something to strongly avoid.)
</Lecture you done ignoring this yet?>

]:>

-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t at -(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html
     Systems Department Operating Systems Analyst for the SSU Library

On Tue, 7 May 2002 dolo724 at softhome.net wrote:
> One member of our household has a 1.8GHz RedHat 7.2 workstation, makes it 
> easy to administer and solves many problems when I have to interrupt a small 
> child who's playing a game. 
> 
> We're also into pranks... and here's the question: I'd like to slow the 
> machine down for only one user, say from 1.8 GHz to 180MHz or slower. Any 
> Ideas? 
> 
> Indeed, it's not really ethical, but a good prank well executed is its own 
> reward. 
> 
> Thanks
> Mike Rice
> 




More information about the talk mailing list