[Tutorial] Creating custom Trainer/Berry e-Cards

[BlackShark]

This guide is for those who are interested in editing an actual trainer/berry e-Card to use with the real e-Reader. If you are capable of save editing or you are playing on an emulator it's probably easier to inject the trainer/berry into your save file directly.

Requirements

• your custom Trainer (ECT) or Berry (ECB) of course (can be created with this tool)
• e-Reader dev tools (https://caitsith2.net/ereader/devtools.htm)
• e-Card headerfix tool headerfix.zip (source)
• a hex editor (like HxD)
• a raw e-Card which we will use as a base (English, Japanese)

 

 

Editing the raw e-Card

1. Decode your raw e-Card with nedcenc like this: nedcenc.exe -i card.raw -d -o card.bin
2. Open the decoded card in your hex editor.
3. Copy the header (the first 83 (0x53) bytes as seen above) and save them for later.
4. Copy and save the VPK (starting at offset 0x53 with "vpk0") into a new file. The full VPK size can be found at offset 0x51. Keep in mind that this is written as little endian, which means if these two byte are "81 07" the actual size is 0x781 (from 0x53-0x7D3). The rest of the decoded card is just padding, you can ignore/delete it for now.
5. You have saved the VPK into a new file, now decompress it with nevpk: nevpk.exe -i trainer.vpk -d -o trainer_decompressed.vpk
6. Open the decompressed VPK in your hex editor.
7.  
   • For trainers: navigate to offset 0xD50, that's where the actual trainer data (ECT) is located, it's 188 (0xBC) bytes.
   • For berries: the data (ECB) is at offset 0x4EA, it's 530 (0x212) bytes.
8.  
   • For trainers: replace the data from 0xD50-0xE0B with your custom trainer and save the file.
   • For berries: replace the data from 0x4EA-0xA19 with your custom berry.
9. Compress your edited VPK with nevpk: nevpk.exe -i mytrainer.vpk -c -o mytrainer_compressed.vpk
10. Note the size of your new compressed VPK!
11. Create a new file in your hex editor and paste the header you have saved earlier in step 3.
12. Paste your compressed VPK right after the header at offset 0x53.
13. Now fix the VPK size at 0x51 to match the new size. Remember to write it as little endian!
14. Fix the size info at 0x26:
    1. in the image above the value is 0x020F0622
    2. bit 9-23 is the same as your VPK size + 2
    3. bits are counted from left to right starting with 0
    4. the original VPK size is 0x781 + 2 = 0x783 or in bits 0000 0111 1000 0011
    5. 0x020F0622 in bits: 0000 0010 0000 1111 0000 0110 0010 0010
    6. convert your new VPK size into bits
    7. replace the bits marked in red in the size info
    8. convert the size info value back into hexadecimal
    9. write it back to offset 0x26
15. Pad the card to a proper size of 2112 (0x840) bytes. You can fill the area after the VPK until 0x83F with FF.
16. Fix the cards checksums by droping it on headerfix.exe and you are done!
17. You are done! You can now encode your edited card back into a raw e-Card: nedcenc.exe -i custom.bin -e -o custom.raw

 

You can use the dotcode printer from the devtools for printing, it can print dotcodes in raw or bmp format. Keep the DPI at 300, choose your card and your printer and print it!
You could as well just convert your raw card into bmp (raw2bmp.exe -i card.raw -o card.bmp) and print that.

 

So, I hope everything was clear enough, if there are still questions feel free to ask!

[DragonmasterDX]

Thanks much for this, BlackShark! I appreciate the work you've put into this guide!

[LinkPlayer]

Do you know where the language section is located? I want to make e-cards for the European versions

[theSLAYER]

58 minutes ago, LinkPlayer said:

Do you know where the language section is located? I want to make e-cards for the European versions

European languages should work across each other. So as long as you use the English one as base it should be enough.

[BlackShark]

8 hours ago, theSLAYER said:

So as long as you use the English one as base it should be enough.

Unfortunately not. After the region verification on the card header there's language verification on the vpk.

9 hours ago, LinkPlayer said:

Do you know where the language section is located?

0xD26, 0xD3D and 0xD3F

0x01 Japanese
0x02 English
0x03 French
0x04 Italian
0x05 German
0x06 unused
0x07 Spanish

You can actually skip the whole process with pasting the edited vpk back into the card. Just use nedcmake from the dev tools and rebuild it. I guess I should update the guide at some point.

Region 1 = US, 2 = Japan, Type 1 is for berries and trainers.

nedcmake.exe -i card.vpk -o card.raw -type 1 -region 1

 

[theSLAYER]

Didn't know that, cool, thanks ;D

[SupremeThunderDragon]

Thank you a ton BlackShark for this breakdown. In combination with other resources, it's been very helpful for this novice to understand the basic structure of the e-cards. I'm wondering if there's any additional details you can go into regarding what the VPK is and how it works? I'm assuming this is the machine code for the e-Reader to parse, but I wouldn't know where to start in regards to editing something beyond just a trainer or berry.

In particular, I've been curious about how multi-strip programs work for Mystery Event. It's hard enough to find any documentation regarding the e-Reader, much less about Mystery Event e-cards with more than one strip, since to my knowledge only two exist and they're both Japanese. The trainer cards, berry cards, and Eon Ticket are all one strip to scan. However, the Japanese 08-O001 Regi Doll Decoration Present is two strips, and the oft-forgotten Japanese 16-A001/2 "Berry Problem Repair Program" is a whopping four strips to scan.

Against my better judgement, I wanted to start my e-card analysis with the Berry Problem Repair Program. Since it supposedly just shifts the RTC timestamp of the save game, I found it curious that it somehow requires four strips to scan. Instead, I've discovered that the BPRP appears to not follow the same VPK rules that all other Mystery Event e-cards do.

Firstly, I should mention how these multi-strip cards differ from the single-strip ones. For every e-card .bin file, the compressed data VPK + padding is a total of 2029 bytes after the VPK size bytes. With more than one strip, the only strip that actually has padding is the final one (ie, the second strip for the Decoration Present, and the fourth strip for the BPRP), with all other strips containing VPK data in the full 2029 bytes. In addition, the VPK size bytes only seem to apply for the first strip, which denotes the combined VPK size of all strips. Every other strip has weird VPK size bytes that I don't understand.

Strip	VPK Byte	VPK Byte (Decimal)	VPK Size	Size Info Byte
08-O001 1	0x0DA4	3,492	2,029	0x021B4C42
08-O001 2	0x0D00	3,328	1,461	0x021B4C44
16-A001 1	0x19D5	6,613	2,029	0x0233B682
16-A001 2	0x087E	2,174	2,029	0x0233B684
16-A002 1	0xC203	49,667	2,029	0x0233B686
16-A002 2	0x708F	28.815	524	0x0233B688

The total VPK size for the Decoration Present is 3,490, but the first strip's VPK byte has it two bytes larger at 3,492. Likewise, the BPRP's total VPK size is 6,611 yet the first strip's VPK byte also has it two bytes larger at 6,613. I thought I miscounted multiple times, but it's peculiar that two separate strip sizes are both two bytes less. I ensured this was a trait not shared with other cards; for reference, both the English and Japanese Eggant Berry cards' VPK byte matches their VPK size (0x053F to 1,343 and 0x054B to 1,355, respectively).

This oddity aside, I was able to take the two strips from the Decoration Present e-card, cut their VPKs from each, paste the two together, and it successfully decompiled into a VPK that has "GameFreak inc," so I assume it was done properly.

On the other hand, the BPRP can't be decompiled in the same manner. The VPK tool says "Invalid vpk data" when I try decompressing a file composed of the four VPK pieces from each strip of the BPRP. Perhaps most importantly, the VPK of the first strip does lacks something every other strip does: leading with 0x306B7076, aka the text "vpk0."  After the VPK size bytes, every VPK starts with that, and this includes strip 1 of the Decoration Goods (but not strip 2, likely because it's a direct continuation of the full VPK). It seems possible that the Berry Problem Repair Program uses some unique format or something, and if it doesn't follow the same format that the rest do, then this novice is immediately out of ideas.

Decoration Goods' header and VPK start, with the standard "vpk0" begin:

Berry Problem Repair Program's header and alleged VPK start, lacking the standard "vpk0":

I've included the sets of .bin files for the BPRP and Decoration Goods to look at or check my work.

berry_prog_bin_files.rar deco_goods_bin_files.rar

[3rd Gen Expert]

So, if I am understanding this correctly: it is possible to alter any original Japanese E-Reader card raw file, change the region bytes to US, print, and use as if authentic? I am seeing someone capitalizing on this idea, but I am more interested in adding official Japanese trainers to FRLGE (though it appears...I could make ANY trainer?), and perhaps the Japanese Series 2 Berry Set to RS.

Does this work for both NTSC-U versions of FRLG and Emerald? Or has some card reading functionality stripped out here?

Or is there maybe just a flag that needs to be set in the ROM to use original Japanese cards via a Japanese E-Reader+ (after seeing this promising video) I know (while albeit a different case) NSTC-U Colosseum just blocked access to the E-Reader room, but everything still worked authentically after you get in there.

[Lordbaldpmero]

El 1/4/2021 a las 5:15 a.m., BlackShark dijo:

 

What's up, I'm new to this, I try my best to understand but I can't get nedcenc to work, how do I run it?

 

Thank you very much for the contribution