# Reverse Engineering Analysis Workflow

Find functions needing documentation by prioritizing those with the most cross-references (xrefs), as these are typically more important to the codebase. Focus on functions still named with patterns like "FUN_" which indicate they haven't been analyzed yet.

When documenting functions, rename them using PascalCase convention based on their purpose and how they're used by callers. Names should clearly describe what the function does, such as ProcessPlayerSlots, ValidateEntityState, or InitializeGameResources. Examine the function's callees and the context from xrefs to understand the function's role in the larger system.

Set the function's return data type accurately by analyzing what value is returned and how calling functions use that value. Common return types include void for functions with no return value, int or DWORD for status codes or counts, BOOL for true/false conditions, and pointers for object references. Define the function prototype with all parameters properly typed and named, and specify the calling convention such as __cdecl, __stdcall, __fastcall, or __thiscall based on how parameters are passed and the stack is managed.

Rename all variables and parameters using descriptive names without prefixes like "local_" or "param_". Use camelCase for variables such as playerIndex, bufferSize, or entityPointer. When register artifacts are meaningful to understanding data flow, include them in variable names like eax_returnValue or ecx_objectPointer. Focus on the variable's purpose in the algorithm rather than its storage location.

Create or rename labels at jump targets using snake_case convention with names that describe their purpose. Common patterns include loop_start and loop_continue for iteration control, validation_failed and check_bounds for conditional logic, error_handler and cleanup_and_exit for error paths, and state_0_init or state_1_processing for state machines. These labels make the control flow easier to follow in both disassembly and decompiled views.

Add appropriate data structures and types for memory locations referenced by the code. When you see structure access patterns, identify common Diablo II data types from the codebase. Key structure types include UnitAny for game entities with fields like dwType, dwUnitId, dwMode, pInventory, pStats, wX, and wY. Room and level structures include Room1 and Room2 for map data with fields like pRoom2, dwPosX, dwPosY, dwSizeX, dwSizeY, and pLevel. Player data structures use PlayerData with szName, pNormalQuest, pNightmareQuest, pHellQuest, and waypoint pointers. Item structures use ItemData with dwQuality, dwItemFlags, wPrefix, wSuffix, BodyLocation, and pOwnerInventory. Monster structures use MonsterData with behavior flags, anEnchants, wUniqueNo, and wName. Inventory structures use fields like pOwner, pFirstItem, pCursorItem, and dwItemCount. Pointer types commonly use LP prefix like LPUNITANY, LPROOM1, LPROOM2, or LPLEVEL for entity pointers.

Common field naming patterns include using Hungarian notation with dw prefix for DWORD values like dwFlags or dwUnitId, p or lp prefix for pointers like pNext or lpPlayerUnit, w prefix for WORD values like wLevel or wStatIndex, n prefix for counts like nCount or nMaxXCells, sz prefix for null-terminated strings like szName or szGameName, and f or b prefix for boolean flags like fSaved or bActive. Position fields typically use dwPosX and dwPosY while size fields use dwSizeX and dwSizeY.

Add comments in both decompiler and disassembly views to explain the code's purpose and behavior. Decompiler comments should provide algorithm context explaining what the code section accomplishes, describe structure access patterns and what fields mean, explain magic numbers and sentinel values, document validation logic and boundary checks, and note edge cases and error handling. Keep disassembly comments concise within 32 characters, focusing on what each instruction does like "Load player slot index", "Check if slot active", "Jump to error handler", or "Call cleanup routine". Add a high-level summary comment in the function header describing the overall algorithm, key parameters, return values, and any important preconditions or side effects.

Define all undefined variables that appear in the decompiled output. Ghidra may show variables like undefined1, undefined2, undefined4, or undefined8 which should be replaced with proper types. Map these to appropriate types: undefined1 becomes BYTE, undefined2 becomes WORD, undefined4 becomes DWORD or pointer, and undefined8 becomes QWORD. Look at how the variable is used to determine if it should be a numeric type, a pointer, or part of a structure.

Work silently without showing status messages or progress output. Do not create or edit any files as all documentation changes should be made directly within Ghidra. Apply all function renaming, variable typing, structure creation, label creation, and commenting operations through the Ghidra MCP tools. Use batch operations when available to improve efficiency, such as batch_set_comments for adding multiple comments at once, batch_set_variable_types for typing multiple variables, and batch_create_labels for creating multiple jump target labels. After completing documentation for each function, immediately search for the next undocumented function and repeat the process, continuing until all critical functions have been analyzed.