What's new
By:
Filters

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

saturnnights said:
bootstrapping a sega ringedge to see what i can reverse-engineer of ALL.net for potential simulation of that network [think programmed sun/programmed world for konami/bemani, if you're in the know]
Click to expand...
that would be amazing....
 
I just purchased a card reader unit for ID4/5 on Lindbergh. It's the same reader as 6-8, but I don't have a Ringedge to play with at the moment.

I'm in the process of trying to confirm that it works and hope to get some good logs for attempting to make an emulator.

I noticed the test menu tests are very forgiving about not replying to commands. In fact, the Mario Kart card emulator can get through a lot of the tests. I'm seeing some new commands and will have to get a good understanding of the data read/write commands, but hopefully can get something working.

I also successfully got ID4 booting with the emulator and got to the point where it wanted me to insert a card or start a new game, but I was just running it on the bench with no controls wired up, so couldn't see how far it would let me go before giving an error.
 
I'm happy to report that I've got something in the way of a working card reader unit for ID 4 and 5. After a lot of frustrating experiences in the test menu and the discovery that I bought a card reader that's not actually the one used for these games, @android suggested in another thread that the test menu will fail print tests, but will probably work in game, which happened to be the case for me. Big thanks to @android for the information and the logs posted above!

Also thanks go out to @freddiefiasco for donating a few cards to me for experimentation.
 
I started logging the communication for the card tests in the test menu and for one card that I have working in-game with ID5.

I have a pretty good grasp of the protocol and how the data is read and written, but there is a specific CMD that gets some different ACKs dependent on card that I haven't been able to figure out yet.

Even a blank card comes with some built in header data that looks like it would make each card unique, though I don't have enough multiples of the same type of card to tell.

There's a back and forth that establishes what looks like a unique ID code per card and some kind of authentication process (helpfully pointed out in android's analysis posted above). I can see where the ID code comes from in the card data, so I hopefully can reference an existing card to get data for emulation purposes. I am curious if the game cares or even tracks if there are duplicate codes being used from different cards.

For the unique ACKs for the CMD I can't figure out - I'm wondering if I can get away with spoofing the same card ID every time and maybe those ACKs are unique to the card I'm spoofing every time.

I'm also planning to write a script to blank out a card for reuse. I had used a card for test read/write and now the game won't allow it to be loaded back into the stocker and reused in game. The game loads a card and then reads it before allowing it to be used, so it will have to be blanked out and there aren't any test menu options for doing so. Being able to blank out a card will let me see more logs of what happens when a new card is purchased.
 
freddiefiasco said:
Does that unique ID match the card ID on the back of the cards?
Click to expand...
I'm not seeing a correlation, but that does not mean a correlation does not exist.

For example:
The ID code for one of my cards is:
80 51 F6 6B
The code on the back is:
0101 0320 3404 8482 3333

I wasn't on my computer when I was referencing the CMD that I can't figure out.
It's the ones that start with:
02 09 D1 00 00 00 6D

The three examples I see in my logs are:
02 09 D1 00 00 00 6D 00 03 03 B5
02 09 D1 00 00 00 6D 00 30 03 86
02 09 D1 00 00 00 6D 00 C0 03 76

Replies seem to be unique per card in one of the reply bytes, but I can't figure out a correlation between the command and any data stored on the card. I honestly don't even know if it's more of a status or some kind of data being retrieved off of the card. I'm not sure if the game really even cares what the ACK is, but I won't know until I get further into coding the emulator.

D1 so far is a difficult command to categorize. It's the same command code used to read data, set the mark for where data should be written, and write the data. I can only tell what it's wanting to do by seeing the entire command.

02 09 D1 00 00 00 8D 00 XX 03 CRC - CMD to set XX position to write
02 0F D1 00 00 00 CD XX XX XX XX XX XX XX XX 03 CRC - CMD to write 8 specified bytes to position set in previous CMD. (Note that the reader iterates the position automatically so sequential write commands can come one after the other without specifying a position each time.)
02 0F D1 00 00 00 4D 00 00 00 00 00 00 00 00 03 90 - CMD to get ID Code
02 09 D1 00 00 00 0D 00 XX 03 CRC - CMD to get 128 bytes of data from XX position

What's odd to me is that the data seems to be written in 8 byte chunks, but it gets read in 128 byte chunks. The commands used to write data for Initial D3 and Maximum Tune write out the entire chunk of necessary data all in one command. The nature of the protocol would limit the reply to FF bytes, and the cards used in ID4-8 have a larger capacity than the older versions, but it seems like the protocol could have handled writing data in larger chunks.
 
Last edited:
I should have given you a mime card to test out as well. I'm wondering if the replies are unique per 'type' of card and not necessarily per card itself. You mentioned using the ID4 and ID5 cards right? Does the reply match the same pattern as the ID8 card?
 
you have to understood - ID1-3 and ID4-8 readers uses completely different technology.
ID3 uses magnetic cards, which access handled fully by reader itself.
ID4 and later uses RF cards, access via ME-MA21-A-SNT RF card reader, located inside of whole reader case. so its like "device inside device", high likely connected via serial port to "main reader" board.

command D1 seems to be simple "transfer data to/from serial port" connected to RFID card reader.
so "main reader" doesn't know what data is in D1 command, it just pass them to RF device.

these data is RF reader commands (6D, CD, 4D, etc), and you have to understand them.
it somewhat like "door to another Narnia" :D
 
hmm, the funny part - protocol look similar (but not same) as Maxell ME-PM01-RA-SG reader used in Mushiking/Dinoking games.

here is it's commands:

5E xx xx
TEST
reply: 0A (OK)

4E
REQuest RF tag serial number
reply: 0A (OK), then 4 bytes SN#

2E ss ss ss ss pp pp pp pp
SEL - authentication, input - SN#, password
reply: 0A (OK)

0E
READ
reply: 0A (OK) followed by 128 bytes of data

6E nn
COUNTer decrement
reply: 0A (OK), counter value

EE 00 00 00 00
WRITE_STart (reset write pointer to 0)
reply: 0A (OK)

CE xx xx xx xx
WRITE data (4 bytes)
reply: 0A (OK)

8E 00 00 00 00
WRITE_NOP (skip 4 bytes)
reply: 0A (OK)
 
freddiefiasco said:
I should have given you a mime card to test out as well. I'm wondering if the replies are unique per 'type' of card and not necessarily per card itself. You mentioned using the ID4 and ID5 cards right? Does the reply match the same pattern as the ID8 card?
Click to expand...
The command in question only comes in the logs for cards being written to, so I don't have a good variety of logs to compare and don't want to potentially waste some cards on the test write option.

It appears that the game only reads the header to identify if the card is blank and usable, so I will need to determine if I can rewrite the header to reuse a card in-game and I will be more comfortable doing one off tests without fear of wasting a card.

My hope at the moment is that I will be able to get away with establishing a usable header for an emulated card that is based off of a blank real card, and I can hopefully get away with sending the same ACKs seen in logs from that reference card. That is assuming that the CMDs in question always get the same reply from the same card... and assuming that the game even cares about the content of the ACK.
 
Just for reference, here are some ACKs to the 6D command:
CMD: 02 09 D1 00 00 00 6D 00 30 03 86
ACK from card 1: 02 09 D1 63 30 30 4B FF E8 03 E4
ACK from card 2: 02 09 D1 63 30 30 4B FF EC 03 E0
ACK from Android's log: 02 09 D1 43 30 30 4B FF E5 03 C9

CMD: 02 09 D1 00 00 00 6D 00 C0 03 76
ACK from card 1: 02 09 D1 63 30 30 4B FF E8 03 E4
ACK from card 2: 02 09 D1 63 30 30 4B FF EC 03 E0
ACK from Android's log: 02 09 D1 43 30 30 4B FF E5 03 C9
(same ACKs as above CMD)

CMD: 02 09 D1 00 00 00 6D 00 03 03 B5
ACK from card 1: 02 09 D1 63 30 30 4B FF EE 03 E2
Command only shows up in logs for card used in-game. Only have one card log to reference at the moment.
 
MetalliC said:
these data is RF reader commands (6D, CD, 4D, etc), and you have to understand them.
it somewhat like "door to another Narnia" :D
Click to expand...
I like this explanation. :)


winteriscoming said:
The command in question only comes in the logs for cards being written to, so I don't have a good variety of logs to compare and don't want to potentially waste some cards on the test write option.
Click to expand...
Oh my mistake, I thought the questionable command also appeared during reads. Can you potentially send the write command multiple times to the same card in the same session? In other words, if you send a write command, over and over until you send the reply OK command? If so, I'm wondering if you can just use that same write session to test on the same card before end of card write.

The way i'm interpreting it (based on the similarities of the SG card reader):

EE 00 00 00 00
OA
CE xx xx xx xx (first write attempt)
OA
EE 00 00 00 00 (reset print position)

OA
CE xx xx xx xx (second write attempt)
OA
8E 00 00 00 00 (end of card write session)
OA

I feel like if you can overwrite proceeding sessions, the log would have multiple write sessions to analyze. Sorry if i'm not making any sense, @MetalliCs reply got me wondering what each Send/Receive is actually doing. And with the ID check, if that part is necessary between each sequence or if it is only per initiation of the write command.
 
winteriscoming said:
Command only shows up in logs for card used in-game. Only have one card log to reference at the moment.
Click to expand...
let me guess, each log or test have different replies from these commands ? ;)
I'd bet 6D is much similar to counter decrement 6E from my doc, but in ID4 reader it works with 16bit data, located in your RF card at 0x30 - 0x3f area, as big endian 16bit numbers.
number/offset of counter determined by some pair bits of command argument == 1

6D 00 C0 - this will decrement 16bit counter at 0x30 - 0x31 (unless it is 0) and return resulting value
6D 00 30 - same but for 0x32-0x33 counter
6D 00 0C - same but 0x34-0x35
and so on
 
freddiefiasco said:
Oh my mistake, I thought the questionable command also appeared during reads. Can you potentially send the write command multiple times to the same card in the same session? In other words, if you send a write command, over and over until you send the reply OK command? If so, I'm wondering if you can just use that same write session to test on the same card before end of card write.
Click to expand...
I haven't done any write tests with my own code yet. It appears that the game will initiate the authentication procedure at the beginning of read/write, even multiple times in the same session. One of the commands may be an end command, requiring authentication to read/write again. There are some commands that get the same reply, regardless of card:

CMD: 02 07 D1 00 00 00 28 03 FD - unknown command - always same reply no matter which card
ACK: 02 07 D1 63 30 30 0A 03 BC

CMD:02 07 D1 00 00 00 F7 03 22 - unknown command - always same reply no matter which card
ACK:02 07 D1 63 30 30 0A 03 BC

CMD:02 07 D1 00 00 00 48 03 9D - unknown command - always same reply no matter which card
ACK:02 08 D1 63 30 30 1A 40 03 E3

CMD:02 07 D1 00 00 00 38 03 ED - unknown command - always same reply no matter which card
ACK:02 07 D1 63 30 30 0A 03 BC

The nice thing about an emulator, though, is if it's always the same ACK for a given CMD, I don't actually have to know what it means if it isn't impacting data that is read or written. I just need the game to see an expected ACK so that it won't error out.

It's those variable ACKs I'm not sure of, which could end up complicating this.

From the perspective of using a script to write to the cards, that gets a little tricky. I was thinking I would just use the authentication commands found in the logs for the given card I want to blank out. I have no idea how the game is reading the ID and generating an authentication code. It's probably some kind of algorithm I won't be able to figure out, so I will only be able to rewrite cards where I can see logs to get the auth code, which is fine for my purposes, but I likley won't be able to release any kind of useful script that others could use.

Examples:
ID code - Generated Authentication Code
80 51 F6 6B - 9B A4 5D FF
81 2C 63 BC - 98 58 25 EE
80 48 70 82 - 48 77 B6 04
81 42 41 48 - 5B 54 C4 04
 
winteriscoming said:
The nice thing about an emulator, though, is if it's always the same ACK for a given CMD, I don't actually have to know what it means if it isn't impacting data that is read or written. I just need the game to see an expected ACK so that it won't error out.
Click to expand...
I'm sorry, but if your script/software just REQ/ACK selector it is not emulator ;)
 
MetalliC said:
winteriscoming said:
Command only shows up in logs for card used in-game. Only have one card log to reference at the moment.
Click to expand...
let me guess, each log or test have different replies from these commands ? ;) I'd bet 6D is much similar to counter decrement 6E from my doc, but in ID4 reader it works with 16bit data, located in your RF card at 0x30 - 0x3f area, as big endian 16bit numbers.
number/offset of counter determined by some pair bits of command argument == 1

6D 00 C0 - this will decrement 16bit counter at 0x30 - 0x31 (unless it is 0) and return resulting value
6D 00 30 - same but for 0x32-0x33 counter
6D 00 0C - same but 0x34-0x35
and so on
Click to expand...
I tell you what! You're the key to unlocking every mystery I come across in these card reader emulator projects!

I think you've got it figured out.

I'm curious though how you read the CMD variable and get the address from it? Like how does C0 translate to x30-x31, 30 translates to x32-x33, etc?

Here's the entire 128 byte header (0x00-0x80 as read from on of my cards with the 0x30-0x31 highlighted:
03 36 00 01 80 51 F6 6B
F7 04 08 43 02 8E 02 89
42 4D 4C 20 00 00 00 00
00 00 00 00 00 00 00 00
FF FF FF FF FF FF 17 FF
00 00 00 00 00 14 7E 17
FF ED FF ED FF F0 FF EF
FF FF FF FF FF FF FF FF
01 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
10 52 00 F0 FF FF FF FF
35 00 01 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

On this card, the stored value was FF ED at the time. If it were decremented, it would report FF EC like seen in one of the ACKs posted above!

This leads me to wonder if I could just not decrement the values on an emulated card, and not have to worry about an expiring card.

I wonder how much validation of the data there is in the game, though. The game seems to read the header data in every time it authenticates for read/write, so I wonder if it it does some secondary validation of the decremented values by comparing them to what it knows was the previous state.
 
Looking at header data read from blank cards for various Initial D versions, I'm not seeing much difference. It may not even identify the game version.

I do see ASCII values of "InitialD" followed by hex 'AA', but that seems to stay consistent across all versions of cards I have. I wonder if something is different here with the US ID4 cards (waiting to receive some) and something about them makes the JP games refuse the US cards.

Since ID5 does not complain about an JP ID card, it may not have any means of knowing what version the card is to be able to know if it's the correct card. I would be curious to know if ID 6-8 can use have cards interchanged without complaint from the game.

Edit: Interesting! The values that store "InitialD" get zeroed out when the card is written... Not sure why... ?(
 
You must log in or register to reply here.
Back
Top