"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 :)LN2 wrote: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?mahlemiut wrote:You can always bypass that by killing the process before it gets a chance to start encrypting.
AlphaMame Blocking Bonus
Moderator: BBH
-skito
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.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
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.
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.
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.
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.
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.
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.
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
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/kChad 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.
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.Chad wrote:I'm not sure where the users feeling pain
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).
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).
-
Mr. Kelly R. Flewin
- MARP Knight
- Posts: 317
- Joined: Thu Jul 18, 2002 4:59 am
- Location: Somewhere over the Rainbow
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.
Ooooo, is that meant to be Galibert or Belmont?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!"
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
MARP Assistant Web Maintainer
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.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
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.
Dont believe vote fair
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?
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?
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.
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
eh?
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
If this is the case god help people like BBH???
????
GG
"Life Is Short, Play MAME!"