Just thought I'd give everyone an update on my progress on MAME Tournament Edition. This is to get some feedback, maybe additional ideas, and also to find an answer to a problem I still need to solve. I have hinted at some of these things already during our meeting last Sunday, but now I have taken the time to think about it and to write it down exactly what I wanted to say.

As I have said before, knowledge is power. So I am going to be very paranoid about things concerning the inner workings of MAME TE becoming public knowledge. Within a matter of weeks after TG3 was released, it already was public knowledge that it recorded the speed and disabled the Pause key, and that (apart from encrypting the .inp somewhat) that was all it basically did. I hated the fact that this became public knowledge. If people know exactly what gets recorded, then they can try to find ways to cheat that involve things that do not get recorded. And also, if they know what gets recorded, then they can set out to find exactly how and where that information is stored in the .inp and then edit a recording to make it look legitimate. Both Chad and I, independently, found a way to take a regular mame35 final .inp and convert it to a TG3 .inp while adding "valid" speed information to it. I think we both accomplished this even before we got a copy of Mark's Checker program. With a copy of Checker, it becomes even easier, because (1) while hacking you can immediately check whether you are on the right track or not, and (2) the additional information that Checker gives (viz. it displays speed values) makes it easier to find where and how the speed information is stored.

So I am not going to reveal exactly what kind of information MAME TE will store in the .inp, and this causes a bit of a problem. Ideally, I'd want to have a checker program for MAME TE recordings that gives no information at all. That is not feasible of course, because it would be useless then. At the very least, it has to say whether the .inp is "good" or "bad". That in itself already gives some information, but there is no way around that, because I do not want to be the only person able to check MAME TE recordings. On the other hand, I do not want my fellow editors to disqualify a recording based solely on the fact that the only thing a checker program said was that the recording is "bad". So where do I draw the line? Do I say "too slow", or do I say "too slow: average speed 78%", etc.? I do not want to reveal too much, but at the same time, I also want the editors to have some idea of why a recording is "bad".

And what constitutes "bad" in the first place? Sure, I think we have already agreed on an average speed of at least 95%. But when somebody plays at 50% speed during the hard parts of a game (adding up, maybe, to only a few minutes of play time), and at 102% for the remaining hour or hours of the game, then the average could still very well be at least 95%. So maybe a checker also needs to give some information in case at least a certain number of consecutive frames is below 95%.

I am not going to send out interim versions of MAME TE, because seeing it in various different stages would make it easier to hack. So I'll send it out once everything I wanted to put in is in. And at that point, it will be sent out as an internal version, so one that only editors will get to see. I'd like to have a beta testing (and hack attempt) period of several weeks at the very least. I do not want to rush things, so I would not be comfortable releasing it to the public in time for T5. The more effort we put into it, the more secure it will be, and the longer its lifespan, usefulness, and reliability will be.

It should be no surprise that MAME TE will record the speed, but in addition to that, it records a lot more things. And even if people partially hack it, there is a very good chance that the upcoming checker will still catch them, because of all the extra information and checks that will be built in. Although a recording would still play back fine in a lot of cases, the checker program will still catch cheating, just like a slowed down recording in TG3 would play back fine, but still be caught by Checker/InpSpeed. In particular, I have spent a lot of time in finding ways to either render impossible or make detectable all the different ways I knew of hacking TG3.

At this point, most of my code is done, but it is not part of MAME yet. Most of it is in a small standalone program that I used for developing and improving the code. And even though the program would take an existing 36 final .inp, convert it to a 36 final TE .inp, then take the 36 final TE .inp and convert it back to a 36 final .inp (which was a good way of testing both encryption and decryption), the upcoming Checker would have no trouble in seeing that the TE .inp had not been generated by MAME TE. I guess what I'm trying to say is that at this point, even I would have quite a bit of trouble hacking TE, despite the fact that I wrote it. Even taking MAME TE and reverse engineering and modifying it to re-enable some disabled features, will more than likely result in one of three cases: (1) the hacked version of MAME crashes, (2) the .inp doesn't play back correctly, or does not even record correctly in the first place, (3) the upcoming checker will catch it.

I realise that some things about MAME TE will easily become public knowledge. After all, it will be easy to see that hitting the Pause key while recording won't have any effect. I'd very much appreciate it, though, if all the editors could refrain from mentioning even the most trivial things like this in public. It's a lot easier not to say anything at all than to say things and to try not to let anything slip by. A few times, things have been revealed in the past that either weren't public knowledge, or, even if they were, not everybody knew about. After all, new people are joining MARP all the time, and those may never have heard about things that were revealed a while ago. And of course not everybody present when it was revealed read about it. I am pretty sure that, unfortunately, there are people who do not cheat right now only because they wouldn't know how. Reveal all the ways that people can cheat undetectably, and the number of cheaters and "bad" recordings will undoubtedly go up significantly. The only way we can place trust in the authenticity of a recording is if we can be relatively sure that no cheats or no hacks were used. Revealing inside information about MAME TE would breach that.

If I were the only one with any information on the inner workings of MAME TE, then it would be easy for me to keep track of what I revealed. And as long as I wouldn't reveal anything, nothing would get known. I know I may sound paranoid, but, to my knowledge, two people have hacked TG3 (Chad and I), so it would be very foolish to assume that we are the only ones who did or who are capable of doing it. At the same point, I don't want to hide everything from my fellow editors. So you are more than likely going to get information about MAME TE that I would never want to become public knowledge. So I am asking you to please be disciplined about it. Speak about MAME TE in public as little as possible, because that reduces the chances of anyone letting anything slip by. We are all fed up with the cheating on MARP and MAME TE is a way to fight it. Please don't let it become useless.

Mark started hinting a long time ago at the fact that maybe I should write the successor to TG3. I have always had very mixed feelings about it and I still do. Because I am a player as well. I want to play games. And I don't want the fact that I wrote MAME TE disallow me from participating in tournaments. And I know that I'm am going to get some flak from other people from time to time. Recently, Vaz said something like "but who checks the editors?" to me when I told him only editors had access to the .inp analysis tools. I am more than likely to get to hear people ask "but who will check Ben Jos?". I don't know. I am not ready to retire from playing yet, but I got fed up with the cheating on MARP. And, based on experience and education and MARP involvement, I realised I was one of the best MARPers to do a more secure version of MAME. I still don't like it, but I didn't see any other way.

Questions, remarks, comments, criticism, ideas?

Thanks for listening. Cheers, Ben Jos.

-- Anonymous, September 12, 2000

Answers

i'm just glad i won't have to have the flak you might get :) at any rate: bravo, bravo, bravo, I think what you are doing is very cool. And if the editors can help in anyway, they should do what ever they can to get this project fullfilled.

I think the paranoid aspect of it is very important, however i don't share the same concern about revealing "some" of TEMAME techniques. All of them is a different story, but i think selected hints to techniques used (if they are strongly hack proof enough) would discourage hackers from even attempting to use the secure mame, i.e. bring the knowledge of hints home (along with the knowledge that there are more techniques not revealed) and try to hack with them and find they can't.... But i certainly don't think we have that strongly hack proof techniques yet, but i haven't heard much about TEMAME so far. I very much like the idea of keeping TEMAME a secret, but also remember the less people know about it the more they can acuse it's not much more secure than tg3mame.

I do think we could find another name for TEMAME because i don't want it to be just for tournaments. and i'm sure we can come up with a nice acronym for a new name. MARE comes to minde (Mame accurate replay emulator) but that's LAME.

-- Anonymous, September 12, 2000

Ben Jos, I am really looking forward to this upcoming version!

Reasonable wish list:  MAME TE release to coincide with m37final, not enough time for T5  ALL-IN-ONE checker for checking MAME TE INPs. (CHECK-TE.EXE)  For starters, parameterless input--full report output  Disable speed throttle when recording  Disable TAB key after a credit has been inserted  Disable player 2,3,4 controls and credits  Poke and store computer data in INP (eg. CPU speed, bus speed, etc)

Radical Wish list!! There are some real beauties in here!!  Auto record with MAME TE using same name for INP  Disallow playback on MAME TE or checker program to playback AND test  Link to external customizable files for game data (lists, dips, fps)  Encode date and time stamp into INP and check to match what DOS says  One byte checkdigit for each line to prevent file tampering!!  Detect multiple keys mapped to the same game function  Trap and block OS multitasking features (CTRL+ESC, ALT+ESC, ALT+TAB)

Don't worry about "Who will check Ben Jos". I can watch you! :)

-- Anonymous, September 12, 2000

Chad: There's a lot of redundancy in it in the way of checking. Reverse engineer and hack it, and there are bound to be other parts of the program where Checker will catch it. In a way, I don't care if people think it's not much more hack-proof than TG3. Let anybody (Lamat or Krol, preferably) try to cheat on it and upload the .inp, and they'll be in for a fall.

I agree on the name. I am not very imaginative as far as names of programs are concerned. As long as things are not final, I am open to suggestions. I just don't want to call it "secure", because I know from experience that all protections can be broken if people are willing to put enough time in.

Pat: It will probably be final before 37 final. And if QT's suggestions are anything to go by, there might be versions that will follow every official MAME beta release.

All-in-one checker: It's possible, but at this point, only if I am the one doing the Analinp compilation. So far, Chad has been doing the compilations and distributions. There would be a part of the source code that only I can put in. And as long as I want to keep the source a complete secret, only I could do the final compilation.

From your "reasonable wish list", most of those are already in there or will be. I don't want to get into the details at this point, though. :-)

Radical wish list:

- Auto record? What do you mean by that?

- Disallow playback? I'd rather have some notorious cheater find he can play it back correctly and then still get caught by the checker than not have it play back correctly in the first place.

- Link to external files... that's a lot of work. Instead, I'd rather take it upon myself to extend my CheckDIPs program to handle new games. Besides, in some cases, it might be preferred to allow more than one setting on a game.

- Date and time stamp. Yes. But if someone changes the clock on their computer (including TOD), there's no way of catching it. In other words: There is no way to tell what date it REALLY is.

- One byte check digit: I'd rather refrain from comments, but let me just tell you it does a lot more than just one check (and some of them will screw up the .inp completely when tampered with)...

-- Anonymous, September 12, 2000

Aaaaaaaarrrrrrrrggggggggghhhhhhhh! I hate when I click the wrong button. I wasn't done yet. :-)

- Detect multiple keys mapped to the same function. We should discuss this. Because I don't see a significant difference between this and having a joystick with large enough buttons to be operated with several fingers. We can't catch the latter. Why disallow the former then? Even more so, "official" world records do not disallow people from using 2, 3, or 4 fingers on one button.

- Trapping OS keys. This is pretty much impossible. Even when writing Windows programs, it's extremely hard to catch Alt-Tab for instance. In the DOS version, it's even harder. However, we don't have to worry too much about this, since Chad has already shown that the speeds recorded will catch this.

Cheers, Ben Jos.

-- Anonymous, September 12, 2000

Oh, and last, but certainly not least: Thanks for the support. You guys seem even more motivated than I am.

Cheers, Ben Jos.

-- Anonymous, September 12, 2000

Oh... one more thing I just thought of...

We mightn't even need an all-in-one program. Bubble has done a great job on his front-end (MarpFE). It's pretty easy to configure his program to use several tools on a number of selected files.

Cheers, Ben Jos.

-- Anonymous, September 12, 2000

I'm not concerned if hackers think it's not hack proof, i'm concerned if legits think it's not as hack proof as tg3 since the really honest people might not use it if they think it's still hackable.

Timestamp is sort of useless in determining date, but recording the encrypted timestamp of begin time and crc hashed end time of the recording, is a perfect check to ensure the frames add up to the seconds taken to record the game. (i would assume your doing this because this is a really good check).

I also hope you are hashing/seeding/keying the encryption algorithm with something including timestamp, gamename, and perhaps a mame.cfg option value.

I don't really want to ask this but it would be something i would try to guess and probably find out if i had more encryption experience, are you using any standard encryption algorithms or ones you've written yourself? A mix would be prefered over either of the two.

Oh, i also wanted to ask (and didn't hit submit yet :) that you mentioned you would have "trouble" hacking an inp not recorded by TEMAME into a checkable/viable TEMAME recording. I find that hard to believe because if you have the TEMAME source you could take that code and copy it to a TEMAME converter program and convert away with out neededing to use TEMAME. Why wouldn't this be possible?

-- Anonymous, September 13, 2000

one more thing, how much cpu time does encrypting the source take? this may be important and could affect the performance of mame to play games at a reasonable speed. i'm sure you've thought of this but i want to know if you think it will be as "fast" as tg3mame.

-- Anonymous, September 13, 2000

Yes, there is some form of timestamping.

Yes, the encryption is my own, but it is based on knowledge obtained during a university course I took in it.

Yes, lots of "things" are included in the encryption as seeds or otherwise. Everything is extremely interconnected, so even if you were able to change the timestamps inside the .inp, it would either completely mess everything up (the .inp wouldn't) play back anymore, or it would be detected by the checker program.

As for me having trouble converting a regular .inp to MAME TE format and have it be undetectable by the checker program, there are several reasons for it. The combination of the fact that timestamps and the values of several MAME variables are stored makes it very hard. I can convert a 36 final .inp to MAME TE format and it would play back fine, but the checker program would find a lot of things wrong with it. Let's leave it at that for now.

As for speed, the encryption is very fast. Moreover, since there will be a LOT less I/O in the form of hard drive accesses, the whole thing might even be faster than TG3 or regular MAME. The reason that there will be a lot less I/O is that the .inp is compressed at run-time. For instance, a recording that would result in a 2 meg .inp in 36 final, would result in an .inp of less than 30k in MAME TE...

Cheers, Ben Jos.

-- Anonymous, September 13, 2000

can you answer yes or no to: do you store the number of seconds difference in the clock from begining recording to ending recording (hopefully not including the time mame starts but the time the game starts after the 'O' 'K' and returns) in the inp?

I'm still not sure temame can check variables and encrypt them you couldn't duplicate that code for a outside temame inp encrypter. I guess i'll take your word for it.

Compressing may not be faster than IO but the magnitude of compression matters for that. we definitley need to test this with slow games a lot with a temame and mame side by side (or one after the other with autoframeskip on and measure the average fps printed out when mame finishes), and that is beautifull to compress the inp while encrypting, very pgp oriented hmm have i found a clue? :) I'm glad you say you might even have a version out before mame37 final finishes to test and possibly release a version for mame37.

dang i haven't thought of any cool acronyms but i'm sure we can come up with something clever.

-- Anonymous, September 13, 2000

 I would say that if you plan to release a version that follows every official MAME release, then we should consider doing away with these releases and only accept TEMAME recordings or may I suggest the name MARP.EXE... My personal belief is that it's less work and better stability comes from 6 month releases.

 The date and time stamp is important so as to catch a basic cheat. Let's say someone forgets to change the date/time, records the INP, and then after the INP is created, decides to change the date/time. This would catch date/time changes DURING OR AFTER the INP is created.

-- Anonymous, September 13, 2000

Chad: Yes. There is enough information for a very detailed analysis of the exact time used.

And the reason I compress the .inp run-time is because of redundancy. The more redundancy in a set of data, the easier it becomes to hack. A good example of redundancy is the English language for instance. You can leave out two thirds of the letters in any non-trivial piece of text, and it will still be pretty clear what it said. A good way to see how much redundancy something contains is to try compressing it. And, ideally, well-encrypted data looks like random data, so, by definition, it does not compress. While it is not very hard to encrypt an .inp so that it looks like more or less random data, it's of course highly impractical. It wouldn't compress and so we'd see 10 meg and even larger .zip files. So I "had" to take out the redundancy.

Pat: Forcing people to wait until the next official release is probably going to meet with a lot of resistance. People already started bitching when they had to wait a few weeks to record b6 games. I don't think I want to deal with that. Maybe some compromise like every other beta, or one in every three betas or something, at least for regular MARP? I don't really want to release a new MAME TE with every beta, because of all the work involved, but it would probably make a switch to a MARP where only MAME TE recordings are allowed the smoothest.

Yes, it has timestamps. All I was saying that it wasn't hard to just change the date/time on your computer and it can't be detected. But, yes, I'm hoping that somebody will make a stupid mistake anyway. So I definitely do not leave things out, just because a cheater has to be really careless to get caught. I don't expect people to get caught this way, but there is no way I'm going to leave things out because of it.

Cheers, Ben Jos.

-- Anonymous, September 13, 2000

Oh, about the all-in-one checker without having to specify any switches, Pat: Bubble's MarpFE can be configured to use any program with any number of switches. Furthermore, it's a GUI program, so you can just select one or more files and have them all checked with just a single click. And, last but not least, you don't even have to unzip the .inps anymore...

Cheers, Ben Jos.

-- Anonymous, September 13, 2000

Ben: i hope you're using a Limpel-Ziv derivative and not compressing by bit count. are you sure all the code you are using is free or written by yourself, that is the most important part you know to keep mame free. We'd also have to make sure it's compiled for 386 architecture just in case someone wants to record a really fast game (sinv) on a slow computer...

Compiling every beta would ideal provided compiling mame is easy but it is not. I'd say build "MARE" every final release let people "practice" with regular mame (grandfathering all previous recordings), but only allow new points to be scored with the new mame and maybe allow half as much points for non-MARE recordings. I don't think we can accept zero score for non-mare recordings or no one would play new games (actually i kind of like that idea now.)

(MARE isn't the best name but we can't call it MARP.exe we're not running a "page" executable :)

-- Anonymous, September 13, 2000

adding the diffuclty of compiling a mare for every beta is that you have to do multiple platforms... Ben: how familiar are you with compiling xmame? i'm pretty familiar with it, and i would definitley like to walk you through compiling it for a linux box, i think it's about 3 times easier compiling for xmame than dos mame (and who knows how much more difficult than winmame). I can also help with any portability issue you would have as long as you think reporting the issue to me doesn't give any tricks away.

-- Anonymous, September 13, 2000

Although I'm not the best with hacking the program and stuff - I can look at things through a publicity issue - so I want to prepare a statement now and release this statement WHEN THE SOFTWARE IS RELEASED PUBLICLY. In other words - I'm creating a rough draft.

Something like this:

MAME 37 TE Final has been released in it. What's different from the original MAME? I don't know. But I do know it will begin to become the official version of the (link)MAME Action Replay Page(end link) - the site of over 15,000 recordings created on MAME.

Sound good to everyone? Cicca is GREAT with publicity - so his help might want to be used here. We probably should also try Dave's Classics(now Vintage Gaming) as well - this can draw tons of hits to the website. The March 21st, 1998 record of 870 hits is still the record to this day - because of a link from that page.

---------------------------------

Next - let's talk about compatibility: how far are you going to take the compatibility? I think Linux and Windows and Mac if possible should be ported. It's only my opinion... but if we want to make MAME 37 TE the only version allowed in MARP - then it should be ported to at least an extra platform or two.(at least windows... please? With a cherry on top?)

-----------------------------

A final opinion on the checker program: I must look at this through a tournament perspective. There will be judges that may have to use this checker.

Therefore - I propose two types of checkers if this has to take place (and there are some very trustworthy judges we've seen over the past 4 tournaments) - then I only suggest this printing for the judges checker:

Pass / Fail.

That's it. Then it would be the judging coordinator's responsibility to determine exactly why(because he has the editor's version of the checker).

For editors - something like: Cheat(Average speed: 84 %) - Cheat (tampered with INP) - Cheat(Fastest average autofire speed: 2.48) - should be sufficient enough to understand what they did. I hope that this in itself wouldn't be too much information.

How can we avoid distribution of the "advanced" editor's checker file? Best thing would be give the editors version a strange filename (3jfi21so.exe), and the judges checker an easy filename(checker.exe).

To establish something: the judging coordinator of the tournament is Pat Laffaye - who is an editor to this site.

That's my opinion on things - thanks for reading. GB9

-- Anonymous, September 14, 2000

All the code was written by me. I also developed all the algorithms myself. So I am not using anyone else's code, nor am I using possibly patented algorithms.

I am not adding any code that won't run on a 386 as well. I can't guarantee that the rest of MAME doesn't contain code that wouldn't run on a 386.

How about calling it something like ReMARP? It doesn't really have to mean something. If it sounds nice, that'll do as well. Some didn't want it to be called MAME TE since it wouldn't be limited to tournaments. I don't really see the problem with that, because isn't MARP in itself some kind of tournament? Or, stated differently, if we call it something with "MARP" in the name, does that mean it can't be used outside MARP? Anyway, coming up with names for programs has always been a problem for me. No imagination whatsoever. :-)

Hmm... right... I hadn't thought about the ports. So far, I had only been thinking about only DOS and Windows. But, yes, if at some point, MAME TE is going to be the only allowed version, then I guess we need more ports. A Linux version shouldn't be too hard, and maybe it'll finally force me to do what I've been meaning to do for years: Install Linux on a machine at home. A Macintosh version might be a problem, though. On the other hand, I think there are only 1.5 people using a Mac on MARP. Ejoty seems to be pretty active, though. Although there are more platforms that MAME has been ported to, do we even have recordings on MARP for those (like BeMAME or AmigaMAME)? Well, I'll worry about that later. I want to get a DOS version up and running first.

If MAME TE is going to be the only allowed version at some point on MARP, then we should probably not do it immediately. I'd rather see (as yet another test) it used during some tournament first, to see if I didn't miss anything.

Hmm... announcing it publicly... I'm not too sure I am too crazy about it. I mean there is always the issue that there is a very small part of the source code that I cannot release without making MAME TE completely useless. Its reliability is based on the fact that people have no source code to see how .inps are encrypted and what kind of information is stored exactly. TG3 has been around for a while now, but it has always been kept at a low profile. So it looks like Nicola (although he may not like it too much, and apart from one or two short remarks he made) more or less allows it. But if we made this all a big occasion with lots of publicity, what would happen then? I see no alternatives to keeping the "extra" parts unpublished. I can't think of a feasible way of making a version of MAME that is very secure, yet at the same time fully open source.

I have been thinking of two versions of a checker for a while now myself (actually, three). I don't have too many problems with giving one to the editors that gives some information, as long as it never leaks out to non-editors. But even a pass/fail version could be too much for regular judges during tournaments. I mean, suppose I wanted to cheat and I obtained a copy of the pass/fail version. That part is easy. Hell, even Lamat has an copy of an old version of Analinp. Anyway, so I start cheating and recording and I will have immediate feedback on whether it worked or not. So I can try dozens of different things a day. And once it says "pass", I know I'll have succeeded in fooling it. I'd much rather have such a person be caught and publicly stoned or something, than to give him a tool that keeps him from getting caught. On the other hand, any version of MAME that we consider secure should be able to withstand such a brute force attack. Anyway, once you guys get a copy of MAME TE, I'll also send along a checker, so that you all can attack it.

Cheers, Ben Jos.

-- Anonymous, September 14, 2000

yes lets not release ANYTHING press or exe's untill we have a working stable fast version of MARE (darn i still like that name but i know we can think of something really clever) That records and playsback as many games as we can make recordings for.

I would also recommend encrypting checkers with pgp when senging exe's to the editors that should not be released to anyone else. we could probably create a userkey for marpeditors and then ben could encrypt with his private key and marpeditors public key, then the editors could decrypt it with the editors password what ever we choose that to be. I think sending the exe's over mail uncrypted would be useless if we are going to try and keep the enhanced checker program under arms.

-- Anonymous, September 14, 2000

This may not be the right thread, but I wanted to make a name suggestion for the new version. Since it's a tourney edition, why not simply call it...

TMAME

It almost spells like TGMAME, but since our association with TG isn't really tight, I think it would sound suitable for general tournament usage.

-- Anonymous, September 21, 2000