djturbolence
Beginner
I just had someone build me one. About $500 or so shipped. Arrives in a week or two
- Thread starter winteriscoming
- Start date
-
- Tags
- card reader id3 initial d3 naomi 2
seventhbigsmoke
Student
Geez that's almost as much as the damn machine lol. I feel like it shouldn't be to hard is there software in the og server or is it just a router??
djturbolence
Beginner
I have ID8s, paid a bit for them and shipped them to Hawaii. $500 seems worth compared to what I pay. For me it’s an a thaly ring edge and a router. Probably why it costs as much as it does.
seventhbigsmoke
Student
Hmm i wonder if someone could dump the drive that's in that ringedge and found out what's in that drive and be able to make an easier and cheaper solution. There obviously getting the software to make a ringedge work as an server but where is it coming from?? Well never know yet lol
AbolishedEnigma
Student
While I apologize that this is likely not the place to ask, but does anyone in here still monitoring the thread happen to have an old Sanwa Newtec CRP-1231 AR-10 card reader/writer laying around?
hopeajonne
Beginner
Hey, I'm also making an NFC replacement thing here https://git.shigusegubu.club/HJ/SugoiDeCard work in progress
I'm however not doing any emulation and instead the tool interfaces with YACardEmu https://github.com/GXTX/YACardEmu via API I contributed there, although I still wish it had websocket API, but I'm not even remotely good at C++ and reimplementing it feels like a waste.
I have two NFC readers - GHI NC001 and ACR122U-A, former however does not work with aime (sony FeliCa) cards, and latter seems to be working but I had issues that i still need to investigate.
I'm however not doing any emulation and instead the tool interfaces with YACardEmu https://github.com/GXTX/YACardEmu via API I contributed there, although I still wish it had websocket API, but I'm not even remotely good at C++ and reimplementing it feels like a waste.
I have two NFC readers - GHI NC001 and ACR122U-A, former however does not work with aime (sony FeliCa) cards, and latter seems to be working but I had issues that i still need to investigate.
mathewbeall
Champion
Assuming this is the card reader for WMMT2 - yep, I do.
Thanks again for your commits and giving my project a chance to see real world use
hopeajonne
Beginner
SugoiDeCard updated, I pretty much rewrote the entire thing to utilize a state machine and events, no more awful spaghetti code (mostly), and so far it's working fine in about 70% scenarios.
State machine is used to approximate game's state using two types of events - shutter events (opened/closed) and card events (inserted-dispensed/ejected)
WMMT3's state machine looks like this:
(red box is unknown territory)
And SugoiDeCard's approximation of it for purposes of replacing paper cards with IC cards looks like this:
Essentially, it will only read cards when game is at "Do you have a card?" screen, for registered (known) cards it will just command YACardEmu to insert the card, if card is unregistered (unknown/new) it will just tell YACardEmu to load new card without "inserting" it, which will cause newly dispensed card to be written into it, if no new card is dispensed it defaults back to a "dummy" one. Dummy card is also used when user didn't scan the card but chose to "purchase" new one nonetheless, in this case data will be lost. In case of "real" guest play (i.e. "no card" -> "no purchase") SugoiDeCard just drops back to idle.
For main part this works... fine, but if you enter service menu from login screen ("do you have a card?") then shutter supposedly will remain open until you leave the service menu and it trips up SugoDeCard a bit, maybe code for reporting shutter state needs to be updated in YACardEmu, idk. Going to service menu while game waits to check for renewal also can trip it up. I'm thinking about having a physical button next to screen (or in service closet/door/whatever its called) just to reset the management software and potentially for better feature completeness, i.e. multiple people at the gamecenter already asked me to add multiple profiles per card feature...
I also wonder if anyone tried YACardEmu with other games (F-Zero AX, Mario Kart) and if those games have same/similar state machine when it comes to cards.
State machine is used to approximate game's state using two types of events - shutter events (opened/closed) and card events (inserted-dispensed/ejected)
WMMT3's state machine looks like this:
(red box is unknown territory)
And SugoiDeCard's approximation of it for purposes of replacing paper cards with IC cards looks like this:
Essentially, it will only read cards when game is at "Do you have a card?" screen, for registered (known) cards it will just command YACardEmu to insert the card, if card is unregistered (unknown/new) it will just tell YACardEmu to load new card without "inserting" it, which will cause newly dispensed card to be written into it, if no new card is dispensed it defaults back to a "dummy" one. Dummy card is also used when user didn't scan the card but chose to "purchase" new one nonetheless, in this case data will be lost. In case of "real" guest play (i.e. "no card" -> "no purchase") SugoiDeCard just drops back to idle.
For main part this works... fine, but if you enter service menu from login screen ("do you have a card?") then shutter supposedly will remain open until you leave the service menu and it trips up SugoDeCard a bit, maybe code for reporting shutter state needs to be updated in YACardEmu, idk. Going to service menu while game waits to check for renewal also can trip it up. I'm thinking about having a physical button next to screen (or in service closet/door/whatever its called) just to reset the management software and potentially for better feature completeness, i.e. multiple people at the gamecenter already asked me to add multiple profiles per card feature...
I also wonder if anyone tried YACardEmu with other games (F-Zero AX, Mario Kart) and if those games have same/similar state machine when it comes to cards.
chunksin and Bobby Dilly complained about F-Zero but neither would really troubleshoot with me and I haven't been able to get anyone else to test since, but I'm pretty sure I fixed the issue they were running into. The game heavily utilizes the custom font functionality and previously I was doing "fake processing" on the command which caused it to need to spit out multiple status commands per font (aka icon) so the boot process would be lengthy and the game didn't like it. Otherwise it should just work(tm), both for F-Zero and Mario Kart (Mario assuming it's the same baud rate, would need a confirm there).
hopeajonne
Beginner
speaking of cards, I had some more insights on WMMT3's cards format:
There three 69-byte (nice!) tracks on the card, track_0 seem to never change ever (maybe if card is renewed or upgraded?), and all cards always start with first two bytes being 10110110 11011111 (0xB6 0xDF) at least for Maxi3 (which I managed to emulate), i still need to compare those to Maxi3DX+. Additionally, Interesting bit I noticed when emulating - game has card backup feature, i.e. if game was being played with a card but write to card failed it will instead save car data to disk (5 slots for this according to service menu) so that operator can fix the issue, enter the service menu and transfer data to the card again. That save file is a singular file which is track_0+track_1+track_2 back-to-back, dunno if it's significant that it stores it all as a same file or not.
There are also seem to be temporary files that are 336 lines long which seem to be card data in original format, 336 bytes each detailing a bit/byte/word, without what I assume is "comments" (lines starting with `--`) that's 298 lines which is more than 207 (total data storage of card). I'm not entirely sure but data on card might be compressed and/or encrypted. There are lines describing two sets of pad bits and pad bytes, i need to compare those to actual files next time as game only stores this raw format for most recently used card. Attached an example of such file (for card named `ＡＡＡＡＡ`, Maxi3 Export (debug build???)) File is stored in /env/tmp/ and named after-race.card, there are also player.card, before-race.card as well as some other files. If anyone has any ideas about how this is turned into 3*69byte card please let me know, maybe someone has an idea what "mark_", "iv1_dataX_", "iv2_dataX_" and "mac_dataX_" could mean, maybe it could direct us to encryption/compression algorithm used
There three 69-byte (nice!) tracks on the card, track_0 seem to never change ever (maybe if card is renewed or upgraded?), and all cards always start with first two bytes being 10110110 11011111 (0xB6 0xDF) at least for Maxi3 (which I managed to emulate), i still need to compare those to Maxi3DX+. Additionally, Interesting bit I noticed when emulating - game has card backup feature, i.e. if game was being played with a card but write to card failed it will instead save car data to disk (5 slots for this according to service menu) so that operator can fix the issue, enter the service menu and transfer data to the card again. That save file is a singular file which is track_0+track_1+track_2 back-to-back, dunno if it's significant that it stores it all as a same file or not.
There are also seem to be temporary files that are 336 lines long which seem to be card data in original format, 336 bytes each detailing a bit/byte/word, without what I assume is "comments" (lines starting with `--`) that's 298 lines which is more than 207 (total data storage of card). I'm not entirely sure but data on card might be compressed and/or encrypted. There are lines describing two sets of pad bits and pad bytes, i need to compare those to actual files next time as game only stores this raw format for most recently used card. Attached an example of such file (for card named `ＡＡＡＡＡ`, Maxi3 Export (debug build???)) File is stored in /env/tmp/ and named after-race.card, there are also player.card, before-race.card as well as some other files. If anyone has any ideas about how this is turned into 3*69byte card please let me know, maybe someone has an idea what "mark_", "iv1_dataX_", "iv2_dataX_" and "mac_dataX_" could mean, maybe it could direct us to encryption/compression algorithm used
hopeajonne
Beginner
Quick update:
it seems that card data literally starts with unit16 corresponding to mark_ in that text file, followed by 8 int8 values corresponding to iv1_dataX_
that's where correlation ends however. Last time i investigated i couldn't even find any resemblance to player name in the data, which made me believe it's compressed and/or encrypted. There's also pad1_bitX_ where X is 0-4 meaning there's possibility that after certain point data is shifted by 5 bits (more if game stores booleans as bits also) making investigation a bit harder since most stuff wants to skip/shift bytes, not bits, and reading non-octet data is always a pain when using conventional tools.
I know that, I made a JS tool to extract DeusEx dialogues from a .u (UE1) file just to make a shitpost bot...
it seems that card data literally starts with unit16 corresponding to mark_ in that text file, followed by 8 int8 values corresponding to iv1_dataX_
that's where correlation ends however. Last time i investigated i couldn't even find any resemblance to player name in the data, which made me believe it's compressed and/or encrypted. There's also pad1_bitX_ where X is 0-4 meaning there's possibility that after certain point data is shifted by 5 bits (more if game stores booleans as bits also) making investigation a bit harder since most stuff wants to skip/shift bytes, not bits, and reading non-octet data is always a pain when using conventional tools.
I know that, I made a JS tool to extract DeusEx dialogues from a .u (UE1) file just to make a shitpost bot...
derole actually has an editor for MT3 cards. https://derole.co.uk/downloads/MT3CardTools_latest.html
The game when run in Debug mode via TP it actually prints out the entire card structure, then you just need to resign the parts.
I have the MT2 struct that I can share privately.
The game when run in Debug mode via TP it actually prints out the entire card structure, then you just need to resign the parts.
I have the MT2 struct that I can share privately.
Last edited:
hopeajonne
Beginner
oooooooooooh nice, is there source for it anywhere?
Hi there! Was pointed here by @whatnot.
I'd be willing to upload the source to github, however need to make sure its okay to open source first (since I had others help me with certain bits).
In terms of how the format works, youre pretty spot on. The reason track 1 never changes is because its old MT2 data, right after that data region there are 3 seemingly random bytes. These are where the mt2 checksum and end byte lie (for compatability with mt1/2 probably). When generating a card in wmmt3, it uses a PRNG algorithm to fill those 3 bytes (Its especially important you get this right for 3dx+, as it will re encode your card and do a 1:1 comparison of every byte).
If you want to fiddle with the wmmt3 data, you need to decrypt the second data section. You will need to rip some decryption tables from the games executable, these should be pretty obvious once you find the function that decodes the data from the card reader. Theres also a table for generating the MAC signatures as well, as well as for the PRNG algorithm used to pad the data structures. EDIT: I think my tool has a key ripping function, so if you have a game executable for any version it should be able to rip those tables for you
Off the top of my head, you decrypt the 2nd section by grabbing a value from the decrypted 1st section, doing some bitwise operations to it, then using that to grab 8 bytes from the decryption key table to get the key for the 2nd section.
There is no compression, however numbers are packed very tightly, often as just 2-4 bits, so you will need to implement some sort of bit reader and writer class in your language of choice.
Last edited:
hopeajonne
Beginner
That's about what I'd expect, yeah. Unfortunately I have near-zero experience with debugging and reverse-engineering applications, so I'm just glad someone did it at least, not sure if I'll continue on with it - for "IC replacement" looking into card data has pretty limited purposes:
1) Displaying player name on LCD instead/in addition to IC card's UID
2) Checking how many plays remain on card to prepare for renewal more adequately
3) Letting people "cheat" by starting with a better vehicle, i.e. generating present cards for each type of car, unlocking extra content for an old game etc.
None of which are by any means necessary.
Just checked the tool actually, it doesn't seem to work on Wine, but surprisingly works on mono, albeit erroring on every misstep but letting me continue nonetheless. I wonder if i can use keys it extracts as means of help to reverse engineer the rest of the card data myself.
Also I wonder if it's possible to use it to convert japanese cards to export ones, since local arcade switched to export version all old cards stopped working obviously.
1) Displaying player name on LCD instead/in addition to IC card's UID
2) Checking how many plays remain on card to prepare for renewal more adequately
3) Letting people "cheat" by starting with a better vehicle, i.e. generating present cards for each type of car, unlocking extra content for an old game etc.
None of which are by any means necessary.
Just checked the tool actually, it doesn't seem to work on Wine, but surprisingly works on mono, albeit erroring on every misstep but letting me continue nonetheless. I wonder if i can use keys it extracts as means of help to reverse engineer the rest of the card data myself.
Also I wonder if it's possible to use it to convert japanese cards to export ones, since local arcade switched to export version all old cards stopped working obviously.
I didn't get past the compilation stage and can't remember complaining about it, sorry if that was your perception, I was trying to help but the version of Raspbian I was on was a year old and for some reason it wouldn't compile properly. Pretty sure you fixed it but knee deep in my own projects and no time to progress I'm afraid. Sounds like exciting times ahead though, good to see this thread moving again
I've got hardware for each version of ID 1-8 so need to get back onto that at some point.Tool is now open source! https://github.com/derole1/MT3CardTools. Theres already loads of hacked cards that were sold on ebay/facebook floating around so go wild, plus dnspy can decompile the executable with pretty spot on accuracy anyways
Yes the keys are everything you need to decrypt from the game itself. Somewhere in the source (Think its Card.cs) is where the magic happens with decoding, should be able to work out everything from there.
And yes it is possible, in fact the editor has the functionality to do this under the "Extra" menu. Behind the scenes all it does is change the 2 byte mark to the value from the japanese version. The marks for all the versions should also be in the previously mentioned source file. Just make sure you do some basic validation. E.g. ensuring a user doesnt have a gemballa car. Pretty sure title IDs are the same, so they should just appear translated (apart from some japanese exclusive ones that will probably appear blank or with a generic title).
Wish you luck with your project and hope this helps! Overhaul is the card life, so you can force that to 60 at each save and never require a renew.