Newbie Spellweaver
- Joined
- Jun 12, 2026
- Messages
- 22
- Reaction score
- 2
CrossFire 1.0 — 2012 | Research & Reconstruction Project
Hello, I'm JonyLiveBR, and I'm starting a new project focused on CrossFire 1.0, based on the 2012 version.The goal is to study, understand, document, and gradually reconstruct the environment required to run this old version of CrossFire, instead of simply relying on old server packages found on the internet.
Everything is being developed and tested locally, in a controlled environment, strictly for study, research, preservation, and development purposes.
The project is based exclusively on materials, files, clients, server packages, and information that have already been publicly available on the internet.
Why am I doing this?
Over the years, several old CrossFire server packages have been shared online. These materials are extremely useful for understanding how older versions of the game worked, but there is a major problem:Some of these packages have been modified by third parties and may contain malware, trojans, backdoors, hacks, suspicious DLLs, or modified executables that are unrelated to the legitimate operation of the original server.
During my tests, I also noticed that some suspicious components may affect other files after being executed.
This can create a chain reaction: you start with a few compromised files and, after running the environment, additional executables or components may also become affected.
A common explanation is that these detections happen simply because the software is old or incompatible with modern versions of Windows.
While compatibility issues and false positives can certainly exist with old software, my analysis has also found cases involving files that appear to have actually been modified or compromised.
Because of this, I decided to take a different approach.
Reconstructing the server
Instead of downloading an old package and trusting everything inside it, I'm analyzing the CrossFire 1.0 / 2012 architecture component by component.This includes studying:
- EXE files;
- DLL libraries;
- dependencies;
- server services;
- communication between services;
- executable paths;
- configuration files;
- database communication;
- client/server communication;
- server initialization procedures;
- internal file structures.
Whenever possible, I'm working toward recreating or replacing components instead of permanently depending on unknown legacy binaries.
Using publicly available server files as reference material, I have already been able to get a server environment running with practically no errors during gameplay.
That working environment provides an important reference for understanding what each service expects and what is actually required for the game to operate.
Breaking old client limitations
Another important part of this research involves the limitations commonly associated with old CrossFire clients.One example is the claim that adding additional weapons or expanding certain structures in these old clients is impossible because of fixed limits.
During my research, I managed to work around some of these limitations by expanding the available space in certain structures instead of remaining restricted to the original allocated size.
This opens the possibility of researching additional content while preserving the characteristics and gameplay of the old CrossFire versions.
Custom CrossFire tools
I'm also developing my own tools to read, analyze, and edit CrossFire files.Instead of depending entirely on old tools of unknown origin, the goal is to gradually create a cleaner development environment where the game's structures can be studied and modified in a controlled way.
As the research progresses, these tools should also make it easier to document the formats and structures used by this version of the game.
Daily Development Reports
I also want this project to be documented from the beginning.For this reason, every day I will publish a development report describing what happened during that day's work.
These reports may include:
- what was analyzed;
- files and components being studied;
- problems and incompatibilities discovered;
- solutions that were tested;
- successful and unsuccessful experiments;
- progress with the server and client;
- development of new tools;
- discoveries made through reverse engineering;
- modifications and improvements;
- current problems;
- and the next steps planned for the project.
The idea is to document the real development process — including the problems, failed attempts, solutions, and discoveries along the way.
Over time, these daily reports will create a complete development history of the project and may also become useful technical documentation for people interested in researching old CrossFire versions.
The objective
The objective is not simply to put another private server online.I want to understand the architecture behind this version of CrossFire and create a cleaner, documented, reproducible, and understandable environment for research and preservation.
Every executable, DLL, dependency, configuration, and required path is being analyzed individually.
This is a long process. We are dealing with software and infrastructure from around 2012, and much of the original technical documentation is no longer easily available.
But that is exactly what makes documenting this process interesting.
If you're interested in old-school CrossFire, reverse engineering, game preservation, server development, or modding, you're welcome to follow the project and its daily progress.
Developer: JonyLiveBR
Discord:
To view the content, you need to sign in or register
Telegram:
To view the content, you need to sign in or register
YouTube:
To view the content, you need to sign in or register
CrossFire 1.0 • 2012 • Reverse Engineering • Research • Development • Game Preservation
CrossFire 1.0 — 2012 | Projeto de Estudo e Reconstrução
Olá! Eu sou o JonyLiveBR e estou iniciando um novo projeto focado no CrossFire 1.0, baseado na versão de 2012.O objetivo é estudar, compreender, documentar e reconstruir gradualmente o ambiente necessário para executar essa antiga versão do CrossFire, em vez de simplesmente depender dos antigos pacotes de servidor encontrados na internet.
Todo o desenvolvimento e todos os testes estão sendo realizados localmente, em ambiente controlado, exclusivamente para fins de estudo, pesquisa, preservação e desenvolvimento.
O projeto utiliza exclusivamente como referência materiais, arquivos, clientes, pacotes de servidor e informações que já foram disponibilizados publicamente na internet.
Por que estou fazendo isso?
Ao longo dos anos, diversos pacotes antigos de servidores de CrossFire foram compartilhados na internet. Esse material é extremamente útil para entender o funcionamento das versões antigas do jogo, mas existe um grande problema:Alguns desses pacotes foram modificados por terceiros e podem conter malwares, trojans, backdoors, hacks, DLLs suspeitas ou executáveis modificados que não possuem relação com o funcionamento legÃtimo do servidor original.
Durante meus testes, também percebi que determinados componentes suspeitos podem afetar outros arquivos depois de executados.
Isso pode criar um efeito em cadeia: você começa com alguns arquivos comprometidos e, depois de executar aquele ambiente, outros executáveis ou componentes também podem acabar sendo afetados.
É comum encontrar a explicação de que essas detecções acontecem simplesmente porque os arquivos são antigos ou incompatÃveis com versões modernas do Windows.
Embora problemas de compatibilidade e falsos positivos realmente possam existir em softwares antigos, durante minhas análises também encontrei situações envolvendo arquivos que aparentam ter sido efetivamente modificados ou comprometidos.
Por esse motivo, decidi seguir outro caminho.
Reconstruindo o servidor
Em vez de simplesmente baixar um pacote antigo e confiar em tudo que existe dentro dele, estou analisando a arquitetura do CrossFire 1.0 / 2012 componente por componente.O trabalho envolve o estudo de:
- arquivos EXE;
- bibliotecas DLL;
- dependências;
- serviços do servidor;
- comunicação entre os serviços;
- caminhos utilizados pelos executáveis;
- arquivos de configuração;
- comunicação com o banco de dados;
- comunicação entre cliente e servidor;
- processo de inicialização dos serviços;
- estruturas internas dos arquivos.
Sempre que possÃvel, estou trabalhando na recriação ou substituição de componentes, evitando depender permanentemente de binários antigos e de origem desconhecida.
Utilizando os arquivos já disponibilizados publicamente na internet como material de referência, já consegui colocar um ambiente de servidor em funcionamento com praticamente nenhum erro durante as partidas.
Esse ambiente funcional serve como uma referência importante para entender o que cada serviço espera e o que realmente é necessário para o funcionamento do jogo.
Superando limitações dos clientes antigos
Outra parte importante da pesquisa envolve algumas limitações normalmente atribuÃdas aos clientes antigos do CrossFire.Um exemplo é a afirmação de que seria impossÃvel adicionar novas armas ou expandir determinadas estruturas nesses clientes devido a limites fixos.
Durante minhas pesquisas, consegui trabalhar em algumas dessas limitações, aumentando o espaço disponÃvel em determinadas estruturas em vez de permanecer limitado ao tamanho originalmente reservado.
Isso abre possibilidades interessantes para estudar a implementação de novos conteúdos sem abandonar as caracterÃsticas e a jogabilidade das versões antigas do CrossFire.
Ferramentas próprias para CrossFire
Também estou desenvolvendo minhas próprias ferramentas para ler, analisar e editar arquivos do CrossFire.Em vez de depender completamente de ferramentas antigas e de origem desconhecida, a ideia é construir gradualmente um ambiente de desenvolvimento mais limpo, onde as estruturas utilizadas pelo jogo possam ser estudadas e modificadas de maneira controlada.
Conforme a pesquisa avançar, essas ferramentas também poderão ajudar na documentação dos formatos e estruturas utilizados por essa versão.
Relatórios diários de desenvolvimento
Também quero que todo esse projeto fique documentado desde o inÃcio.Por isso, todos os dias pretendo publicar um relatório mostrando o que aconteceu durante aquele dia de desenvolvimento.
Os relatórios poderão incluir:
- o que foi analisado;
- arquivos e componentes estudados;
- problemas e incompatibilidades encontrados;
- soluções testadas;
- testes que funcionaram e testes que falharam;
- progresso no servidor e no cliente;
- desenvolvimento de novas ferramentas;
- descobertas feitas através da engenharia reversa;
- modificações e melhorias realizadas;
- problemas que ainda precisam ser resolvidos;
- próximos passos do projeto.
A intenção é mostrar o desenvolvimento como ele realmente acontece — incluindo problemas, tentativas que não funcionaram, soluções encontradas e descobertas feitas durante o caminho.
Com o tempo, esses relatórios formarão um histórico completo da evolução do projeto e também poderão servir como documentação técnica para outras pessoas interessadas em estudar versões antigas do CrossFire.
Objetivo do projeto
O objetivo não é simplesmente colocar mais um servidor privado online.Quero compreender a arquitetura por trás dessa versão do CrossFire e construir uma base mais limpa, documentada, reproduzÃvel e compreensÃvel para estudo e preservação.
Cada executável, DLL, dependência, configuração e caminho necessário está sendo analisado individualmente.
É um processo demorado. Estamos trabalhando com software e infraestrutura de aproximadamente 2012, e grande parte da documentação técnica original já não está facilmente disponÃvel.
Mas é justamente por isso que considero importante documentar esse trabalho.
Se você também gosta de CrossFire antigo, engenharia reversa, preservação de jogos, desenvolvimento de servidores ou modding, está convidado a acompanhar diariamente a evolução do projeto.
Desenvolvedor: JonyLiveBR
Discord:
To view the content, you need to sign in or register
Telegram:
To view the content, you need to sign in or register
YouTube:
To view the content, you need to sign in or register
CrossFire 1.0 • 2012 • Engenharia Reversa • Pesquisa • Desenvolvimento • Preservação de Jogos
[DEV LOG #01] CrossFire 1.0 — Rebuilding the Server from Scratch
Clean gDBGW Reconstruction & Compatibility Research
Hello, I'm JonyLiveBR.Before anything else, I want to thank CoderCF for publicly sharing a package containing CrossFire 1.0 Server Files, Client, and Databases.
Finding a complete package like this is extremely rare.
Most of the time, when researching old CrossFire versions, you only find isolated databases, incomplete clients, old tools, or server files from different revisions. Then you have to figure out which files are compatible with each other and make the client, server, and database work together.
Having Client + Server Files + Databases from the same environment is extremely valuable for anyone studying or preserving old versions of the game.
Original post:
https://forum.ragezone.com/threads/...iles-and-tools-client-cf-ph-gameclub.1229454/
Special thanks again to CoderCF for preserving and sharing this material.
Why am I doing this project?
There is growing concern within the Brazilian CrossFire community about the long-term future of CrossFire Brazil, including rumors and discussions about a possible shutdown of Brazilian operations in the future.I am not treating those rumors as officially confirmed information.
Regardless of whether that eventually happens or not, I believe it is important to study and document old CrossFire versions while this material is still available.
The purpose of this project is strictly:
- technical study;
- research;
- reverse engineering;
- documentation;
- preservation;
- software development.
I am using only materials, clients, databases, tools, and server files that have already been publicly shared on the internet.
My CrossFire archive
Over the years, I have collected a large amount of material related to CrossFire.At the moment, my archive contains more than 700 GB of files, including:
- Clients;
- Server Files;
- Databases;
- Tools;
- Configuration files;
- Test builds;
- Old versions;
- CrossFire 1.0 material;
- CrossFire 2.0 material;
- CrossFire 3.0 material.
The recurring problem has almost always been the same:
Suspicious or malicious files.
I have found environments that were functional as game servers but contained suspicious executables, DLLs, tools, or other components.
This is one of the main reasons I decided to approach the project differently.
The problem with old server packages
There is a common belief that antivirus software detects these files only because they are old.Sometimes that is true.
Old software can trigger:
- false positives;
- compatibility warnings;
- detections caused by obsolete compilers;
- old libraries;
- behaviors considered suspicious by modern security software.
Some packages appear to contain components that may participate in a real infection chain.
Example:
Compromised file is executed
↓
Other files or components are modified
↓
Additional executables begin showing suspicious behavior
↓
The entire environment becomes increasingly compromised
This can create a snowball effect.
Because of that, simply adding antivirus exclusions is not acceptable for what I want to build.
My approach is different:
The first major component selected for this work is:
gDBGW.exe
What is
The gDBGW.exe executable works as a gateway between the CrossFire server executables and the SQL Server databases.The game services do not necessarily access SQL Server directly.
They primarily communicate through:
DBGWManager.dll
The DLL communicates with the gateway through TCP.
Observed architecture:
CrossFire Server
↓
DBGWManager.dll
↓
TCP 127.0.0.1:6666
↓
gDBGW
↓
Selects the corresponding database alias
↓
SQL Server
Rebuilding gDBGW correctly is therefore one of the key steps toward replacing unknown legacy components.
1. Initialization
The gateway mainly uses two configuration files:C:\pmang\gDBGW\gDBGW.ini
C:\pmang\DBGWMGR.ini
The gDBGW.ini file contains information such as:
- TCP port;
- SQL Server addresses;
- databases;
- aliases;
- connection pool sizes;
- ping intervals;
- reconnection settings;
- logging options;
- internal gateway settings.
6666
Main database aliases identified:
| Alias | Database |
|---|---|
| CF_GAMEDB | CF_PH_GAME |
| CF_GUILDDB | CF_PH_GUILD |
| CF_LOGDB | CF_PH_LOG |
| CF_BILLDB | MICROGAMESBILL_DB |
| CF_AUTHDB | MYGAME_MEMBER |
2. Connection Pools
gDBGW does not necessarily work with only one SQL connection per database.It maintains a connection pool for each alias.
In the current INI configuration, approximately:
10 connections per database
are requested.
The gateway also needs to manage:
- periodic connection checks;
- reconnection after failure;
- selection of an available connection;
- timeouts;
- pause;
- resume;
- connection pool state.
3. Server Authentication
When DBGWManager.dll starts communicating with the gateway, it sends an authentication request.Observed fields include:
- frame size;
- message tag;
- server SSN;
- authentication/test query.
Tag: 1
Type: ConnectReq
SSN: 318
Query: select 1
Tag: 1
Type: ConnectReq
SSN: 318
Query: select 1
Expected gateway response:
Tag: 2
Type: ConnectAns
Error: 0
This behavior has already been reproduced in the clean executable being developed.
Most importantly:
THE ORIGINAL DLL ACCEPTED THE RESPONSE.
4. Receiving Queries
After authentication, the DLL starts sending actual requests.The request contains information such as:
- query type or priority;
- request ID;
- payload size;
- command text.
ALIAS|TYPE|COMMAND|PARAMETERS...
Direct SQL example:
CF_GAMEDB|Q|select CODE_NAME from CF_REF_CODE where MAIN_CODE='36091'
Stored procedure example:
CF_GAMEDB|S|GSP_AL_SERVER_CANCEL|1
Main types identified:
Q = SQL Query
S = Stored Procedure
5. DBGWMGR.ini Catalog
The file:acts as a catalog of accepted queries and their parameters.
Conceptual example:
Q6=SP_USER_NICK_CHECK|p_i_nick|I|STR|p_o_result|R|INT
Observed directions:
I = Input
O = Output
R = Return
Observed data types include:
INT
BIG
STR
Other types may also be used depending on the specific version.
The gateway validates information such as:
- whether the query exists;
- number of parameters;
- parameter names;
- parameter direction;
- parameter type;
- corresponding database alias.
6. SQL Server Execution
After interpreting a request, the gateway needs to:- identify the alias;
- select an available SQL connection;
- locate the query definition;
- convert incoming values;
- create SQL parameters;
- execute the command;
- collect rows and columns;
- collect output parameters;
- collect stored procedure return values;
- serialize the result.
- NULL values;
- timeouts;
- SQL errors;
- reconnections;
- invalid parameters;
- invalid queries.
7. Result Format
Another important part of the reconstruction was identifying how results are returned to the server.The result is converted into a text structure delimited by:
|
Examples observed:
S|0|
This may represent a successful query with no additional data.
Another example:
S|0|0|
Larger responses may look like:
S|0|01|QA|QA|-1|3000|192.168.1.5|10008|0|...
When multiple rows are returned, the values are serialized sequentially.
The service that made the request already knows the expected structure for that query and can interpret the columns.
Stored procedures can also produce responses such as:
S|1|
The exact meaning of the second field may depend on the specific operation.
8. Response to
The gateway returns a new frame containing approximately:- frame size;
- Tag 3;
- request ID;
- result size;
- serialized result.
During tests with the reconstructed gateway, we already received:
DBGWMInit result=1 error=0
and:
ExecuteQuery result=1 error=0
This confirms that important parts of the protocol expected by the original DBGWManager.dll are already being reproduced.
9. Heartbeat and Maintenance
The original gDBGW does much more than receive a query and execute SQL.Other observed or expected systems include:
- heartbeat;
- disconnected client detection;
- reconnection;
- pause/resume;
- statistics;
- executed query counters;
- queues;
- priorities;
- profiling;
- slow query monitoring;
- connection pool control;
- performance monitoring.
10. Logs
The main log directory used by the original environment is:C:\LOG\GDBGW
These logs are extremely important for reverse engineering.
They can reveal:
- received queries;
- aliases;
- executed SQL;
- parameters;
- serialized results;
- parsing errors;
- SQL errors;
- reconnections;
- network behavior;
- gateway behavior.
Original gDBGW
↓
Observed behavior
↓
Own implementation
↓
Behavior comparison
What has already been rebuilt?
The current clean implementation already includes:
Reading gDBGW.ini- Reading DBGWMGR.ini
- Recognition of the five identified databases
- Successful connection to all five databases
- Basic connection pools
- Local TCP listener
- Port 6666
- Authentication compatible with DBGWManager.dll
- Frame reading
- Request ID identification
- Query identification
- Correlated responses
- Basic response structure:
S|0|...
- x86 build
- Execution in the local test environment
- Current build accepted by Windows Defender without detection
- complete DBGWMGR.ini query support;
- stored procedures;
- Input / Output / Return parameters;
- additional data types;
- multi-row results;
- heartbeat;
- reconnection;
- pools;
- queues;
- priorities;
- complete error handling;
- compatibility with the remaining server executables.
That is a major step for this project.
Final Objective
The objective is not simply to modify an old executable until antivirus software stops detecting it.The goal is to progressively reduce dependency on unknown legacy binaries.
The intended workflow is:
Public old files
↓
Analysis
↓
Documentation
↓
Reverse Engineering
↓
Reimplementation
↓
Compatibility Testing
↓
Controlled and understandable component
The goal is to understand each part of the CrossFire environment.
One component at a time.
Next Steps
Development of the new gDBGW will continue with focus on:- real execution of DBGWMGR.ini queries;
- stored procedures;
- Input / Output / Return parameters;
- multiple data types;
- multi-row result handling;
- heartbeat;
- reconnection;
- connection pools;
- queues;
- priorities;
- complete error handling;
- compatibility with the remaining executables.
Daily Development Reports
From now on, I intend to publish a development report every day showing what happened during the project.These daily reports may include:
- components analyzed;
- discoveries;
- file structures;
- protocols;
- problems;
- successful tests;
- failed tests;
- tools developed;
- reconstructed components;
- changes performed;
- current limitations;
- next objectives.
Sometimes an entire day may be spent understanding only a few bytes of a network packet, one function, one DLL, one structure, or one unexpected behavior.
That is exactly what I want to document:
Over time, these reports should create a complete technical history of the project.
Last edited:
