Jump to content

Recommended Posts

Posted

Made some VB code for Gen 6:

#Region "Generation 6"
#Region "Classes"
Public Class Class1
#Region "Block A"
   ' Starts at 0x8
   Public PokedexID As String ' 0x8
   Public HeldItem As String ' 0xA
   Public OTID As UInt16  ' 0xC
   Public OTSID As UInt16 ' 0xE
   Public EXP As UInt32 ' 0x10
   Public Ability As Byte     ' 0x14
   Public Ability_Num As Byte ' 0x15
   Public Nature As Byte ' 0x1C
   Public Multi_Flag1 As Byte ' 0x1D
   Public HP_EV As Byte        ' 0x1E
   Public Attack_EV As Byte    ' 0x1F
   Public Defense_EV As Byte   ' 0x20
   Public Speed_EV As Byte     ' 0x21
   Public SpAttack_EV As Byte  ' 0x22
   Public SpDefense_EV As Byte ' 0x23
   Public Pokerus As Byte ' 0x2B
   Public Ribbons As UInt32 ' 0x30
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       PokedexID = BitConverter.ToUInt16(block, 0)
       HeldItem = BitConverter.ToUInt16(block, 2)
       OTID = BitConverter.ToUInt16(block, 4)
       OTSID = BitConverter.ToUInt16(block, 6)
       EXP = BitConverter.ToUInt32(block, 8)
       Ability = block(&HC)
       Ability_Num = block(&HD)
       Nature = block(&H14)
       Multi_Flag1 = block(&H15)
       HP_EV = block(&H16)
       Attack_EV = block(&H17)
       Defense_EV = block(&H18)
       Speed_EV = block(&H19)
       SpAttack_EV = block(&H1A)
       SpDefense_EV = block(&H1B)
       Pokerus = block(&H23)
       Ribbons = block(&H28)
   End Sub
#End Region
End Class
Public Class Class2
#Region "Block B"
   ' Starts at 0x40
   Public Nickname As String ' 0x40 - 0x57
   Public Move1 As UInt16 ' 0x5A
   Public Move2 As UInt16 ' 0x5C
   Public Move3 As UInt16 ' 0x5E
   Public Move4 As UInt16 ' 0x60
   Public Move1_PP As Byte ' 0x62
   Public Move2_PP As Byte ' 0x63
   Public Move3_PP As Byte ' 0x64
   Public Move4_PP As Byte ' 0x65
   Public Move1_PPUP As Byte ' 0x66
   Public Move2_PPUP As Byte ' 0x67
   Public Move3_PPUP As Byte ' 0x68
   Public Move4_PPUP As Byte ' 0x69
   Public Move1_Hatch As Byte ' 0x6A
   Public Move2_Hatch As Byte ' 0x6C
   Public Move3_Hatch As Byte ' 0x6E
   Public Move4_Hatch As Byte ' 0x70
   Public IV_Block As UInt32 ' 0x74
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       Dim decpt As New System.Text.UnicodeEncoding
       Nickname = decpt.GetString(block, 0, 24)
       Move1 = BitConverter.ToUInt16(block, &H1A)
       Move2 = BitConverter.ToUInt16(block, &H1C)
       Move3 = BitConverter.ToUInt16(block, &H1E)
       Move4 = BitConverter.ToUInt16(block, &H20)
       Move1_PP = block(&H22)
       Move2_PP = block(&H23)
       Move3_PP = block(&H24)
       Move4_PP = block(&H25)
       Move1_PPUP = block(&H26)
       Move2_PPUP = block(&H27)
       Move3_PPUP = block(&H28)
       Move4_PPUP = block(&H29)
       Move1_Hatch = BitConverter.ToUInt16(block, &H2A)
       Move2_Hatch = BitConverter.ToUInt16(block, &H2C)
       Move3_Hatch = BitConverter.ToUInt16(block, &H2E)
       Move4_Hatch = BitConverter.ToUInt16(block, &H30)
       IV_Block = BitConverter.ToUInt32(block, &H34)
   End Sub
#End Region
End Class
Public Class Class3
#Region "Block C"
   ' Starts at 0x78
   Public OT_Owner As String ' 0x78 - 0x8F
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       Dim decpt As New System.Text.UnicodeEncoding
       OT_Owner = decpt.GetString(block, 0, 18)
   End Sub
#End Region
End Class
Public Class Class4
#Region "Block D"
   ' Starts at 0xB0
   Public OT_Name As String ' 0xB0 - 0xC7
   Public Date_Egg_Received(2) As Byte ' 0xD1 - 0xD3
   Public Date_Met(2) As Byte ' 0xD4 - 0xD6
   Public Egg_Location As UInt16 ' 0xD8 - 0xD9
   Public Met_At_Location As UInt16 ' 0xDA - 0xDB
   Public PokeBall As Byte ' 0xDC
   Public Multi_Flag2 As Byte ' 0xDD
   Public Game_Version As Byte ' 0xDF ' X = 24, Y = 25
   Public Country_ID As Byte   ' 0xE0
   Public Region_ID As Byte    ' 0xE1
   Public DS_Region_ID As Byte ' 0xE2
   Public OT_Language As Byte ' 0xE3
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       Dim decpt As New System.Text.UnicodeEncoding
       OT_Name = decpt.GetString(block, 0, 18)
       Date_Egg_Received(0) = block(&H21)
       Date_Egg_Received(1) = block(&H22)
       Date_Egg_Received(2) = block(&H23)
       Date_Met(0) = block(&H24)
       Date_Met(1) = block(&H25)
       Date_Met(2) = block(&H26)
       Egg_Location = BitConverter.ToUInt16(block, &H28)
       Met_At_Location = BitConverter.ToUInt16(block, &H2A)
       PokeBall = block(&H2C)
       Multi_Flag2 = block(&H2D)
       Game_Version = block(&H2F)
       Country_ID = block(&H30)
       Region_ID = block(&H31)
       DS_Region_ID = block(&H32)
       OT_Language = block(&H33)
   End Sub
#End Region
End Class
Public Class Class5
#Region "Unencryted Section"
   ' Starts at 0x0
   Public PID As UInt32 ' 0x0
   Public Sanity_Placeholder As UInt16 ' 0x4
   Public Checksum As UInt16 ' 0x6
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       PID = BitConverter.ToUInt32(block, 0)
       Sanity_Placeholder = BitConverter.ToUInt16(block, 4)
       Checksum = BitConverter.ToUInt16(block, 6)
   End Sub
#End Region
End Class
#End Region
Public Class PKM_File
#Region "Setup"
   Public Sub New(blka As Byte(), blkb As Byte(), blkc As Byte(), blkd As Byte(), blku As Byte())
       BlockU = New Class5(blku)
       BlockA = New Class1(blka)
       BlockB = New Class2(blkb)
       BlockC = New Class3(blkc)
       BlockD = New Class4(blkd)
   End Sub
#End Region
#Region "Declarations"
   Public BlockU As Class5
   Public BlockA As Class1
   Public BlockB As Class2
   Public BlockC As Class3
   Public BlockD As Class4
#End Region
End Class
#End Region

  • Replies 284
  • Created
  • Last Reply

Top Posters In This Topic

Posted
Made some VB code for Gen 6:

#Region "Generation 6"
#Region "Classes"
Public Class Class1
#Region "Block A"
   ' Starts at 0x8
   Public PokedexID As String ' 0x8
   Public HeldItem As String ' 0xA
   Public OTID As UInt16  ' 0xC
   Public OTSID As UInt16 ' 0xE
   Public EXP As UInt32 ' 0x10
   Public Ability As Byte     ' 0x14
   Public Ability_Num As Byte ' 0x15
   Public Nature As Byte ' 0x1C
   Public Multi_Flag1 As Byte ' 0x1D
   Public HP_EV As Byte        ' 0x1E
   Public Attack_EV As Byte    ' 0x1F
   Public Defense_EV As Byte   ' 0x20
   Public Speed_EV As Byte     ' 0x21
   Public SpAttack_EV As Byte  ' 0x22
   Public SpDefense_EV As Byte ' 0x23
   Public Pokerus As Byte ' 0x2B
   Public Ribbons As UInt32 ' 0x30
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       PokedexID = BitConverter.ToUInt16(block, 0)
       HeldItem = BitConverter.ToUInt16(block, 2)
       OTID = BitConverter.ToUInt16(block, 4)
       OTSID = BitConverter.ToUInt16(block, 6)
       EXP = BitConverter.ToUInt32(block, 8)
       Ability = block(&HC)
       Ability_Num = block(&HD)
       Nature = block(&H14)
       Multi_Flag1 = block(&H15)
       HP_EV = block(&H16)
       Attack_EV = block(&H17)
       Defense_EV = block(&H18)
       Speed_EV = block(&H19)
       SpAttack_EV = block(&H1A)
       SpDefense_EV = block(&H1B)
       Pokerus = block(&H23)
       Ribbons = block(&H28)
   End Sub
#End Region
End Class
Public Class Class2
#Region "Block B"
   ' Starts at 0x40
   Public Nickname As String ' 0x40 - 0x57
   Public Move1 As UInt16 ' 0x5A
   Public Move2 As UInt16 ' 0x5C
   Public Move3 As UInt16 ' 0x5E
   Public Move4 As UInt16 ' 0x60
   Public Move1_PP As Byte ' 0x62
   Public Move2_PP As Byte ' 0x63
   Public Move3_PP As Byte ' 0x64
   Public Move4_PP As Byte ' 0x65
   Public Move1_PPUP As Byte ' 0x66
   Public Move2_PPUP As Byte ' 0x67
   Public Move3_PPUP As Byte ' 0x68
   Public Move4_PPUP As Byte ' 0x69
   Public Move1_Hatch As Byte ' 0x6A
   Public Move2_Hatch As Byte ' 0x6C
   Public Move3_Hatch As Byte ' 0x6E
   Public Move4_Hatch As Byte ' 0x70
   Public IV_Block As UInt32 ' 0x74
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       Dim decpt As New System.Text.UnicodeEncoding
       Nickname = decpt.GetString(block, 0, 24)
       Move1 = BitConverter.ToUInt16(block, &H1A)
       Move2 = BitConverter.ToUInt16(block, &H1C)
       Move3 = BitConverter.ToUInt16(block, &H1E)
       Move4 = BitConverter.ToUInt16(block, &H20)
       Move1_PP = block(&H22)
       Move2_PP = block(&H23)
       Move3_PP = block(&H24)
       Move4_PP = block(&H25)
       Move1_PPUP = block(&H26)
       Move2_PPUP = block(&H27)
       Move3_PPUP = block(&H28)
       Move4_PPUP = block(&H29)
       Move1_Hatch = BitConverter.ToUInt16(block, &H2A)
       Move2_Hatch = BitConverter.ToUInt16(block, &H2C)
       Move3_Hatch = BitConverter.ToUInt16(block, &H2E)
       Move4_Hatch = BitConverter.ToUInt16(block, &H30)
       IV_Block = BitConverter.ToUInt32(block, &H34)
   End Sub
#End Region
End Class
Public Class Class3
#Region "Block C"
   ' Starts at 0x78
   Public OT_Owner As String ' 0x78 - 0x8F
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       Dim decpt As New System.Text.UnicodeEncoding
       OT_Owner = decpt.GetString(block, 0, 18)
   End Sub
#End Region
End Class
Public Class Class4
#Region "Block D"
   ' Starts at 0xB0
   Public OT_Name As String ' 0xB0 - 0xC7
   Public Date_Egg_Received(2) As Byte ' 0xD1 - 0xD3
   Public Date_Met(2) As Byte ' 0xD4 - 0xD6
   Public Egg_Location As UInt16 ' 0xD8 - 0xD9
   Public Met_At_Location As UInt16 ' 0xDA - 0xDB
   Public PokeBall As Byte ' 0xDC
   Public Multi_Flag2 As Byte ' 0xDD
   Public Game_Version As Byte ' 0xDF ' X = 24, Y = 25
   Public Country_ID As Byte   ' 0xE0
   Public Region_ID As Byte    ' 0xE1
   Public DS_Region_ID As Byte ' 0xE2
   Public OT_Language As Byte ' 0xE3
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       Dim decpt As New System.Text.UnicodeEncoding
       OT_Name = decpt.GetString(block, 0, 18)
       Date_Egg_Received(0) = block(&H21)
       Date_Egg_Received(1) = block(&H22)
       Date_Egg_Received(2) = block(&H23)
       Date_Met(0) = block(&H24)
       Date_Met(1) = block(&H25)
       Date_Met(2) = block(&H26)
       Egg_Location = BitConverter.ToUInt16(block, &H28)
       Met_At_Location = BitConverter.ToUInt16(block, &H2A)
       PokeBall = block(&H2C)
       Multi_Flag2 = block(&H2D)
       Game_Version = block(&H2F)
       Country_ID = block(&H30)
       Region_ID = block(&H31)
       DS_Region_ID = block(&H32)
       OT_Language = block(&H33)
   End Sub
#End Region
End Class
Public Class Class5
#Region "Unencryted Section"
   ' Starts at 0x0
   Public PID As UInt32 ' 0x0
   Public Sanity_Placeholder As UInt16 ' 0x4
   Public Checksum As UInt16 ' 0x6
#End Region
#Region "Sub New"
   Public Sub New(block As Byte())
       PID = BitConverter.ToUInt32(block, 0)
       Sanity_Placeholder = BitConverter.ToUInt16(block, 4)
       Checksum = BitConverter.ToUInt16(block, 6)
   End Sub
#End Region
End Class
#End Region
Public Class PKM_File
#Region "Setup"
   Public Sub New(blka As Byte(), blkb As Byte(), blkc As Byte(), blkd As Byte(), blku As Byte())
       BlockU = New Class5(blku)
       BlockA = New Class1(blka)
       BlockB = New Class2(blkb)
       BlockC = New Class3(blkc)
       BlockD = New Class4(blkd)
   End Sub
#End Region
#Region "Declarations"
   Public BlockU As Class5
   Public BlockA As Class1
   Public BlockB As Class2
   Public BlockC As Class3
   Public BlockD As Class4
#End Region
End Class
#End Region

Is that VB.net or VB6? Because they're two entirely different languages.

I'm asking this in case others don't get confused when they try to use one thing but their code doesn't compile properly.

Posted

I got an idea:

Why not reverse engineer the protocol used for the mystery gift to inject Pokémon over?

If we can't use internet-based ones to intercept Pokémon recieved through the internet (ie, the event Torchic), one can get their hands on a Wallmart copy of the game and reverse engineer the protocol for the serial key instead?

Posted
I got an idea:

Why not reverse engineer the protocol used for the mystery gift to inject Pokémon over?

If we can't use internet-based ones to intercept Pokémon recieved through the internet (ie, the event Torchic), one can get their hands on a Wallmart copy of the game and reverse engineer the protocol for the serial key instead?

The serial key is checked against a server which then distributes a Pokémon if the code is valid.

Like the rest of the GTS/Mystery Gift functions, this is encrypted and so reverse engineering it is not a viable option.

Posted

have you already tried with a packet injection system?

so far we know the pkx format and how the packet is structured to extract the pkx. wich mean that the packe have a structure like [validation not yet breaked][pkx file][end packet] or similar (i didn't really had the time to dig it). my basic idea is that the part that we still have to break might be somthing generated using the other trainer info or server generated info.

by using a man in the middle kind of attack we can use a structure like this:

pc with both eth (or other network card) and a wireless card in master mode. with the pc routing the traffic we should be able to inject in the packet on the fly our pkm replacing the old pkx. (this might sound confusing and i'm not a native english speaker so if you need some kind of clarification please tell me)

Posted
have you already tried with a packet injection system?

so far we know the pkx format and how the packet is structured to extract the pkx. wich mean that the packe have a structure like [validation not yet breaked][pkx file][end packet] or similar (i didn't really had the time to dig it). my basic idea is that the part that we still have to break might be somthing generated using the other trainer info or server generated info.

by using a man in the middle kind of attack we can use a structure like this:

pc with both eth (or other network card) and a wireless card in master mode. with the pc routing the traffic we should be able to inject in the packet on the fly our pkm replacing the old pkx. (this might sound confusing and i'm not a native english speaker so if you need some kind of clarification please tell me)

We've already examined the protocol to find out how it works.

Turns out, there's kind of a checksum applied to the transaction that verifies the trade.

We need to figure out how said checksum works before we even try to inject Pokémon through trades.

Posted

Unless you've figured out how the packet hash is calculated, your posts with random ideas or suggestions aren't serving any purpose. You cannot come up with anything useful, because there is nothing to be done at this point.

  • 2 weeks later...
Posted

I am not sure how much of a help it is, but people had been talking about Masuda Method in this thread, so I'll just dump the results of my experiments.

As people may or may not know, the stats inherited to the offspring are even determined before the egg is generated, thus you can save, generate the egg, take it, hatch it, check its IVs and look up which parent inherited what stat.

Now "international" and "normal" breeding use different algorithms when it comes to determining which stats are inherited, so there is always one inheritence spread for normal breeding and one for international breeding.

If you use a "Japanese" (meaning language set to Japanese but region still normal) and a Japanese (real Japanese one with both language and region set to Japan), the international inheritance spread is used instead of the normal one. If you use completely foreign parents, also the international inheritance spread is used. Which means that determining whether the international or normal inheritance algorithm is used is based on region settings.

It is most likely that the international breeding algorithm also makes shinies appear more frequently which means that international breeding and the Masuda Method are related to each other, but in the end people may whine because they only set the language to a foreign one for nothing and claim that this is just a theory (though everything points to it being the case) since we can't dig into the ROM and look that mechanics up.

Hope that information is helpful in any way.

(Also what I wonder is whether the chances of encountering a shiny had been increased. Instacheck uses that shiny values that are 12-bit long while the determination stays the same (XOR first 12 bits of LPID, UPID, SID and TID etc). If still the 13-bit numbers were used for determining shininess like in previous generations, there would have been a load of false positives within Instacheck and people would notice it early since very many people use it, but somehow I am not sure if I am just missing something that makes the chances remain 1:8192 instead of 1:4096.)

Posted
(Also what I wonder is whether the chances of encountering a shiny had been increased. Instacheck uses that shiny values that are 12-bit long while the determination stays the same (XOR first 12 bits of LPID, UPID, SID and TID etc). If still the 13-bit numbers were used for determining shininess like in previous generations, there would have been a load of false positives within Instacheck and people would notice it early since very many people use it, but somehow I am not sure if I am just missing something that makes the chances remain 1:8192 instead of 1:4096.)

The original Shininess Determination prior to Gen VI was XOR result (16-bit) < 8 (= 2 ^ 3), therefore you have to match 16 - 3 = 13 bits.

In XY however, there are reports of Shiny Pkxs whose XOR result falls between 8 and 15. This leads to the speculation of the threshold being raised to 16 (= 2 ^ 4), which will yield a 16 - 4 = 12 bit match.

The chances are thus 2 ^ -13 = 1/8192 and 2 ^ -12 = 1/4096 .

By the way, can we confirm the threshold by intentionally set up a breeding of non-Shiny with XOR result 16?

Posted
The original Shininess Determination prior to Gen VI was XOR result (16-bit) < 8 (= 2 ^ 3), therefore you have to match 16 - 3 = 13 bits.

In XY however, there are reports of Shiny Pkxs whose XOR result falls between 8 and 15. This leads to the speculation of the threshold being raised to 16 (= 2 ^ 4), which will yield a 16 - 4 = 12 bit match.

The chances are thus 2 ^ -13 = 1/8192 and 2 ^ -12 = 1/4096 .

By the way, can we confirm the threshold by intentionally set up a breeding of non-Shiny with XOR result 16?

I don't know about you, but I've been using Smogon's instacheck, that shows trainer's and egg's shiny value (TSV and ESV respectively),

and that value goes up to max 4096.

So far, all my hatches, done for me and done for other people, have all hatched shiny indeed.

Based on my results, it matches the 1/4096 threshold

Posted

To absolve any confusion:

( TID ^ SID >> 4 ) = Trainer Shiny Value

( PIDlow^PIDhigh >> 4 ) = PKM Shiny Value

If both xor'd together = 0, the Pokemon is shiny. It's always been this way; it's just a new fan term for it since it is a bit more abusable.

The way the games determine if its shiny or not is more or less this:

(PIDlow^PIDhigh)^(TID^SID)>>3 = 0 -> Shiny [Gen 3-5 origin] (return 0-8191)

(PIDlow^PIDhigh)^(TID^SID)>>4 = 0 -> Shiny [Gen VI origin] (return 0-4095)

Without the shifts, pre gen6 the XORs had to return a number 0-7. What we noticed in Gen VI is that shinies exhibited 0-15 results, thus the overall odds were doubled.

The whole shiny value stuff is a fan simplification since PIDs and Trainer IDs can't be altered by one user, only the OT can be changed (giving a new SIDTID).

I don't think anyone has bothered checking xor=16, but there shouldn't be a difference between wilds/breeds. They can always roll extra PIDs if it's not shiny (like genV shiny charm or gen45 MM, or g34 everstones... you get the point)

Posted

For the record, for anyone who is researching the checksum and comparisons of trading encrypted information,

Pokemon cloning is now possible.

I've done this with my friend and it worked, but the window was really really slow. took me half an hour to get one success -.-

Perhaps you can trade the same pokemon with each other for comparison.

(though this ain't possible for wonder trade, duh. Unless you managed to find a time slot where no one else is wonder trading and thus co-ordinate; only happened to me once.)

Posted
So the 1.2 patch ruined it all, here's a comparison of frames and stuff.

Contains an entire box (20 Pokemon) from my game.

- Box 13 - 1.0 1.1

- Box 13 - 1.2 363

- Box 13 - 1.2 407

- Box 13 - pkx

Stupid Battle Analyzer. This is why we can't have nice things.

*Sigh*

Now I must revert to traditional ways of getting shinies ;(

EDIT:

Either that or we use Virtual Router to create some form of spoofed Local Network, like Hamachi? I don't know T.T *cries*

Posted

To recap what's new due to 1.2:

EAD header:

uint magic; //0x0301D0EA // EA D0 01 03

ushort size; // without EAD header

ushort unk1; // wondertrade: 0x1111, gts = 0xAFA1

ushort unk2; // wondertrade: 0x08E2, gts = 0x00E2

ushort unk3;

ushort packetId;

ubyte checksum[16];

ushort unk4; // 02 01

ubyte encryptedFlag; // 00 = plaintext (wondertrade), 01 = encrypted (gts)

Data:

ubyte data;

if it's wondertrade:

byte unk[0x1C];

byte pkx[0x104]; box & party data

That's what it used to be.

Now the only difference is that the 0x120 payload of the unk&pkx is never the same (when comparing different instances) because it is encrypted.

Image showing a 1.0 packet and a 1.2 packet of the same PKX stored in a box:

qIOce.jpg

Thanks RoC -- this is his Xerneas and the first 1.2 dump of it.

I'm not assuming that both the 0x1C and 0x104 datas are the same between packets; the encryption key for the PKX should be the same -- it's just showing that the packet is encrypted with another layer of protection.

Speculation:

The traffic has not been entirely encrypted; the same header, checksum, and payload arrangement exists. So it still is obvious where in the transmission our desired data is... it's just got another layer of protection.

As for that protection, since both the checksum and the 0x120 data are different for subsequent interactions, I'd imagine that the checksum is what creates that layer. Call it a hunch but I think it's probably used as a encryption/decryption key for the packet the same way the Gen 4/5 checksum was for pkm's. You have your data you want to protect, you checksum it so you can detect modification, then you use your checksum to hide it from prying eyes with some sort of RNG XOR.

Upon looking at the posted GTS packets... this might be the same kind of encryption layer the GTS uses...

Posted
To recap what's new due to 1.2:

That's what it used to be.

Now the only difference is that the 0x120 payload of the unk&pkx is never the same (when comparing different instances) because it is encrypted.

Image showing a 1.0 packet and a 1.2 packet of the same PKX stored in a box:

qIOce.jpg

Thanks RoC -- this is his Xerneas and the first 1.2 dump of it.

I'm not assuming that both the 0x1C and 0x104 datas are the same between packets; the encryption key for the PKX should be the same -- it's just showing that the packet is encrypted with another layer of protection.

Speculation:

The traffic has not been entirely encrypted; the same header, checksum, and payload arrangement exists. So it still is obvious where in the transmission our desired data is... it's just got another layer of protection.

As for that protection, since both the checksum and the 0x120 data are different for subsequent interactions, I'd imagine that the checksum is what creates that layer. Call it a hunch but I think it's probably used as a encryption/decryption key for the packet the same way the Gen 4/5 checksum was for pkm's. You have your data you want to protect, you checksum it so you can detect modification, then you use your checksum to hide it from prying eyes with some sort of RNG XOR.

Upon looking at the posted GTS packets... this might be the same kind of encryption layer the GTS uses...

so, in theory, after figuring out the encryption, tracking the packet is still possible?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...