I've asked Nicola about the derivative works issue. I explained about the inp encryption, and the problem with recording and playback in the same session.

I'll let everyone know what the response is, if any.

Thanks to everyone for the encouragement.

Mark

-- Mark Longridge (cubeman@iname.com), November 02, 1999

Answers

Well Nicola responded to my message:

Mark Longridge wrote: > The problem is if I release the source code for this version of MAME, as > per your instructions, cheating will again become trivially simple, and if > we award prizes (e.g. cash, certificates) then it is possible that the > winner is in fact a cheat.

Cheaters will cheat anyway, the only thing you can do is try to make it harder - and getting a false sense of security.

The license requires that source code is distributed alongside derivative works. I'm sorry, but no exceptions can be made.

Nicola Salmoria MC6489@mclink.it

-- Mark Longridge (cubeman@iname.com), November 03, 1999.

The MAME dev coordinator has spoken.

So it's back to the drawing board. I wonder if all the other variations of MAME post the source code?

Well, it's back to the idea of open source with some form of key. I really don't understand the necessity of posting the source as all I did was remove a giant cheating oportunity, and I removed the pause function. The only information I'm holding back is the inp file encryption. The decryption information could be placed in an external file, but what about the ENcryption information? Then all someone would do is undo the encryption...

I'm interested to hear everyone's ideas.

Thanks..

Mark

-- Mark Longridge (cubeman@iname.com), November 03, 1999.

Mark, I write for one of the emu sites, hold off releasing that code just yet. I'm going to get on the horn about this issue, to see if it does any good.

-- Chris Parsley (cparsley1@hotmail.com), November 03, 1999.

Everyone check out the latest editorial at wwemu, it refers to the problems of Mark Longridge. http://www.snes9x.com/wwemu Then check on the Editor's page...

Also, I know there is a few of you out there, that know how to spread the word all the way around. Go to it, and get this out to everyone.

-- Chris Parsley (cparsley1@hotmail.com), November 03, 1999.

There is an easy but difficult solution to this problem. If you encrypt the inp file (and timestamps) with a timesensitive generated key that is received outside of the source, the source need only contain the encryption algorithm and not the key, so the source could be distributed perfectly along with a link to a website that returns timesensitive keys. (the algorithm that creates the keys does not need to be distributed (NOR implimented by any marper) but the code that recieves the key can be distributed.)

This is difficult because the program must connect to a website before and possibly after a mame game inp file is recorded. Which means if you're not online you might not get a authenticated timestamp for your awesome recording. Mark if you're interested and i'll email you how this can be implimented and how to close certain security holes.

-- Chad (churritz@cts.com), November 03, 1999.

Mark: Do you still want me to see if I can hack version 2 of MAME35TG as well?

Chad/Mark: I am going to keep this more general than necessary, because this is all about making it as hard as possible to cheat, and the more details about things are out in the open, the easier it gets to cheat.

First, a good method is to have some value that changes with every word of input and use this (adding, xor-ing, whatever) to modify the input word. This ensures that, roughly, every word will occur equally many times, and so a lot of methods of breaking keys will fail. This by itself will not be enough, since anybody people with some experience in cracking encoded data may still be able to crack it. So in addition to this, the input has to be permutated, and a different permutation (again, generated by some value) has to be used for every frame. Both generators (i.e. the algorithms that change that base value all the time) can be initialised with some value ("key") that is kept outside of the MAME source, and these keys have to be sufficiently large (say 128 bits) to withstand brute force attacks.

The problems with this:

If the key is outside the MAME source, but is still used when compiling MAME, then (in addition to problems I do not like to discuss here) it can be argued that you are not making the entire source code public.

If the key is somehow generated outside everything, and has to be retrieved somewhere (like Chad suggested, from the internet, for instance), then everybody will more or less have a unique version of MAME35TG, which also means that nobody but the person who got the key and everybody who knows what the key is, can play back recordings. This probably means that only Mark and the person who recorded the game will be able to play back that recording. And if Mark uses some utility to convert it to a regular .inp file, then that, again, makes security very vulnerable. I don't think it's desirable that only two people can view .inps, especially not since this whole thing is first and foremost meant for world record .inps. What good is it if nobody but Mark can see it? And, no offence Mark, why should others take Mark's word for it that the recording is legitimate? That only shifts the problem.

A minor problem with using algorithms that transform an .inp into something resembling random data (because seemingly true random data is the only kind of data that is not susceptible to hack attacks) is that the .inps will not compress very well. A 10 meg .inp will, if it looks like it's random enough, remain a 10 meg .inp, even if zipped, or compressed with whichever, much better, compression tool you wish to use.

There are some more problems I can think of, but this will do for now.

Ben Jos.

-- Ben Jos Walbeehm (walbeehm@walbeehm.com), November 03, 1999.

I would actually prefer everyone being able to watch the inps.

This is getting a little extreme, like I'm trying to defend some super important secrets. All I'm trying to do is make EASY cheating somewhat harder. How hard is it to cheat on the normal release of mame35 or higher? It's just too easy to cheat.

The rules of the game should be enforced by the software, and I figured the way to do it was simply encrypt the inps, plug the major security hole, and axe the pause. The only time I used pause was to check I had enough hard drive space to record a game of Dig Dug.

I don't think there is a 100% solution to this problem. Why do care about this so much? Well, the Guinness Book of World Records published some bogus scores (not many mind you). This drove me crazy for over 10 years. I thought "There must be some way to have totally authentic high scores".

Then INPs came along and I thought "Great! There's no way to cheat now". Sadly that's not the case, especially after version 35.

I think the current TG MAME 35 version 2 stops most of the cheating. I'm sure it's still possible to decrypt the inps. I think most of the scores are true high scores. Certainly I can get the scores on the real arcade machines I've posted here, and they were published in the August 1999 issue of Tips and Tricks magazine. (This was from the first Funspot tournament in New Hampshire)

So Ben Jos, Chad and Chris: This is what I would like to do:

Make a TG/MARP version of MAME with open source, crafted in such a way so that everyone can playback the inps, and cheating is next to impossible. One thing possibly is everyone has 2 keys, a playback key and a record key. Your playback key is public knowledge, and only the player has knowledge of his record key.

Could such a scenario work?

Mark

-- Mark Longridge (cubeman@iname.com), November 03, 1999.

Its free, its exportable, its open source. http://www.gnupg.org/

I'm not into encryption but maybe it could be used?

-- Dave Kaupp (info@kaupp.cx), November 03, 1999.

Problems that can be addressed:

As for getting the key from outside source, that still makes the source code of TGMAME that gets the key public. Is the source of lynx not public because it requires a website to get an upgrade? i think so. just because you need information from a program from an outside source doesn't make it not public.

As for encrypting the whole inp file and introducing problems of it not playing back as well as not being compressable, i say it's not necessary. The only thing we need to verify is the times that the program is started and the time that the program is ended. As long as an honest recording takes 60 seconds to play, and its game fps is 60, then if there are 360 frames in the inp file that file is verified as long as you can verify the file was finished 60 seconds after it was created. You only need to encrypt the timestamps, which means you can still output a file that can be playedback by everyone, but ONLY verified by the person who knows the time sensitive key generation function and the decryption algorithm.

There are three downsides in keeping the key generating function in the mame executable: (1) the user can hack the system time, (2) the user can hack the key generating function and recreate their own valid timestamps, (3) the cheating code can be inserted backinto mame if the source is released.

There are two downside of keeping the key generating function on the net. (1) Mame players have to be online for the start and the end of recording a inp file, this can suck greatly because windows sometimes just hangs up and thus you might get the start time verified, you might not get the end time verified. (2) the program can still be hacked if people can insert the code that makes mame cheat into the executable which actually can be done easily if the source is released although it becomes more difficult with the digital timestamps needing to be refreshed.

There are plenty of free encryption algorithms, for this instance it should be good to find a least popular one (i have a link of some excellent encryption source that is free and won't be found on many search engine results) so that when compiled it won't easily be recognized as "such and such" kind of encryption assembler wise.

The best part is that those who compile mame don't have to know what the key is and the key changes each time you make a recording. But someone (a non marper please) would have to come up with a key generation function, that hashes, crcs, and/or encrypts the time in a complicated maner so that you get a unique key for each time it is run.

I've got a design of how everything would work in detail, if anyone wants to listen to more propaganda... I think i've solved all problems except the reinsertion of the cheat code if the source is released.

-- Chad (churritz@cts.com), November 04, 1999.

I have the deepest respect for Nicola, and I'm so greateful to him and all the MAME team. But this time I've got to disagree !!!

According to the license terms, Nicola is right, damn !!! But....we could easily assume that he's right if, and only if, a different MAME release is *public*. So far, if you Mark keep the TGMAME on your site, downloadable....well, you should, or better, must, make the source available too. On the other hand, nobody could oblige me to release the source of a version of MAME I eventually modified in any way and personally use at home.

Here's the "trick" to avoid the license: let's make TGMAME a "private" release and e-mail it each other MARP competitors.... therefore, we could state that everybody is "incidentally" playing here at MARP with the same, private version, of MAME. ;-))))))

That's why I actually hope that the sources will never be released.

Cicca

-- Cicca (cicca@writeme.com), November 04, 1999.

What I was kicking around would have had three factors - time, gamename, and a LARGE (at least half a meg) keyfile. The starting time would have been used to pick which part of the keyfile was used that session (intending on a 64k block), and the gamename would act as the seed for the encryption algorithm. If the algorithm is changed from a formula to a giant "look up" table then it could also be loaded from a seperate file, which I think takes everything really interesting out of the source code so we could get around the damn immovable object. It could be distributed with two "junk" files so record/playback would function properly even if you had to get a keyfile that the destination page (MARP/Mark/Sniper/T2/...?) would accept to register a score.

I know the sizes are probably overkill, and I don't have any special ideas how to fight a debugger/disassembler, but maybe it's a start?

Aqua

-- Aquatarkus (aquatarkus@digicron.com), November 04, 1999.

Just my 2 pennys.

I agree with Nicola, if someone wants to cheat they will find a way. About the only thing to do is detour cheating. Thats what I've been saying all along.

I also think that the re-record code should be commented out of the main source tree in mame, but anyone wiht coding skils could always replace it. It would only detour a regular joe from cheating.

I'm a firm believer in the open source movement. Alot of people put alot of work into MAME. They did not write mame for MARP/TG, nor do they have MARP/TG in mind while they where creating MAME.

The MAME team is about emulation, its not about high scores. Giving Nicola or the MAMEDEV team a hard time about not "getting into TG/MARP" or not "Understanding our problems" doesnt do MAME any good. There job is not securing a recording so a high score can be proved, there job is about emulation.

Now, if we could find a way to ultimitaly prevent anyone from cheating in an open source manner, I'm sure Nicola would include it in the source code. There would also be hundreds of developers knocking at our doors to find out how we made them pirate dudes stop cracking there copy protection. As previuosly stated and what Nicola was also stating. A piece of software sitting in a foriegn environment with the user at complete control is a very big security risk. You can not guarantee complete security, hence his false security statement.

All recordings no matter what is done will still be considered as invalid if not visually verified. I think this will not be a problem in the coming years when everyone has one of them little cameras sitting on top of there monitors that could be pointed at there monitor while playing a game. Until then, all scores are suspect to cheating. I'm sure someone will find a way to defeat the cameras also. :) PS: I still beleive that a TG version would fall under the personell use clause for official verification of the TG record books if it is not "distributed". There could be a clause in the TG record books that a MAME recording was done with a MAME version or a TG/MAME version that a person asked Mark to give then to record with.

-- Dave Kaupp (info@kaupp.cx), November 05, 1999.

Dave: I agree with you about MAME not being about high scores first and foremost. But they obviously thought about it somewhat, otherwise why even bother with INPs at all? And if you are going to bother with high scores (as I and others and the existence of MARP can attest to). So, since we do care about high scores, why not make it honest (or as honest as possible). Would anyone like it if they found out the Olympics had cheating (hmmmm, sorry, bad example! But at least they deal with cheaters!)

Anyways...I don't expect Nicola or MAME Dev to do any work specifically for high scores or MARP or TG etc, etc. I'm willing to put some time into it. This isn't all negative, as it gives me incentive to finally try and understand the MAME source. Maybe I'll even write a driver someday.

I think it's best to use the idea of MAMETG is a private release, which only the high score crowd cares about. It's just silly releasing the source code for this TG version, as it doesn't add anything at all to anyone's knowledge of emulation. It doesn't help to understand the drivers, or graphics or sound. The only people who would even care about a "TG/MARP" version are the MARP/TG people. However I'll tell everyone what I little I did do:

I modified two pieces of source code:

inptport.c Which deals with the recording and playback of INPs usrintrf.c Which deals with a variety of things, but all I did here was comment out some code pertaining to the pause function.

Oh, I did do one other little thing. I checked the return code to see if the inp was still being read, since if you are decrypting the stream, there's no point if the stream stops to continue decrypting.

Mark

-- Mark Longridge (cubeman@iname.com), November 05, 1999.

I'm not sure of others views on pausing and whether or not Mark's programming skills are up to it but what if instead of disabling the pause key he covered the game board. That way you couldn't use the pause key to help your gameplay - particularly timed puzzle games - but could still use it for a loo stop ?!

Dr C.

-- Dr Chip (Dr_Chip_ii@hotmail.com), November 06, 1999.

> But they obviously thought about it somewhat,
> otherwise why even bother with INPs at all?

Well - the original reason for adding recording/playback was so that if there was a problem with a driver which only showed up on certain levels, the driver developer could easily view that level by using a .inp file that demostrated the problem.

It would still be best if we could find an open source solution to the problem, but I really don't think that's possible. Whatever servers the open source code connects to, and whatever time stamps, keys, or whatever it gets from them, a recompiled-with-cheating- enabled version could also connect to, and carry out the same transactions with them, too.

Maybe I'm missing something, and there is a method of securing .inp files with an open source program, but I can't see it at the moment. Chris.

-- Zwaxy (zwaxy@mail.com), November 06, 1999.

As Chris stated, the original reason for recording inps was for debugging purposes. Has anyone asked Nicola to at least comment out the re-record code so that if someone wants to cheat *that* way they would have to compile there own version.

DR C: Good idea with that pause feature. The xmame version does dim the screen a bit when the pause key is pressed, blacking it all out would disable the advantage for using the pause key on some games but still allow players with other interuptions to continue to play there current game. Does the dos version dim the screen when pause is used?

-- Dave Kaupp (info@kaupp.cx), November 07, 1999.

The code was infact "commented out" in m35rc2 before mame35 so there was a reason nicola uncommented it out in the final version, so it's not likely we can convince him to undo it, tgmame is a better solution.

It is a good idea, but even with the screen blanked, you can do a screen shot before you pause and look at it on your computer while mame is paused blank.

-- Chad Hurwitz (churritz@cts.com), November 07, 1999.

The purpose of disabling the pause key is two fold. 1) so you can't study the screen and 2) so you can't take a rest break. Under tournament conditions, you can't do either of these, so there's no point in having any type of pause function.

-- Pat (laffaye@ibm.net), November 08, 1999.