Poryhack

I know I wasn't the designated answerer here, but I wholeheartedly disagree that PID<>IV relationships are worthless. There are plausible pokemon and there are genuine pokemon, and they are for all intents and purposes exactly the same. BUT there are also pokemon that aren't even plausible; a wondertomb for instance. A pokemon that has an invalid PID<>IV combination is in the same boat as a wondertomb. It's more subtle sure, but it is nonetheless a pokemon that isn't and shouldn't be legal for tournaments, trades, etc.

I haven't seen anything like that, and I doubt there is anything. The palm crowd and the pokemon crowd didn't have a ton in common.

The source should still be kicking around somewhere, I had it for a time but lost it in an unfortunate format. I've gotta say it's not really as special as you'd expect though. Sabresite was brilliant no doubt but with only a few exceptions the stuff he discovered/co-discovered has been publicized at one point or another. In Legal's dying days Sabresite tried to take a step beyond the math and give it a database but I wouldn't trust that for much. I was always the methodical guy with the database whereas Sabre couldn't remember what you said to him yesterday. We worked together a lot but Legal's database aspects were an afterthought for Sabresite that I didn't really agree with, so nobody bothered to make sure it was complete or accurate.

I doubt it. They did it with the Pal Park last gen for no apparent reason. (The GBA games were never released in Korean.)

The client DS has to have a legitimate retail copy of D/P/Pt/HG/SS; there never was a (attempted) workaround for that and there never will be. This patch was designed to work around the region lock but it doesn't work and as of now the region of D/P/Pt/HG/SS must match the region of B/W.

Thanks for the heads up, I will keep it in mind. EDIT: I'm pretty close to a definitive answer on weather or not forcing a non-encrypted ciphersuite will work. My setup is impersonating the dls1 server as best it possibly can and I just have to work out an issue I'm having with java not wanting to use my ciphersuite settings. EDIT2: I've gotten my earlier issue resolved but now I'm running up against another problem I've been anticipating. Java breaks the connection upon noticing that the DS's listed ciphersuites don't include the null suite I'm attempting to force on it. I may have to resort to a lower-level method to get the flexibility I need. This is turning out to be a lot of effort for something that isn't likely to work... =/

This isn't really the place to discuss it, but look into this to dump your save file and this to edit it.

The goal of this project is to get wondercards onto retail game cards without 3rd party hardware and/or create a desktop client program to download wondercards from the official server.

Pokedoc, any comment on the 3in1 issue where saves are being written with trash data? A lot of people (myself included) have had the issue and kuronot even noticed that there was some kind of pattern to it.

Oh you're right, sorry, don't know what I was thinking.

In DP the file that contained this information was called zukan_data.narc; I detailed it here. For HGSS it should be a/0/7/4.

DPPt and HGSS were built on the same engine and mystery gift compatibility was by design. BW is totally new. Specifically, the wondercard data structure is new, which is the main thing killing this idea.

I cant really recall any 3in1 homebrew I've used that hasn't had intermittent issues like this. You got things to work the same way I did; trying again.

http://gbatemp.net/index.php?showtopic=193929

Your saves opens up fine in Pokesav. What was it not working in?

I'm not gonna write a comprehensive guide but the process goes something like this: Find the banner graphic in the ROM's filesystem. This is possibly the most time consuming part, unless someone else has already documented the location of this particular graphic. Edit the file with some kind of tile editor... This could be a lot less painful then it is but sadly there are no tools that are made specifically to edit DS graphics. Replace the original file in the ROM with your edited copy; pretty easy with all the filesystem tools out there.

Almost all the overlay files in HG/SS (and Platinum IIRC) are compressed. I found your string "00 05 05 00 08 05 0A 0A 05 0A 0B 05 0A 0C 14" in overlay 12 after decompressing it, and from the looks of it everything else is there too, ready to edit. I assume you know how to decompress files in CrystalTile2 now; it's the same process as with starter editing just with a different file.

I'd be willing to to take a crack at this. I've never done it on DP or any other version(s) though so I'm gonna request that you provide some detailed information on how to do it in in DP. I'll then try my best to extrapolate to HGSS.

Good news. The CA public keys aren't encrypted. Because Nintendo CA doesn't publish their public key I had no way to verify that it wasn't encrypted, but I think it's a safe bet because the public keys listed for the other CAs are not encrypted. I specifically checked the key under Thawte Consulting against the root certificate found here (Thawte is a subsidiary of Verisign) and it's a match. What this means is that at the very least we can snoop on transactions with the genuine dls1 server and subsequently create and run fake server(s) that will work with an edited ROM as well as write a desktop client program that will work with any server. I still prefer a solution which wouldn't require an edited ROM (thus allowing retail card users to take advantage of it) which is why I'm going to try forcing the DS into a nonencrypted ciphersuite first. Beyond that the only way I can think of that would be viable for retail cards is to use RNG prediction which is not something I particularly want to try ...even if it worked out the process would have to be repeated for every connection to the server which would just be a nightmare.

I've got what should be a compatible PCI card and now that I'm back home for break I can finally put it in a desktop machine and try it out.

You probably aren't decompressing the ARM9 file first then. The only tool I know of that will do it for you is CrystalTile2.

Now we're getting somewhere! As you can see from my earlier post I was considering an SSL MITM and at the same time kind of doubting it would work. You finding the request URL in plaintext changes things though. If GAMEFREAK's code doesn't break upon modifying that URL to use plain HTTP we could set up a proxy server to log whatever comes from the DS, SSL-ify it, and relay it to the real server then do the same thing in reverse for what the server sends back. Once we know the protocol we could use some of the same techniques to set up a fake server. The catch is that it would require ROM hacking; I may try to focus on methods that wouldn't require ROM hacking first. Awesome find. I've searched all over for this but I never thought to look for just a partial URL. This'll be very useful; we could probably have a working client without anything more then this. I've seen these before and they are definitely SSL/certificate related. They're not the private key though; I'm not sure how much you know about RSA but the private key never needs to leave the server for the whole SSL scheme to work, having it on the DS would be pointless and even more insecure than GF normally is. However, I am noticing good things that I failed to see before. The dls1 server's certificate correlates with "US, Washington, Nintendo of America Inc, NOA, Nintendo CA, ca@noa.nintendo.com" (those are several of the fields on the certificate). Each of the bytestrings you copied looks to be a public key (it's the correct length for a 1024bit key) and some metadata. The metadata actually precedes the "name" part. Like this: 01 00 01 00 E0 CA 20 02 80 00 00 00 30 CB 20 02 03 00 00 00 C8 CA 20 02 // metadata 55 53 2C 20 57 61 73 68 69 6E 67 74 6F 6E 2C 20 4E 69 6E 74 65 6E 64 6F // "US, Washington, Nintendo of America Inc, NOA, Nintendo CA, ca@noa.nintendo.com" 20 6F 66 20 41 6D 65 72 69 63 61 20 49 6E 63 2C 20 4E 4F 41 2C 20 4E 69 6E 74 65 6E 64 6F 20 43 41 2C 20 63 61 40 6E 6F 61 2E 6E 69 6E 74 65 6E 64 6F 2E 63 6F 6D 00 00 B3 CD 79 97 77 5D 8A AF 86 A8 E8 D7 73 1C 77 DF 10 90 1F 81 F8 41 9E 21 // 1024 bit RSA public key of Nintendo CA 55 DF BC FC 63 FB 19 43 F1 F6 C4 72 42 49 BD AD 44 68 4E F3 DA 1D E6 4D D8 F9 59 88 DC AE 3E 9B 38 09 CA 7F FF DC 24 A2 44 78 78 49 93 D4 84 40 10 B8 EC 3E DB 2D 93 C8 11 C8 FD 78 2D 61 AD 31 AE 86 26 B0 FD 5A 3F A1 3D BF E2 4B 49 EC CE 66 98 58 26 12 C0 FB F4 77 65 1B EA FB CB 7F E0 8C CB 02 A3 4E 5E 8C EA 9B I've gotta check if the key in encrypted at all to prevent tampering...

I can't find any of my IR cards or I'd test this myself, but are all HGSS saves coming out of this program like this? If it's only areas with zeros then it seems like some kind of weird masking issue (ie writing 00 over a non-00 byte won't change the byte) which could be an issue with the program.

The diamond save doesn't work either, I thought you said it worked... I can't see anything glaringly wrong with these; at this point I'm not really sure what the issue is.

.