Socket byte encoding overflows for seed-sphere Level 5 on any element other than Fire, crashing the client

[didiconcs]

Summary

ItemSerializerHelper.SetSocketBytes encodes each socket's seed-sphere level + element + option number into a single byte:

var optionIndex = SocketOptionIndexOffsets[elementType] + elementOption;
return (byte)((sphereLevel * MaximumSocketOptions) + optionIndex);

(src/GameServer/RemoteView/ItemSerializerHelper.cs:141-146, MaximumSocketOptions = 50, SocketOptionIndexOffsets = { 0, 10, 16, 21, 29, 36 } for Fire/Water/Ice/Wind/Lightning/Earth respectively, line 62)

For sphereLevel = 5 (the maximum socket bonus tier) on any element other than Fire, sphereLevel * 50 + optionIndex starts at 250 + 10 = 260 for Water and only grows for the later elements, this exceeds byte.MaxValue (255) and silently wraps around via the implicit (byte) cast, producing a completely unrelated index. Fire is the only element that stays in range at level 5 (250 + optionIndex(0..5) ≤ 255).

Example: level 5, Water, option number 4 → optionIndex = 10 + 4 = 14 → 250 + 14 = 264 → cast to byte → 8 (wrapped), instead of a value the client can make sense of.

Impact, reachable through normal gameplay, not just admin tools

This isn't limited to GM/SQL-crafted items. Tracing the standard crafting chain:

• "Seed Creation" (Seed Master NPC) randomly rolls a Seed's Level up to ItemDefinition.MaximumItemLevel, which is 5 for every element alike (Fire, Water, Ice, Wind, Lightning, Earth), CreateSeed() computes it from the same per-element ItemOptionDefinition that's also used for the corresponding Seed Sphere (src/Persistence/Initialization/VersionSeasonSix/Items/SocketSystem.cs).
• "Seed Sphere Creation" copies that level onto the resulting Seed Sphere (SeedSphereCrafting.cs: result.Level = seed.Level).
• "Mount Seed Sphere" copies it again onto the equipped item's socket (MountSeedSphereCrafting.cs: sphereOption.Level = seedSphere.Level).

So a player who legitimately rolls a Level-5 Water/Ice/Wind/Lightning/Earth seed through normal RNG and mounts it ends up with an item whose socket byte silently wraps around on every serialization. When that item is sent to a client (equipped, viewed in a shop/trade window, shown to another player, etc.), the corrupted byte is used by the client to index into a fixed-size table. We reproduced this with a real client (Season 6, English protocol build): it writes out of bounds and crashes immediately with a stack-corruption error (Run-Time Check Failure #2 - Stack around the variable 'iSeedSum' was corrupted) as soon as the item is loaded/rendered.

Suggested fix

The offset table was reverse-engineered from the original client/protocol (per the comment on line 59, "found these index offsets by trial and error"), so the safe range is a client-side constraint OpenMU should defend against server-side rather than assume is never reached:

• Cap ItemDefinition.MaximumItemLevel for non-Fire Seeds/Seed Spheres at 4 instead of 5 (the safe range holds for every element through level 4: 4*50 + maxOptionIndexForThatElement ≤ 255), or
• Rework the encoding so level 5 fits in a byte for every element, if that's what the real client protocol expects.

Either way, an explicit bounds check (or at least a guarding comment) would help, today even the AdminPanel's item option editor lets you freely set Level=5 on a non-Fire socket option with no warning, so the unsafe state is easy to reintroduce even after a data fix.

Environment

• Confirmed against origin/master (commit b29338b78).
• Reproduced with a real MuMain (Season 6, English protocol) client, crash occurs immediately on entering the map with the affected item equipped.

[sven-n]

The internal maximum level probably needs to be 4. There are only 5 tiers of seed sphere levels.
Need to check this in the client sources first, I guess.

[didiconcs]

Hi @sven-n,

Followed up on this in the client source. Short answer: internal max level 4 is correct, and it applies uniformly to all six elements, not on a per-element basis, even though the raw byte-overflow arithmetic itself is element-specific (as you'd expect from the different offsets).

1. Confirmed the client's decode formula, matching the server-side encoding

The client stores each socket's raw byte and decodes it as exactly the inverse of (seedLevel * 50) + offset + optionNumber:

// src/source/UI/NewUI/Inventory/NewUIItemMng.cpp, lines 180-181 (identical logic again at 249-250)
pNewItem->SocketSeedID[i]   = pNewItem->bySocketOption[i] % SEASON4A::MAX_SOCKET_OPTION;
pNewItem->SocketSphereLv[i] = (pNewItem->bySocketOption[i] / SEASON4A::MAX_SOCKET_OPTION) + 1;

bySocketOption[i] is declared as a single BYTE (src/source/Core/Globals/_struct.h:214), and MAX_SOCKET_OPTION = 50 (src/source/Network/Server/SocketSystem.h:13). So the client agrees with the * 50 scheme you found server-side.

2. Client-side element offsets (one discrepancy versus what's in the issue)

Hardcoded identically in two places in SocketSystem.cpp (GetSeedShpereSeedID, lines 88-108, and AttachToolTipForSeedSphereItem, lines 293-313 and 340-360):

case 1: bySocketSeedID = 0  + iLevel; break; // Fire
case 2: bySocketSeedID = 10 + iLevel; break; // Water
case 3: bySocketSeedID = 16 + iLevel; break; // Ice
case 4: bySocketSeedID = 21 + iLevel; break; // Wind
case 5: bySocketSeedID = 29 + iLevel; break; // Lightning
case 6: bySocketSeedID = 34 + iLevel; break; // Earth

So: Fire=0, Water=10, Ice=16, Wind=21, Lightning=29, Earth=34. The first five match what's in the issue, but Earth is 34 in this client, not 36. Worth double-checking SocketOptionIndexOffsets before finalizing the fix in case there's a small mismatch there (or there's a reason client and server intentionally differ that we're not seeing from the client side alone).

3. Per-element byte overflow, using the actual option counts defined in the client (SocketSystem.h:31-73, the _SOCKET_OPTION_OPTIONS enum)

Fire has 6 real options (ids 0-5), Water has 5 (10-14), Ice has 5 (16-20), Wind has 6 (21-26), Lightning has 4 (29-32), Earth has 6 (34-39, using the client's offset of 34). Plugging the highest option id per element into byte = level*50 + offset + optionNumber at level = 5 (0-indexed, i.e. what would be the 6th level):

Element	Offset	Max option id	Byte at level 5	Wraps to
Fire	0	5	255	no wrap
Water	10	14	264	8
Ice	16	20	270	14
Wind	21	26	276	20
Lightning	29	32	282	26
Earth	34	39	289	33

This lines up exactly with what we reproduced in practice: level 5 is fine for Fire (byte lands exactly on 255, the max a BYTE can hold) and overflows for every other element. So the raw overflow threshold genuinely is element-specific.

4. But level 5 is invalid for every element regardless, Fire included

Independent of the byte math, SocketSphereLv (= level + 1) is used to index m_iOptionValue[SphereLv - 1], and that array is fixed at 5 slots (int m_iOptionValue[5], SocketSystem.h:91 and :101). Level 5 (0-indexed) means SphereLv = 6, i.e. m_iOptionValue[5], one past the end of the array. There is also no backing item type for a 6th tier: the item-type enum only defines _1 through _5 for every element (_enum.h:2662-2691, e.g. ITEM_SEED_SPHERE_FIRE_5 = ITEM_WING + 124; no _6 exists anywhere for any element). So even for Fire, where the byte itself doesn't wrap, level 5 is still an out-of-bounds read into m_iOptionValue and doesn't correspond to any real sphere tier in the client.

Conclusion: internal max level = 4, uniformly across all six elements. This isn't a coincidence: the client's real, structural cap is the 5-slot value table / 5-tier item enum (MAX_SPHERE_LEVEL = 5, SocketSystem.h:15), and the byte-overflow arithmetic for 5 of the 6 elements happens to enforce that same limit independently. Fire is the one element where only the array-bound check catches it, since its byte value alone doesn't overflow at level 5.

Bonus: a concrete candidate for the exact crash mechanism

The crash you're chasing matches a real variable name in this code. CSocketItemMgr::CheckSocketSetOption() (SocketSystem.cpp:425-459) declares:

int iSeedSum[6] = { 0, 0, 0, 0, 0, 0 };
...
pInfo = &m_SocketOptionInfo[SOT_SOCKET_ITEM_OPTIONS][pItem->SocketSeedID[j]];
++iSeedSum[pInfo->m_iOptionCategory - 1];   // SocketSystem.cpp:441

_SOCKET_OPTION_CATEGORY (SocketSystem.h:18-29) starts at SOC_NULL = 0. If an overflowed/wrapped bySocketOption byte decodes to a SocketSeedID that lands on an unused/reserved slot of the 50-entry option table (% 50 guarantees the index itself is always in-bounds for the table, but the slot's content is undefined/never populated for those reserved ids, e.g. Fire's options 6-9), pInfo->m_iOptionCategory reads back as SOC_NULL (0), and iSeedSum[0 - 1] becomes a negative array index, an out-of-bounds stack write immediately adjacent to iSeedSum. That matches "Stack around the variable 'iSeedSum' was corrupted" exactly.

CheckSocketSetOption() is called from CHARACTER_MACHINE::CalculateAll() (ZzzInfomation.cpp:3543), which runs on equipment/stat recalculation, consistent with the crash triggering on equipping the affected item.

We can't fully verify this last mechanism against the live binary data file (Data/Local/*/SocketItem_*.bmd), since it isn't part of this source tree, only the code that reads it. But it's consistent with every fact we have, including which specific element(s) reproduce the crash and which don't.

Let me know if it'd help to pull anything else out of this tree.