forums.marpirc.net

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.

<p>

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

<p>

Thanks to everyone for the encouragement.

<p>

Mark

--
cubeman@iname.com

Well Nicola responded to my message:
<p>

Mark Longridge <cubeman@idirect.com> 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.

<p>

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

<p>

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

<p>

Nicola Salmoria
MC6489@mclink.it

--
cubeman@iname.com

The MAME dev coordinator has spoken.
<p>

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

<p>

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...

<p>

I'm interested to hear everyone's ideas.

<p>

Thanks..

<p>

Mark

--
cubeman@iname.com

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.

--
cparsley1@hotmail.com

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...

<p>


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.

--
cparsley1@hotmail.com

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.)

<p>

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.

--
churritz@cts.com

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

<p>

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.

<p>

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.

<p>

The problems with this:

<p>

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.

<p>

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.

<p>

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.

<p>

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

<p>

Ben Jos.

--
walbeehm@walbeehm.com

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

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.

<p>

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.

<p>

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".

<p>

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.

<p>

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)

<p>


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

<p>

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.

<p>

Could such a scenario work?

<p>

Mark

--
cubeman@iname.com

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

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

--
info@kaupp.cx

Problems that can be addressed:
<p>

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.

<p>

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.

<p>

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.

<p>

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.

<p>

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.

<p>

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.

<p>

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.

--
churritz@cts.com

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 !!!

<p>

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.

<p>

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. )))))

<p>

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

<p>

Cicca

--
cicca@writeme.com

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.

<p>

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?

<p>

Aqua

--
aquatarkus@digicron.com

Just my 2 pennys.
<p>

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.

<p>

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.

<p>

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.

<p>

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.

<p>

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.

<p>

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.

--
info@kaupp.cx

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!)

<p>

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.

<p>

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:

<p>

I modified two pieces of source code:

<p>

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.

<p>

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.

<p>

Mark

--
cubeman@iname.com

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 ?!

<p>

Dr C.

--
Dr_Chip_ii@hotmail.com