bug Gen II Egg species identifier (glitch/hacking related)

[theSLAYER]

Was just playing around, and changing to my box 10 prompted this message:

See the end of this message for details on invoking

just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************

System.IndexOutOfRangeException: Index was outside the bounds of the array.

at PKHeX.PersonalTable.get_Item(Int32 index)

at PKHeX.PK2.get_Gender()

at PKHeX.PKX.getSprite(PKM pkm)

at PKHeX.PKM.get_Sprite()

at PKHeX.Main.getSlotFiller(Int32 offset, PictureBox pb)

at PKHeX.Main.setPKXBoxes()

at PKHeX.Main.getBox(Object sender, EventArgs e)

at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)

at System.Windows.Forms.ComboBox.set_SelectedIndex(Int32 value)

at PKHeX.Main.clickBoxRight(Object sender, EventArgs e)

at System.Windows.Forms.Control.OnClick(EventArgs e)

at System.Windows.Forms.Button.OnClick(EventArgs e)

at System.Windows.Forms.Button.WndProc(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************

mscorlib

Assembly Version: 4.0.0.0

Win32 Version: 4.6.1055.0 built by: NETFXREL2

CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll

----------------------------------------

PKHeX

Assembly Version: 1.0.0.0

Win32 Version: 1.0.0.0

CodeBase: file:///C:/Users/Morgan-pc/Desktop/PKHeX.exe

----------------------------------------

System.Core

Assembly Version: 4.0.0.0

Win32 Version: 4.6.1055.0 built by: NETFXREL2

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

----------------------------------------

System

Assembly Version: 4.0.0.0

Win32 Version: 4.6.1075.0 built by: NETFXREL3STAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

----------------------------------------

System.Windows.Forms

Assembly Version: 4.0.0.0

Win32 Version: 4.6.1055.0 built by: NETFXREL2

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

----------------------------------------

System.Drawing

Assembly Version: 4.0.0.0

Win32 Version: 4.6.1068.2 built by: NETFXREL3STAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

----------------------------------------

System.Configuration

Assembly Version: 4.0.0.0

Win32 Version: 4.6.1055.0 built by: NETFXREL2

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

----------------------------------------

System.Xml

Assembly Version: 4.0.0.0

Win32 Version: 4.6.1064.2 built by: NETFXREL3STAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

----------------------------------------

************** JIT Debugging **************

To enable just-in-time (JIT) debugging, the .config file for this

application or computer (machine.config) must have the

jitDebugging value set in the system.windows.forms section.

The application must also be compiled with debugging

enabled.

For example:

<configuration>

<system.windows.forms jitDebugging="true" />

</configuration>

When JIT debugging is enabled, any unhandled exception

will be sent to the JIT debugger registered on the computer

rather than be handled by this dialog box.

What my box 10 looks like in Pkhex (I compiled the latest one from your github) VS on emulator:

My box 10 actually contains 2 normal eggs, 1 shiny gyarados, and 4 Eggs named "gyarados",

that were actually a shiny gyarados that was transformed into Eggs via Arbitrary code execution (

)

so at this point, the 4 eggs are probably species: Egg, so that I can then change their species to whatever I want and hatch whatever shiny I want

(species ID is 0xFD, obtained from http://glitchcity.info/biglist.htm)

While technically not a naturally occurring glitch,

I imagine that via cloning and obtaining bad eggs, these may occur,

so at least treating 252 - 255 as bad eggs may help with handling them in the program.

[SciresM]

To be honest:

With Rhydon, I explicitly did not support Gen I saves that had been modified via the use of glitches/out-of-bounds IDs. I do not think PKHeX should make any attempt to defend against user-corrupted saves in the specific case of Gen I/II (Gen VI/VII are a different story, of course). If using arbitrary code execution will cause errors like this, I don't think PKHeX has any obligation to resolve those errors -- the user can use arbitrary code execution to unscrew their save first.

[theSLAYER]

To be honest:

With Rhydon, I explicitly did not support Gen I saves that had been modified via the use of glitches/out-of-bounds IDs. I do not think PKHeX should make any attempt to defend against user-corrupted saves in the specific case of Gen I/II (Gen VI/VII are a different story, of course). If using arbitrary code execution will cause errors like this, I don't think PKHeX has any obligation to resolve those errors -- the user can use arbitrary code execution to unscrew their save first.

Well, it's not that the pkhex and the save was unusable;

After the error prompt,

Everything else just works as normal.

To that extent I think you're right that people who can use arbitrary execution can always undo the mess they did,

And pkhex has no obligation to resolve these situations.

(I could just give me eggs a species in game, it'll probably bypass this)

As I'm using a version I compiled myself, perhaps handling out of bounds wasn't implemented yet.

(I assume it would have been, because other generations had sanity checks and bad egg recognition)

I was just bringing up the issue with my "eggs", and I'm okay with whatever decision that will be made to deal (or not deal) with these type of scenarios, before it happens in the future

[Metropolis]

It's good practice to tolerate out of bound values or auto-correct them rather than throwing a stack trace.

[Kaphotics]

Snuck in a commit a few days ago to hopefully address this.