What's new
By:
Filters

NAOMI 2/Chihiro/Triforce Card Reader Emulator (Initial D3/WMMT/Mario Kart/F-ZERO AX)

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.
 
AbolishedEnigma said:
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?

​

Click to expand...
Assuming this is the card reader for WMMT2 - yep, I do.
 
this? ( that's WM3)
IMG_3937.jpg
 
WMMT 1/2 card reader is CRP-1231LR-10NAB
 
hopeajonne said:
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.
Click to expand...
Thanks again for your commits and giving my project a chance to see real world use :)
 
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:
1668114397854.png

(red box is unknown territory)

And SugoiDeCard's approximation of it for purposes of replacing paper cards with IC cards looks like this:
1668114451541.png


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.
 
hopeajonne said:
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.
Click to expand...
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).
 
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
 

Attachments

  • after-race.card.txt
    6 KB · Views: 85
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...
 
hopeajonne said:
oooooooooooh nice, is there source for it anywhere?
Click to expand...
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:
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.
 
whatnot said:
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).
Click to expand...
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.
 
hopeajonne said:
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.
Click to expand...
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 :P

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.
 
Thank you a lot!! I will take a look into that and try to incorporate parts of it into a JS library. Fixing overhaul to 60 might be an option but on the other hand unlocking new colors is tied to card renewal, so maybe it's better to do the opposite and reduce maximum of it to 30 or so so that people can get new colors faster, and when all colors are unlocked just lock it to 60.

Also, for any arcade operators out there that have real cards and real readers - you can re-use disused cards by just sticking em into dispenser like they're new - real game doesn't care what's on the "blank" card when it's dispensed. Manual doesn't mention this at all from what I know.
 
happy to report that most recent version of SugoiDeCard worked fine almost entire day at local gamecenter seemingly without crashing

unhappy to report that i was the only one who used cards on it during that day ;(

at least i gave the owner the rpi3 image and most of the equipment so that it can be made working. LCD display had some weird issues but I blame my lousy cabling/crimping although it wasn't an issue last time, could be that PSU is issue, rpis are kinda capricious in that regards.

aime still works like fucking shit on it though honestly, but i had similar experience at home - first time it works fine, but later just never gets detected despite ACR122 beeping nonstop on it. I probäbly need to disable the automatics on it and manually read the UID of the card (thanks sony??)

I will update the repo for SugoiDeCard with more info soon.

Also, it starts YACardEmu on by itself now, it creates temporary dir and writes a config file into it, then launches YACE with CWD in it, works like a charm but YACE's web ui becomes inaccessible (predictably). Since I start it myself i could possibly just read its stdout to monitor shit instead of polling HTTP but i dunno, i'd still prefer a WS API.
 
Small update: ACR1252U reader (basically, same thing as ACR122 but black) works with FeliCa (Aime) out of box way way better than ACR122
 
Been working on some interesting stuff recently, as part of his work on Dolphin Triforce emulation crediar has uncovered and published the decryption method for F-Zero AX card save data and I've spent the last couple of weeks working out how some of the card data is encoded and how to update it to change name, pilot, ship parts (including the exclusive gold ones) and wind back the usage counter. I've been documenting it as I've gone along and hopefully soon should have it all worked out, will publish on a separate thread.
 
You must log in or register to reply here.
Back
Top