Descompilar un BSP, explicado: qué te da realmente un decompile
Descompilar un BSP convierte un mapa compilado de Source otra vez en un VMF. Qué vuelve, qué se pierde y qué logra de verdad la protección anti-decompile.
Descompilar significa que una herramienta como BSPSource toma un archivo BSP compilado y vuelve a generar a partir de él un archivo VMF que se puede abrir en el editor Hammer. El resultado es una reconstrucción, no el archivo original: la geometría y las entities vuelven en gran medida, la estructura de trabajo del mapper no. Como el motor tiene que poder leer cualquier BSP, un mapa compilado nunca es realmente secreto.
Por qué se pueden descompilar los archivos BSP
Un BSP no es un contenedor sellado. El formato se conoce desde hace años, y para cargar el mapa el motor necesita exactamente los datos que evalúa un decompiler: brushes para la colisión, superficies con materiales, entities en forma de texto. Un decompiler lee esas secciones y las vuelve a escribir en el formato de texto que entiende Hammer. ¿Qué es un archivo BSP? muestra cómo está estructurado el archivo.
Hay motivos legítimos para descompilar. Los mappers lo hacen para rescatar sus propios proyectos tras perder el VMF, para investigar problemas en una versión compilada o para aprender de mapas publicados cómo se construyó algo.
Qué devuelve un decompile
Un buen decompile recupera una cantidad sorprendente de cosas:
- los world brushes, reconstruidos a partir de los datos de brush almacenados
- las point entities con todas sus propiedades, además de inputs y outputs
- brush entities como puertas, triggers y
func_detail - displacements, es decir, superficies de terreno deformadas
- los props
prop_staticy los overlays - las posiciones de los cubemaps y los areaportals, estos últimos no siempre en su sitio
- la asignación de materiales a las superficies
- el contenido del pakfile, que se puede extraer como un archivo comprimido normal
Para alguien con experiencia en Hammer, eso basta como punto de partida para modificar un mapa y volver a compilarlo.
Qué falta o solo es aproximado
Todo lo que solo le servía al editor no está en el BSP y, por tanto, no vuelve.
| Área | Estado tras descompilar |
|---|---|
| VisGroups, grupos, comentarios | faltan, nunca se escriben en el BSP |
| Instances | disueltas, todo el contenido queda directamente en el mapa |
Entities que el compilador consume por completo, como func_viscluster | no se pueden restaurar a la perfección, según el readme de BSPSource |
| Formas de los brushes | el BSP conserva los propios brushes, pero los vértices de los brushes complejos vuelven imprecisos, hasta dar sólidos inválidos |
| Texturas de herramienta como clip | en parte sustituidas por nodraw o intercambiadas entre sí |
| Iluminación | las entities de luz están, los lightmaps hay que recalcularlos |
| Archivos fuente de modelos y texturas | faltan, el pakfile solo contiene versiones compiladas |
En la práctica eso significa trabajo de repaso. Los brushes reconstruidos pueden causar leaks o sólidos inválidos al volver a compilar, y en un mapa grande sin grupos ni VisGroups cuesta orientarse. Un decompile rara vez es un archivo de trabajo terminado, pero suele ser un punto de partida aprovechable.
Por qué un mapa compilado nunca es secreto
Hay tres hechos que no se pueden cambiar:
- Todo jugador que entra en un servidor recibe el archivo del mapa.
- El motor tiene que poder leer el archivo por completo.
- Lo que puede leer el motor, en principio también puede leerlo otro programa.
Así que, si quieres proteger un mapa, no confíes en el secreto. Los objetivos realistas son que reconstruirlo cueste más esfuerzo y poder demostrar de dónde salió una copia.
Qué consiguen de forma realista las medidas anti-decompile
Las medidas anti-decompile actúan en dos puntos. Primero, eliminan información que el motor no necesita pero que a un editor le vendría bien, como los IDs de editor o los restos de archivos fuente en el pakfile. Segundo, cambian la forma en que se representa el archivo para que la reconstrucción automática funcione con menos fiabilidad y exija más trabajo manual.
| Expectativa | Realidad |
|---|---|
| Ya nadie puede abrir mi mapa | El motor tiene que leerlo, así que en principio sigue siendo analizable |
| Después, un decompile queda descartado | Se vuelve más laborioso y da peores resultados |
| La protección dura para siempre | Los decompilers siguen evolucionando, y los métodos de protección también |
| El anti-decompile sustituye a la protección anticopia | El archivo se puede seguir copiando sin cambios |
El último punto se pasa por alto a menudo: un mapa ofuscado funciona en cualquier servidor al que alguien lo copie. El anti-decompile protege tu trabajo de que otros lo sigan editando cómodamente, no de que se pase de mano en mano. Para eso hacen falta otros medios, descritos en Proteger tu mapa de GMod de filtraciones.
También importa la comprobación inversa. Ningún cambio en un BSP debe dañar el mapa. Los métodos serios vuelven a validar el resultado y no entregan un archivo que no supere esa comprobación.
bspmarket.de lo formula deliberadamente con cautela para su propia BSP Protection: la capa anti-decompile hace que el resultado típico de un decompile sea más difícil de aprovechar, y en archivos BSP de Source no se puede garantizar una protección completa contra la descompilación. Qué hace cada nivel aparece en BSP Protection y en Ofuscación de BSP explicada. Como un decompile nunca se puede descartar del todo, un fingerprint es el complemento sensato: hace rastreable una copia aunque la copia en sí no se pueda impedir.
Que sea técnicamente posible no significa que esté permitido
Que un mapa se pueda descompilar no dice nada sobre si puedes usar el resultado. Un mapa que refleja las decisiones creativas de su autor está protegido como obra suya, y descompilarlo no cambia eso. Quien modifique, vuelva a publicar o venda mapas ajenos necesitará por lo general el consentimiento del autor. Derechos de autor en mapas de GMod: lo básico ofrece una visión general que no constituye asesoramiento jurídico.
Preguntas frecuentes
¿Se puede descompilar cualquier archivo BSP?
En principio, cualquier BSP de Source se puede analizar, porque el motor tiene que leerlo. Lo aprovechable que sea el resultado depende del mapa, del decompiler y de la protección que se haya aplicado.
¿Descompilar me devuelve mi VMF perdido?
Solo como reconstrucción. La geometría y las entities vuelven en gran medida; los grupos, los VisGroups y las instances, no. Hacer copias de seguridad del VMF con regularidad es el mejor camino.
¿La ofuscación impide descompilar?
No. Dificulta los intentos típicos de decompile y reduce la información de editor aprovechable. Un decompile no se puede descartar.
¿Un fingerprint sobrevive a un decompile?
Depende del método y de cuánto se haya cambiado. Los métodos que se apoyan en varias señales independientes resisten mejor los cambios aislados. No hay ninguna garantía.