Ofuscación de BSP explicada: qué aporta a los mapas de GMod
La ofuscación de BSP modifica un mapa compilado para que funcione igual pero cueste más reconstruirlo. Cómo funciona, qué puede fallar y dónde acaba.
La ofuscación de BSP cambia la forma en que se representa un mapa compilado, de modo que el motor lo sigue cargando con normalidad mientras que las herramientas de reconstrucción dan resultados menos aprovechables. No vuelve ilegible un mapa y no es una protección anticopia. Su finalidad es que descompilarlo y seguir editándolo cómodamente resulte más laborioso.
Qué significa la ofuscación en un BSP
Quizá conozcas el término del código de programas: un script ofuscado hace lo mismo que antes, pero a una persona le cuesta seguirlo. En un mapa la idea es parecida.
Un BSP contiene dos tipos de información. El primero lo necesita el motor para renderizar y simular el mapa. El segundo ayuda sobre todo a personas y editores: rutas descriptivas, IDs de editor, restos del proceso de trabajo.
La ofuscación apunta al segundo tipo y puede trabajar en varios pasos:
- Reducir información. Lo que el motor no necesita puede desaparecer. Eso incluye los IDs de editor de las entities, además de archivos fuente, compile logs y restos de copias de seguridad que acabaron en el pakfile por descuido. A esta parte también se la llama cleanup.
- Cambiar la representación. El archivo se reconstruye de forma que ya no se corresponda tan directamente con una versión cómoda para el editor. Las rutas de materiales son un buen ejemplo: una ruta descriptiva se convierte en una neutra, y las referencias del mapa se ajustan en consecuencia.
Qué dificulta la ofuscación
- La reconstrucción automática. Un decompiler da resultados menos limpios que exigen más trabajo manual. Descompilar un BSP, explicado describe lo que normalmente devuelve un decompile.
- La orientación. Sin nombres ni rutas descriptivas se tarda más en entender un mapa ajeno.
- La reutilización de contenido. Los materiales renombrados son más difíciles de identificar y de llevar a otros proyectos.
- Las pistas sobre tu forma de trabajar. Los archivos fuente y los logs eliminados ya no revelan nada sobre carpetas, herramientas y versiones intermedias.
El mapa tiene que seguir funcionando
La condición más importante de cualquier ofuscación: el mapa tiene que cargarse y jugarse exactamente igual que antes. Eso limita lo que se puede cambiar.
| Área | Por qué hay que conservarla |
|---|---|
Nombres de entities (targetname) | La lógica del mapa y los scripts del servidor se dirigen a las entities a través de ellos |
| Conexiones entre entities | Puertas, botones y triggers dependen de inputs y outputs |
| Clases de entity | El motor crea los objetos a partir del nombre de la clase |
| Referencias a materiales, modelos y sonidos | Cada referencia tiene que apuntar a un archivo existente |
| Header, tabla de lumps, offsets | Sin una estructura coherente, el mapa no carga |
Si se renombra una ruta de material sin que todas las referencias la sigan, en el juego ves el patrón de cuadros de las texturas que faltan. Por eso un método serio vuelve a validar el resultado después de procesarlo y no entrega un archivo que no supere esa comprobación.
Eso sí, una comprobación estructural no sustituye a una prueba en el juego. Antes de poner en producción un mapa ofuscado, recórrelo una vez en tu servidor:
- Carga el mapa en un servidor de pruebas y revisa la consola en busca de errores.
- Recorre el mapa y fíjate en las texturas, los modelos y los reflejos.
- Acciona puertas, botones, triggers y teletransportes.
- Revisa los addons que recuerdan entities del mapa, por ejemplo asignaciones de puertas u objetos colocados de forma permanente.
- Entra con un segundo cliente que reciba el mapa por tu vía de descarga habitual.
Por cierto, el punto 4 vale para cada versión nueva de un mapa, también después de una actualización corriente.
Límites de la ofuscación
El motor tiene que poder leer todo lo que necesita para cargar el mapa. De ahí salen límites fijos:
- Un mapa ofuscado sigue siendo analizable en principio.
- Los decompilers siguen evolucionando. Una barrera alta hoy puede ser más baja mañana.
- Con tiempo suficiente, cualquier mapa se puede reconstruir a mano.
- La ofuscación no impide que el archivo se copie sin cambios y se use en otro servidor.
| La ofuscación ayuda contra | La ofuscación no ayuda contra |
|---|---|
| descompilar y seguir editando cómodamente | copiar el archivo terminado |
| entender rápido un mapa ajeno | el uso en otros servidores |
| llevar contenido a otros proyectos | una reconstrucción a mano |
De la columna derecha se encargan otras herramientas. Un fingerprint hace rastreables las copias, y un mapa Server-Exclusive solo funciona por completo en un servidor con licencia. Proteger tu mapa de GMod de filtraciones explica cómo encajan las piezas.
Obfuscation en bspmarket.de
En la BSP Protection de bspmarket.de, Obfuscation es un nivel de protección propio. El sitio describe expresamente el objetivo no como ilegibilidad, sino como dificultar las vías típicas de reconstrucción. Están documentados públicamente los siguientes puntos:
- Obfuscation trabaja en varias capas controladas.
- Solo se renombran las rutas de materiales. Los nombres de las entities y los targetnames se conservan para que los scripts del servidor sigan funcionando.
- El archivo resultante se vuelve a validar. Si falla, no hay resultado en lugar de un mapa roto.
- El archivo original no se modifica, la protección crea un resultado aparte.
- Solo se te cobra por un trabajo completado con éxito.
- Sigue siendo recomendable una prueba en el servidor de destino antes de publicar.
La guía de protección explica qué detalles no se publican a propósito y por qué.
Preguntas frecuentes
¿La ofuscación cambia el aspecto del mapa o cómo se juega?
No debería. Los nombres y las referencias relevantes para el funcionamiento se conservan, y el resultado se comprueba estructuralmente. Aun así, merece la pena una prueba corta en tu propio servidor.
¿La ofuscación hace imposible descompilar?
No. Dificulta los intentos típicos de decompile y reduce la información de editor aprovechable. En mapas de Source no se puede descartar un decompile.
¿Puedo seguir editando un mapa ofuscado más adelante?
El BSP ofuscado no se edita. Editas tu VMF, vuelves a compilar y proteges de nuevo la versión nueva. Así que guarda siempre a buen recaudo el VMF y el BSP original.
¿Necesito ofuscación si ya uso un fingerprint?
Resuelven problemas distintos. El fingerprint hace rastreable una copia, la ofuscación dificulta seguir editándola. Juntos cubren más que cada medida por separado.