AlphaMame Blocking Bonus

Discussion about MARP's regulation play

Moderator: BBH

AlphaMame Blocking Bonus

Poll ended at Mon Mar 10, 2003 10:57 am

[For Blocking] <br>Block regular dos and windows mame recordings from beating alphamame recordings. All recordings prior to date of begining of the vote (3-3-2003) will be grandfathered to be "ok" to remain beating alphamame recordings.
24
80%
[Nay Blocking] <br> Leave it the way it is, all recordings can beat any others, even when regular mame can use cheating that is not detectable. But Allow for a tgmame leaderboard bonus to be decided later.
6
20%
 
Total votes: 30

User avatar
Chad
Tournament Coordinator
Posts: 4463
Joined: Tue Mar 05, 2002 3:15 pm
Location: calif

Post by Chad »

LN2 wrote:
mahlemiut wrote:You can always bypass that by killing the process before it gets a chance to start encrypting.
You lost me here...cuz if you did that...then on playing it back in alphamame it would alert you it doesn't match and wasn't encrypted wouldn't it?
"killing" meaning signaling the process (a unix term), you can kill or suspend the mame process (in windows too, the current alphamame will still detect that), copy a cheating file into the same location as the file being made by the "ln2 proposed" new version of alphamame, then continue the mame process hit escape and watch the cheating file be encrypted. Encrypting on the fly is the best way to avoid this trick, what alphamame does now. The only safe alternative to allow a mac mame recording watch an alpha mame recording is to make an alpha mac mame :)
-skito
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

Chad wrote:"killing" meaning signaling the process (a unix term), you can kill or suspend the mame process (in windows too, the current alphamame will still detect that), copy a cheating file into the same location as the file being made by the "ln2 proposed" new version of alphamame, then continue the mame process hit escape and watch the cheating file be encrypted
Yes, I totally understood it...but if the inp file is never "closed" until after the encryption is done at the end after hitting escape, then you can't replace with any other inp file...cuz the file pointer within alphamame is still for the inp file it created during that run. If they rename the file and put a substitute file there your file reference pointer within the running alphamame would still be pointing to the correct inp file...not your substitute one.

Your above is only possible if you formally "close" then reopen the same filename...then someone could rename your current inp after shelling out...then move a different inp of the other inp original name into the inp folder..then hit escape back in alphamame and if it reopens the file it would be that substituted one...

...so my point was just don't close and reopen the file. Save it as a sequential file so you can rewind to the beginning to just reread the data in the file without having to close and reopen it.

Heck, for most games the inp file doesn't get large enough where you could even use the tmp file structure in c/c++ so a virtual file is saved...that you wouldn't even have access to as a user shelling out at all...then when you hit escape it generates the encrypted inp from that.

I was only saying if you really wanted to have it do that you could.
scorpion
Button Slapper
Button Slapper
Posts: 8
Joined: Sun Mar 31, 2002 7:17 pm

Post by scorpion »

Excuse me for coming in so late in this discussion, but I think that AlphaMAME is using the wrong technique.

The purpose of encryption is to "hide" information from individuals who do not know some secret value and/or do not posess some particular device/characteristic. I don't think the purpose of AlphaMAME is that of hiding information from its users. (If it was then it could be considered "spyware").

What AlphaMAME is trying to do is "authenticate" an INP. That is, to certify that the INP was created using AlphaMAME, and that it has not been modified since it's creation. No "hiding" of the INP data should be necessary.

A technique to solve the authentication problem already exists. What is needed is a keyed MAC (message authentication code), appended to an otherwise unencrypted file. This small (typically 8 to 24 bytes) value provides security against the INP being modified.

Except for the appended MAC, the file can be a standard INP. Thus it will be compressable as normal, and replayable by any standard version of MAME. Of course if you add additional fields, like frame rate, etc, then this may introduce incompatibility, but a simple utility could be written to strip these extra fields and produce a "normal" INP. (This utility would not need to know the MAC key).

Now if you don't like using "traditional cryptographic techniques", then you can still do the same thing just by replacing the keyed MAC with some "super secret unhackable hash function" that you run across the data as the INP is recorded, and append the final hash value to the end of the file.

I see this suggestion as just as secure as the current technique, more flexible, and slightly less painful for users.

Comments are welcome.
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

scorpion...exactly...that was my thoughts exactly for saying just generate a separate little file that has that exact type of info you described and just call it .enc or something.

In the zip you submit you would need both the inp and the enc file. The cool thing here is the inp file is no different than what you would have from a nonalphamame. This allows easy viewing on even other platforms like MacOS or Linux.

Nothing is compromised using this technique either.

Also since you have the original inp as well...that compresses really well as usual...so you really are only added a very small file to each archive...that results in a much smaller zipped archive versus encrypting the entire inp.

When I first posted this (in a couple different threads) it seemed well received and was thought to be a great idea. however, Barry seems to think it somehow adds a loophole where you can fool alphamame.

...cuz all you would need to do then is hack and figure out what the content of that small .enc file is..or in your case a footer at the end of the inp...which Barry seems to think given that content you then would be able to write utils to generate that footer for any current inp from regular mame so fool others into thinking it's from alphamame.

I guess theoretically it's possible but my guess is it's just as likely those hackers could disassemble alphamame and figure out the encryption code anyway.
User avatar
Chad
Tournament Coordinator
Posts: 4463
Joined: Tue Mar 05, 2002 3:15 pm
Location: calif

Post by Chad »

I'm not sure where the users feeling pain: record in alpha mame, playback in alphamame, seems pretty simple. The only reason i can see it being troublesome is if you DONT have the secure version of mame (easily downloadable with the GET MAME link) and you only want to playback recordings with regular mame. The thing is: if you are playing back secure inps you proly should be recording with them so you should have the secure executable anyway. Plus, if you record speeds in the recording per frame, YOU HAVE to use a different secure executable to play the recording back. AND we HAVE to record speeds per frame for better security and pause detection.

About the hashing technique, this is possible, but it also makes an inp INVALID if it doesn't have the ending check frame. This can cause confusion with verifying programs which will undoubtably report the initial integral speeds of the recording are fine (even though they dont have the right signature at the end of the inp) BEFORE the end of the recording is reached. This could cause someone to mistakenly verify the inp as OK when it's not. And the worst problem with this is that mame or a computer could go down during the recording where someone has already broken a record and the inp would be invalid because mame didn't finish properly and write the verification frame.

I still say the way we are doing it is the safest and most secure possible at the moment.
-skito
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

Chad wrote:And the worst problem with this is that mame or a computer could go down during the recording where someone has already broken a record and the inp would be invalid because mame didn't finish properly and write the verification frame.
Oh, good point there. That does support having that info and encryption live then so at any point if you freeze or mame crashes etc. you have the playback still. I didn't really think of that...I guess cuz my Mac crashes so infrequently. I forget you all are using M$Windows. hehe j/k
scorpion
Button Slapper
Button Slapper
Posts: 8
Joined: Sun Mar 31, 2002 7:17 pm

Post by scorpion »

Chad wrote:I'm not sure where the users feeling pain
It's not a great pain, probably just more like an annoying twitch. This is caused by the users needing double the number of MAME binaries (i.e. normal and Alpha for each version), but mostly this is a solution to the compression and CPU usage problem.
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

I think it's something that if there was an alphamame for version 0.53 or 0.37 or 0.58 even might satisfy some.

MARP passes this alphamame requirement which is only been around for 0.63 and later. Many with slower PCs use older versions of mame to play cuz game performance on older versions for many games is far better than current mames.

You can easily have a situation where a game runs twice as fast with that older mame like 0.37 or 0.53 than it does in current 0.63+ versions.

MARP seems to have taken the stance...oh, just go buy a new PC then...and IMHO that's sort of cruel to just say screw all you guys using older, slower hardware as of March 3, 2003...just cuz there is no alphamame build for the older versions of mame.

I know Barry would rather not make an alphamame build of older versions of mame but given that is the statement MARP is saying above, perhaps he really has been pushed in that direction...at least for one of those older versions...as well as 0.36 for the Sega games.

Just my $0.03 there(inflation you know).
User avatar
Mr. Kelly R. Flewin
MARP Knight
MARP Knight
Posts: 317
Joined: Thu Jul 18, 2002 4:59 am
Location: Somewhere over the Rainbow

Post by Mr. Kelly R. Flewin »

LN2 wrote: I know Barry would rather not make an alphamame build of older versions of mame but given that is the statement MARP is saying above, perhaps he really has been pushed in that direction...at least for one of those older versions...as well as 0.36 for the Sega games.

Just my $0.03 there(inflation you know).

Wellllllllllll from what has been seen in the forums, he's already running low on space as it is from having to compile the other versions as it is, plus the compiler programs changing all the time.. and a "F*CKING MODEM" that should make you feel shame that he has to use it.

I mean if there was a way I could nab all the stuff from him and throw her down on a cdr and send back to him, so he has a backup [since I'm not a programmer by a long shot... no wait... I dabbled a BIT in... Q-Basic 4.5 Professional... hardly enough to know wtf I am doing though].... Maybe then if he had the time, and now new space, he would be able to swing it.

But I know Barry hasn't done this passing with the intent of "screwing over" people with slower pc's. I mean I could get all nasty on yo' ass and pull a Mame.Net forum posting by saying;

"Get yo ass off of that couch you fat pork and upgrade yo' ghetto pc and stop whining!"

But oddly enough.. same advice would be applying to me ^^;; so I know your pain. Given time and some patience, an older release will be available.. the only thing is, then comes the fun of downgrading romsets to work with it ;) I mean there are SOME places you can do it... mind you.. as illegal as it would be.. if someone had compiled constant cdr sets of all the roms for every new mame release... that'd be wicked.... [even if in some later versions, redundancy may stay]

I applaud Barry for all the time and effort he has put in for us... I mean all the binaries he's pulling off atm for every release [thanks for the Mame32 version Barry ^^] ... and I know patience will pay off.... or a nice sizeable cash donation [hint hint hint hint] to both Barry and the Mame PCB dumping crew... maybe some beer for Barry and other MameDevs? ;)


Kelly

-Patience is a virtue, Pac Man is a game.. both require time to Master ^^
Just a gaming junkie looking for his next High Score fix.
User avatar
mahlemiut
Editor
Posts: 4183
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Post by mahlemiut »

Mr. Kelly R. Flewin wrote:I mean I could get all nasty on yo' ass and pull a Mame.Net forum posting by saying;

"Get yo ass off of that couch you fat pork and upgrade yo' ghetto pc and stop whining!"
Ooooo, is that meant to be Galibert or Belmont? :)

I could use a new PC myself, not that that would happen anytime soon. 950MHz was sooo l33t over two years ago...
- Barry Rodewald
MARP Assistant Web Maintainer
Image
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

Mr. Kelly R. Flewin wrote:Wellllllllllll from what has been seen in the forums, he's already running low on space as it is from having to compile the other versions as it is
True, but if he gets a CD burner for like $50, he can backup lots of stuff and free up space. Heck, you can get a decent 18 or 36 gig HD for around $100 nowadays.

Compiler versions won't really matter will they? He can port the code to the same compiler he has done these alphamame versions in. However, if they don't port very well...then yeah I understand...and screw it. hehe

However, I hope MARP makes some exceptions for this alphamame blocking then for games like Hang-On! In later versions since 0.36, you can't see the motorcycle if not turning...plus a few other objects don't show either. I wouldn't want someone to play this game in alphamame getting a crappy score and yet that goes above all since March 3 using 0.36. The only reason for using 0.36 is so the game runs properly. Other games using that same Sega engine have similar issues as many here already know.

It would just be nice if games like that have a special rule that version 36 can be used...and if the code has a way to bypass the blocking for specific games as exceptions.
CMP
Button Slapper
Button Slapper
Posts: 16
Joined: Wed Jul 24, 2002 4:53 pm
Contact:

Dont believe vote fair

Post by CMP »

It didnt go out to everyone.. I didnt know it was even happening until it appeared on the mainpage.

I can't use AlphaMame, my computer crashes anytime it starts up, and if ur going to religate my play to be a 2nd class citizen, why even worry about remaining posting to MARP?
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

cmp, see other threads about alphamame on that...or e-mail Barry about it. I remember him saying something about an ini folder or file you need to remove/create.

I play in a mac so didn't jot down the details.

...hope that helps.
User avatar
Chad
Tournament Coordinator
Posts: 4463
Joined: Tue Mar 05, 2002 3:15 pm
Location: calif

Post by Chad »

CMP: check this out

viewtopic.php?p=17401#17401


Alphamame is VERY similar to regular mame so if regular mame works there's not a lot of reasons why alphamame wouldn't, there is even official, dos, mame32 alphamame versions that use the same code as the regular mame's do. We want your play at marp! But we also want anyone who is trying to cheat to beat your scores to be forced to use alphamame as well to keep everyone at the top a 1rst class citizen.
-skito
User avatar
gameguru
Button Masher
Button Masher
Posts: 49
Joined: Wed Mar 06, 2002 1:18 pm
Location: Bristol UK
Contact:

eh?

Post by gameguru »

I have been here for around 4 years now and I have submitted loads of scores. Am I assuming that these scores are no longer valid?

If this is the case god help people like BBH??? :-(

????

GG
"Life Is Short, Play MAME!"
Post Reply