solution to replay handling maybe???

[zaqrack]

Lestunts gave me an idea...



why to work for months and hack the code of stunts, if we have another way???

This is what you need:



1. A server where a remote program runs.

2. Your computer where the other part of the program runs along with stunts.



I.You start the program, and connect to the server via tcp/ip and a login. Easy job.

II.The server logs your entry.

III. The program on your comp. starts stunts (easy too), and monitors your keys pressed. There are programs which monitor keys, and so you can hack passwords, we need such a thing.

IV. You have 5 mins to finish the track, after it the remote server closes your connection.

V. The keypresses are transferred to the remote, and if it gets the escape key`s code, it also closes your connection.

VI. After you finish the track, the program sends a mail along with an attachment of the replay

VII. OK, but there is the cheat, if you attach another replay instead the one you`ve driven. But remember, the replay saves the keystrokes too, which were also transferred to the remote server, so we only have to compare them at some places, and voila you have a replay with eliminated replay handling.



Sound much more easier for me, because you don`t have to mess up stunts code.



What do you think of it?



Zak



 

[zaqrack]

OK, now I can monitor if someone uses replay handling or not.



BUT



I couldn`t find a dos program doing this right, only a windows prog, and I can only encrypt the log of a dos keylogger.

And we must encrypt the log, because you can simply delete your marks if we don`t.  



I`ll look after some help.



Zak

[juank 23]

hi zak, real good news, sorry but i dont understand anything about computers, i know that you are going to find the way to eliminate it, and then explain me more easier, good luck and thanx

[zaqrack]

Hi ppl.



this is what we have:



-stunts  

-a keyboard monitor which monitors all the keys pressed, so it also monitors the escape-down-down-down sequence (shows replay handling)

-a logfile that this program has generated

-an exe what I`ve written with the use of some sources, which automatically encrypts the logfile with a password, and then it can decrypt it also when the password is entered.



this is what we like to do:



1.activate the monitor

2.run stunts

3.exit stunts

4.deactivate monitor

5.encrypt log together with the replay (problem: somehow we must prevent that the user encrypts another replay with the log. The log can`t be modified, if this whole thing is done in a batch. If you have an idea here pls. write.)

6.send log&replay to the competition address



this is the problem:



the keyboard monitor is a windows program, and there is an activate/deactivate button, which I have to press. But this should be done automatically by a batch script, because if it`s done manually, the pipsqueaks can mess with the log file, before it`s encrypted. A single batch file won`t do, because it can`t press a button.



If there is somebody into windows scripting PLEASE help, this is the last step to eliminate replay handling a bit.

I didn`t say this method can`t be played out, but it`s better than the one we have now.  



Zak

[al il professore]

well i think i got a friend that can help us: its thomas harte... I will send ure beautiful thoughts to him and we'll see what he can do for us!



GREAT GREAT GREAT GREAT No more RH in our stunts world



YEAHAAAAAAAAAAH thx zack!!! u are a genius. ^_^

[Anonymous]

good job zak!   I don't understand a word, but it sounds great!  

[THarte]

Hi! I was pointed to this thread by Alain, and a few things occur to me :



- checking for the 'escape down down down' sequence is worthless since anyone with a mouse can avoid it, and using a mouse for the menus may cause it to occur where the user has just pressed escape to pause, then re-entered the game and decelerated in a strange fashion.

- using a key logger still doesn't prevent technical people from cheating



However, I did a quick search, and www.wittys.com/toolfiles.html seems to include a link to www.wittys.com/files/keytrap2.zip, a free key logger for DOS, included files all dated to 94/95. It warns that "Keytrap will NOT work while you are in windows.", but whether this means anything for Windows newer than 3.1 I wouldn't like to assume. Perhaps this will be the answer to your problems?



Otherwise I have written the bare minimum of a program which installs the necessary keyboard logging stuff and then spawns a second program of your chosing, logging all keypresses until that program exits, which I'll complete properly and add some replay validation functions to if the other solution does not work. In general, this might be a better solution since the TSR in that zip file can't be unloaded.



With respect to the idea of :



start logger

run game

quit game

compare log to replay



Might I suggest that the best idea is to check if, anywhere in the logged presses is a set that matches the replay, and if so the replay file is validated? This way you could play as many times as you like, just being sure to save the replay before you quit, and still get correct validation if you have not cheated.

[al il professore]

well pretty concise and efficient... I stay quiet now and i think we can definetly forget to play with replay handling!



Congratulations Thomas! U win! Perfect!



Zacks idea was barely to avoid using Replay Handling in our competitions. That would be fair in my point of view too. Nevertheless Let us believe noone belonging to our community of crazy stunts pipsqueaks will ever cheat consciously, in any way.



I'm ready to use a non RH competition in the 5th of august tricky tracks some fans will send for France championship.



I still need three original tracks BTW, hurry boys!



MANY MANY MANY THX TO U THOMAS! ^_^ 12XU

[al il professore]

i'm right now coming to this point:



keytrap doesn't work properly under stunts. I mean it does work properly, makin a klog file with the keys I type under dos, but when stunts starts, every key logging ability stops and even got a problem getting out of stunts, big bad bug. But, crossing dusks and darknesses, I continue my journey to the light.



well, I considered you eventually got true when u spoke about the second way, a prog that reads the key pressed, then checks the key log, then says goodbye u used rpl handling OR youre in the points, no Replay handling! it's good! Zack can answer that? when he got his php brand new site online I think... Even alanrotoi can solve this problem, if only he could see that. I'm very intuitive in computers, I can work on every wysiwyg @#%$ until it demands bare mathematics... only pure intuition drives me! ^_^



I keep working on it since i need bigger lights from u guys! see u!

[al il professore]

quoting thomas on stunts community:



progress to date on my program :



- a list is made of all the replay files in your stunts directory

- monitors of timing and keypresses are installed

- stunts is run. Eventually you exit . . .

- monitors are removed, having logged all key events including time of event

- a new list is made of all replay files in your stunts directory

- all new files (i.e. those on the new list but not the old) are loaded and checked to see if their input correlates directly to any input that actually occurred during play



Unfortunately the last step doesn't actually work! If it did, and a replay was found to be valid, then what it would do is encode the replay with a particular key based upon the track layout, then people would be able to send this encoded replay to whoever is running the competition, and they can run a seperate decode program taking the encoded replay and the original track as arguments, from which the original replay is restored and replay length is displayed.



Naturally, both of these are DOS programs. But notice that :



- if the user uses mouse or joystick support, the replay will be invalidated

- any use of menus, no matter what you do before a return to play would invalidate input under this system. The answer is presumably to ignore any input after an escape but before an enter - but again this causes issues for people navigating menus by anything other than the keyboard. A different answer might be to provide a seperate pause button in my program and stipulate that the user may only use that



Also, a couple of small technical notes about Stunts for anyone who collects these things - even after its installed its own interrupt handlers, it continues to pass interrupts to the old ones (which is not often seen amongst software that traps interrupt 8, the timer interrupt), and it reprograms the timer to operate at 100 beats per second (the normal rate when running DOS is ~18.2, but most games fiddle with this).



-Thomas



alain speaking now: it enfocuses two new problems: one the use of mouse is prohibited for now, how can we change that... two, asking 'legal' pauses within a rpl may invalid it.



waiting for your enlightened solutions people ^_^

[THarte]

If anyone is technically minded, could they have a scan and see if they can help me out?



My program hooks code to interrupt 8, the timer, and interrupt 9, the keyboard.



When interrupt 8 signals, it increments an internal timer variable. It seems, from measuring empirically, that the timer interrupt is reprogrammed by Stunts to run at 100Hz.



When interrupt 9 signals, it reads the scancode from port 0x60, and if it is not a keydown for a key that is already down (Stunts seems not to disable key repeat, even during play), it is recorded along with the current internal timer variable, to a buffer.



When the program ends, any new or updated replays are loaded, and are disected to find the times at which the input state changed. The program then attempts to find a period within its buffered input that matches to the changes stored in the replay file. Only if it is successful is the replay is validated.



But here is the problem. Quite often the validation fails, and when I manually compare the input in the replay file to the input the program logged, I see that the change in input to the replay is duplicated by a change in logged input, but the timer suggests that the change my program logged was anything up to a half second after the change was logged by Stunts.



E.g. the change will be at the 513th input sample (at 20 samples/sec) stored in the replay file, but my program will have it logged as happening something like 26 or so seconds after game play must have begun for this to be the valid part of the logged input.



I have already avoided the problem of getting confused because users are able to start producing keyboard input before replay recording begins, e.g. by pressing 'up' during the black screen after selecting 'lets drive' but before the game simulation appears.



A solution of selectively disregarding time information would be relatively hard to implement, since very many keyboard events may occur between input samples in a replay file - e.g. if you can move in 1/20th of a second from pushing up and right to pushing down and left, then you have just generated four keyboard events inbetween one replay file sample.



So, anyway, I'm confused. And stuck for now. Some possibilities :



- Stunts is dynamically reprogramming the timer, causing my assumption of a constant rate to fail. I'd dare say this was unlikely

- Stunts is using some other system of reading the keyboard (e.g. polling the bios input queue) than the keyboard interrupt. This is unlikely since then surely my program would get the key events before Stunts, and users would notice strange delays

- Stunts has several routines connected to the keyboard interrupt, and a higher up one is blocking all lower down ones at some point as a quick hack to make some part of the physics work. But that doesn't sound very convincing either.



Help me?