Below I document the technical work I have completed so far while analyzing and modifying both executables (dekaron.exe and DekaronServer.exe) using x32dbg.
------------------------------------------------------------
1. Debug Monitor Activation (DBMON / DebugView)
------------------------------------------------------------
The client contains multiple internal calls to OutputDebugStringA, but these are disabled through conditional jumps that prevent the debug messages from reaching DebugView.
Typical original structure:
By replacing the conditional jumps (jz, jnz, etc.) with NOP sequences, the client becomes forced to execute OutputDebugStringA every time. After patching these, the client begins outputting all internal strings (loading process, failures, warnings, internal states) directly to DebugView or any DBMON-compatible monitor.
This modification significantly improves analysis when debugging client behavior.
------------------------------------------------------------
2. Increasing Dill Limit in the Client
------------------------------------------------------------
The hardcoded limit for Dill is:
1,000,000,000 decimal = 0x3B9ACA00
Inside the client, this value appears in multiple checks and assignments, typically in the form:
To extend the maximum to:
I replaced all relevant occurrences:
AFTER:
It is important to avoid modifying LEA instructions or any use of the value that is not part of cap validation. After confirming integrity, I exported the patched binary through x32dbg’s Patch Manager.
------------------------------------------------------------
3. Increasing Dill Limit in the Server
------------------------------------------------------------
The server executable contained the same hardcoded limit.
Example of a located region:
After modification:
Since the SQL schema already uses BIGINT for money storage, no database modification was necessary. After replacing the executable and clearing active sessions, the server correctly handled savings and transfers up to the new limit.
------------------------------------------------------------
4. Current Status of HP / MP Limit Research
------------------------------------------------------------
I searched for strings such as:
Update HP MP SD
LoadInfo HP
LoadInfo MP
byHPRecoveryFactor
byMPRecoveryFactor
These routine references only handle regeneration, printing or structure loading. They do not define the maximum HP/MP values.
In Dekaron, the HP/MP limit usually derives from:
• 16-bit internal structures
• packet format constraints
• indirect clamps applied after calculations
Since 0xFFFF appears thousands of times across the executable, identifying the true limitation point requires analyzing value flow inside packets and stat structures rather than simply replacing a constant.
The research continues, and collaboration is welcome. Once this is solved, I plan to release a full tutorial, just as I did with the extended Dill limit.
------------------------------------------------------------
Final Notes
------------------------------------------------------------
This post is intended as a technical guide so that anyone can apply similar improvements to their own servers. Those who need more personalized assistance or custom executable modifications may contact me, as I also provide those services when required.
-------------------------------------------------------------
[ESPAÑOL]
Con el paso del tiempo dependí del trabajo y la guía de varios miembros de esta comunidad como HellSpider, guesswho-.-, Greax, Zarashi y Darijus. Sus aportes fueron esenciales para el desarrollo de muchos servidores, incluido el mío. Al encontrarme recientemente con problemas que ya nadie parecía abordar, decidí estudiar ASM e ingeniería inversa por fuerza mayor. Este post busca demostrar a ellos y a la comunidad que aún existen personas con interés en aprender, compartir y reactivar esta sección de Dekaron, que muchos consideramos prácticamente inactiva.
A continuación detallo el trabajo técnico realizado analizando y modificando ambos ejecutables (dekaron.exe y DekaronServer.exe) utilizando x32dbg.
------------------------------------------------------------
1. Activación del Debug Monitor (DBMON / DebugView)
------------------------------------------------------------
El cliente posee múltiples llamadas internas a OutputDebugStringA, pero vienen deshabilitadas mediante saltos condicionales que bloquean la salida hacia DebugView.
Estructura original típica:
Al reemplazar los saltos condicionales (jz, jnz, etc.) por NOP, el cliente queda obligado a ejecutar la llamada siempre. Después del parche, todas las cadenas internas (carga de recursos, errores, advertencias, estados) comenzaron a mostrarse en DebugView.
Esto facilita enormemente el análisis del comportamiento del cliente.
------------------------------------------------------------
2. Aumento del límite de Dill en el cliente
------------------------------------------------------------
El límite duro original es:
En el cliente aparece en comparaciones y asignaciones como:
Para extender el límite a:
4.000.000.000 decimal = 0xEE6B2800
Reemplacé todas las coincidencias relevantes:
ANTES:
DESPUÉS:
Se debe evitar alterar instrucciones LEA o usos que no correspondan al tope del valor. Después de verificar la integridad, exporté el ejecutable parchado usando Patch Manager de x32dbg.
------------------------------------------------------------
3. Aumento del límite de Dill en el servidor
------------------------------------------------------------
El servidor también contenía el mismo tope embebido.
Ejemplo de zona encontrada:
Tras modificación:
Las tablas SQL ya utilizaban BIGINT, así que no fue necesario modificar la base de datos. Reemplazado el ejecutable y cerradas las sesiones activas, el servidor comenzó a registrar y validar el nuevo límite correctamente.
------------------------------------------------------------
4. Estado actual de la investigación del límite de HP / MP
------------------------------------------------------------
Busqué cadenas como:
Update HP MP SD
LoadInfo HP
LoadInfo MP
byHPRecoveryFactor
byMPRecoveryFactor
Estas solo imprimen valores o administran regeneración. No definen el máximo HP/MP.
En Dekaron, el límite suele provenir de:
• estructuras internas de 16 bits
• formato de paquetes
• clamps indirectos posteriores a cálculos
Como 0xFFFF aparece miles de veces dentro del ejecutable, encontrar el punto real del clamp requiere analizar estructuras y flujo de paquetes, no solo reemplazar constantes.
La investigación continúa. Quien desee colaborar es bienvenido. Cuando se logre resolver publicaré un tutorial completo, igual que con el método para ampliar el Dill.
------------------------------------------------------------
Notas finales
------------------------------------------------------------
Este post sirve como guía para que todos puedan aplicar mejoras en sus servidores. Quienes necesiten asesoría más personalizada o modificaciones sobre sus ejecutables también pueden solicitar ese tipo de trabajo.
