AlphaMAME 0.63

General discussion on MAME, MARP, or whatever else that doesn't belong in any of the other forums

Moderators: mahlemiut, seymour, QRS

User avatar
mahlemiut
Editor
Posts: 4191
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

AlphaMAME 0.63

Post by mahlemiut »

http://mahlemiut.marpirc.net/alphamame-063-1.zip

- Added an average speed output, shown in the console after playback. (Skito's idea)

- Still have to add the sound fix for Sokonuke Taisen Game, as it's STILL not in MAME.

- And, of course, the Cave shooter 'fix'.


Update on other ports:
DOS - When I can be arsed to download the 14MB that is GCC 3.2 for DJGPP.
MAME32 - When they decide to host the source somewhere less crappy than Fileplanet.
Unix/Linux - When they get their act together for a somewhat stable version. :)
- Barry Rodewald
MARP Assistant Web Maintainer
Image
User avatar
mahlemiut
Editor
Posts: 4191
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Post by mahlemiut »

Update: Barthax sent me the MAME32 source, and it appears that no source changes are required at all.

I'll probably upload a version tomorrow sometime.
- Barry Rodewald
MARP Assistant Web Maintainer
Image
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

does alphamame have a lot of assembly code in it or is it like xmame so entirely c/c++ or perhaps almost entirely c/c++?

I ask cuz if almost all c/c++ or at least the "security" added is something that can fairly easily be integrated with the xmame code then perhaps an xmame version of alphamame could be done.

Then we would have a secure version of mame for linux and users like me using mac os x...cuz porting xmame to mac os x is fairly trivial now that Apple has released their own X11 for os x. It just requires remaking xmame in os x...done.

of course the performance of xmame isn't as great as optimized versions with assembly code, but still likely would perform well enough for most of the golden age classic arcade games like the pacman-type games.

I personally would like to see a secure version for MacOS so there is no question at all about any scores....and where if the above as done pretty sure the resulting encrypted inp files from xalphamame would be totally compatible with the macos x port encrypted inp files.
User avatar
mahlemiut
Editor
Posts: 4191
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Post by mahlemiut »

It's the same as the standard MAME, so it uses the ASM 68000 core.

I can release the source for everything but the encryption (which I'll probably do soon), so it could be possible to compile your own if you add your own encryption method, although that would only make it viewable on that particular version.

Generally, on today's PCs, the speed difference between ASM and C is not so noticable. Unless you're BBH, that is. :) I just use the ASM 68000 core in XMAME to maintain compatibility with DOS/Win32 MAME INPs.

I would assume that, if Mac OS X uses GCC to compile XMAME, then INPs produced by it should run on a DOS/Win32 version compiled with the C 68000 core.
- Barry Rodewald
MARP Assistant Web Maintainer
Image
User avatar
mahlemiut
Editor
Posts: 4191
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Post by mahlemiut »

http://mahlemiut.marpirc.net/alphamame32-063-1.zip

'Nuff said. Just remember that you still have to watch out for NVRAM.
- Barry Rodewald
MARP Assistant Web Maintainer
Image
User avatar
mahlemiut
Editor
Posts: 4191
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Post by mahlemiut »

http://mahlemiut.marpirc.net/alphamame-src-063-1.zip

And the source (minus encryption).
- Barry Rodewald
MARP Assistant Web Maintainer
Image
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

mame32 Alphamame

Post by Mr. Kelly R. Flewin »

Woohoo! Thank you very much Barry for making a Mame32 version [even with that lovely NVRam bs which you couldn't do anything about] :)

Now... to figure out more about Fanmame and those lovely games that only appear in there... Pong Highscores anyone? ;) [KIDDING!! It'd prolly be zero'd right away anyways :)
Just a gaming junkie looking for his next High Score fix.
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

mahlemiut wrote:It's the same as the standard MAME, so it uses the ASM 68000 core.

I can release the source for everything but the encryption (which I'll probably do soon), so it could be possible to compile your own if you add your own encryption method, although that would only make it viewable on that particular version.
I can totally understand not wanting to release the encryption code publically but if there was actually going to be a mac version of alphamame then whoever develops that for mac should be able to use that same encryption code.

If you don't then you have totally isolated those playing on macs where no recordings on the mac would be playable on the pc version even for games where the inp files themselves are cross-platform compatible.

Also, thought of another approach...can't you have a system where you have the raw inp file as we have now with regular mames but then with alphamame a separate file is generated that is encrypted etc. that alphamame uses to confirm the inp file is untouched. If the inp file has been changed at all, then the data in the encryption wouldn't verify it and would notify the user. That way you still would be able to get the great compression of the inp and just include the 50-100k type encryption data file that would be needed to verify the inp wasn't hacked as well as it containing other pertinent info like what the average frame rate of recording was etc.

Also, in that case you can still share the inps cross-platform and view them. You just wouldn't be able to verify it wans't hacked on the other platforms.
User avatar
Chad
Tournament Coordinator
Posts: 4463
Joined: Tue Mar 05, 2002 3:15 pm
Location: calif

Post by Chad »

that's a good idea, you could encrypt a 64 bit crc of the unencrypted frame and the speed of each frame in a separate file. This would be able to have a stronger encryption with less compression, but that doesn't help you with mac os. You'd still have to put the encryption INTO alphamame (that needs to make the encrypted crc file while you play) which you'd have to have a mac version of.

It's not like alphamame is a commercial product that is trying to include/exclude/isolate certain operating systems for profitable reasons. Barry's put a serious portion of work into alphamame and he's not getting a buffalo nickel for it. If macmame source is not available to him or someone else he can trust to compile it, it just won't happen.

We want to cator to as many os'es as we can but we have to be carefull not to let the encryption out or alphamame would be worthless.

What barry could do, depending on if the encryption supports a 'key' (which i'm not sure if it does or not) is release the encryption source but NOT release the key for encrypting the dos/mame32/xmame inps, and someone else could maintain the owner of the mac key that they would compile an alphamame mac version. The two versions would be incompatible (not like they are with regular mame!) but the trusted mac person would not be able to comprimise barry's alphamame and barry or no one else would be able to comprimise the alphamacmame because they have different keys. The bad news is i don't think the encryption chosen for the current alpha mame supports encryption keys...
-skito
User avatar
Barthax
MARP Seer
MARP Seer
Posts: 691
Joined: Fri Sep 27, 2002 1:13 pm
Contact:

Post by Barthax »

There's a problem with releasing the encryption code for any of the platforms. If the code is released, the knowledge of how to work around to get a cheated inp into AlphaMAME spec inp would become public (even if few MARPers could figure it out). If ports are to be made, then the encryption code must be retained privately - communicating it between porting parties only.
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

Barthax, I totally agree if the code was leaked out and doesn't have a key. Unix encryption like for user accounts is destructive so even if you have the source for thouse routines you are clueless about what the passwords for accounts are etc. You need the "key" for each account...which is different for each account. It seems alphamame could use the same kind of system for each inp file. You have the inp file separate but then the verification file that's encrypted and requires the key to actually verify. alphamame would report the key to the user or save it to some key.text file when the recording is complete. You then only give the key for verification of that inp to the tournament director or confirmer etc...key not included with your MARP submission upload. It still allows total playback of the inp without needing the key. The key would only be for confirmation of the encrypted data file that has info to verify the inp file is authentic and was played at an accceptable speed etc. In most cases the inp playback isn't suspect so you wouldn't even really need the confirmation.

Chad, I realize you would still have the other issues of the encryption not being cross-platform if Barry wasn't willing to release the code to anyone which is understandable given there is no key. Most people can be trusted though where if they are taking on a huge project like porting alphamame to another OS they aren't going to release code they aren't allowed to release otherwise they wouldn't get the code for that for any future updates which makes their project mostly a large waste of time.

Does alphamame support dynamic frameskipping? If so I would think it would be easier if it didn't. If you only allow a fixed value at the start of the game then it's much easier to verify speed etc. cuz you have the avg fps and the total #frames so can get the average speed of the game knowing the exact frameskip. If frameskip is dynamic then that calculation gets tons more difficult as well as requiring recording more information...like having a byte added to each frame in the input that is the frameskip value.

In summary though it's sad all this type of crap to the level of data encryption has to be done. I guess cheating among pc-gamers is fairly large scale cuz you see cheats released for just about all pc games where then updates to the games are made to disable those cheats...but then new cheats are made....it's a stupid war! Real gamers don't need cheats at all. If you are going to cheat then why play games?

In the macgaming community hacks of games to allow cheats is almost nonexistent.
User avatar
Chad
Tournament Coordinator
Posts: 4463
Joined: Tue Mar 05, 2002 3:15 pm
Location: calif

Post by Chad »

One of the reason key's weren't used with alphamame is that when you use keys you have already "conceded" to strong encryption and thus you will pay with computational time and slowing down the gameplay even more. And no you would not report the key to the user, because if key's were used with our inp form of encryption revealing the key would be like releasing the encrypted source and any use could use that key to make a slowded down inp and then they would encrypt the inp like an alphamame one with the known key, NO! The key's would have to be in the exectuable and difficult to extract from the exe (just like the encryption instructions are right now in alphamame.exe). The good thing about key's is that anyone could compile a version of mame with a key known only to them and no one else would know how to hack that version. So in theory the encryption source COULD be released with only the key withheld. This way the developers of alphamame could use an alphamame with a different key and be proven to have not hacked the version they developed.

#1 keys would slowdown alphamame, #2 the Keys would not be public knowledge, and #3 the keys should be large enough not to be able to be hacked by enumeration. The only good thing is that keys would allow you to have multiple tiers of trust, you could even have a different key for a different os or tournament or mame version.

LN2: it's not all trust that's an issue, there's also the weakest chain in the link theory. The more people that have it no matter how cautions everyone is, the more chance it is for someone to accidentally copy it on a gnutella folder on their hard drive for someone else to grab. Also, I'm not sure how having a separate file helps the encryption, it'll help compressing the whole of the strongly encrypted inp file but it really has nothing to do with making it much more or less secure.
-skito
LN2
MARPaholic
MARPaholic
Posts: 1669
Joined: Wed Jul 24, 2002 4:46 pm

Post by LN2 »

Chad wrote:And no you would not report the key to the user, because if key's were used with our inp form of encryption revealing the key would be like releasing the encrypted source and any use could use that key to make a slowded down inp and then they would encrypt the inp like an alphamame one with the known key, NO!
I wasn't using "key" in that manner.

I was thinking about games that had contests in the past spit out some verification 20-30 character code after the game is over that you send in to the publisher and from that they can verify if the score was authentic or not.

Instead of having some high level encryption for the inp file which would burn up more cpu as the encryption method used is more complex, just save the inp file as regular mames do but then just generate a separate file to use for verification. That small verification file since it isn't very large could use higher level encryptions without really sacrificing the game performance cuz it could even be something that is done when the game ends that you must press some key before quitting that game's emulation that triggers to stop the inp recording and then do that function call to generate that other file for verification.

You could even get really fancy where part of that puzzle is done online where a http call is done and the server does some "stuff" then sends back a code. This way some "unknown" would be occurring at the web site in some perl script or php etc. that wouldn't be known to anyone except mahlemiut.

Then he could have a PC exe that he distributes without any source where confirmers can check that submitted code for verification.

The downside to that is you must be online ...which given we are submitting our scores online should be a given for almost all so I wouldn't see a problem there.

This way given part of the code is at some remote web site it would allow this process to work for all platforms....instead of trying to include all of it in an exe as the source code of alphamame wouldn't have all the pieces of the puzzle.

That kind of system would be even more secure than any exe released even without source where some hacker could disassemble it and perhaps figure it out.

If you happened to not be online when alphamame was finishing a game and/or failed to contact the web site then it could give you a "keycode" file that you submit with your zipped inp to the web site when it is back online or you are online to a form at the site. Given the server is doing something to generate a verification code that is totally unknown to the player, there would be no way to crack the system without knowing what that code on the website is doing.

That seems like the most secure system possible.
User avatar
Barthax
MARP Seer
MARP Seer
Posts: 691
Joined: Fri Sep 27, 2002 1:13 pm
Contact:

Post by Barthax »

LN2: yeah that kind of stuff is already used in PGP for e-mail... you're basically referring to signing the inp. Basic concept: after the file is recorded, take a digest of the inp (MD5, SHA1, or other high-level Hash), then encrypt that hash value with the public key. This could easily be appended to the original inp for verification (no requirement for another file), and would not impose any significant compression degredation. All that remains then is for the private key to remain secret - and that would not need to be in the .exe (it should *not* be in the .exe!).
User avatar
mahlemiut
Editor
Posts: 4191
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Post by mahlemiut »

http://mahlemiut.marpirc.net/alphamamedos-063-1.zip

DOS version. :)

http://mahlemiut.marpirc.net/alphamame-src-063-1.zip

Source updated too, now includes the changes needed for DOS.
- Barry Rodewald
MARP Assistant Web Maintainer
Image
Post Reply