Protege contenido distribuido en el cliente frente a extracción offline sencilla, copia masiva, manipulación no autorizada y uso de herramientas genéricas. Además añade autorización, integridad y control de releases alrededor del servidor.

No hacemos esa promesa. Si un cliente debe renderizar un recurso, alguna representación utilizable existirá en memoria durante la ejecución. Ningún sistema puramente cliente puede garantizar que un atacante avanzado jamás observe memoria. Shield busca elevar mucho el costo de extracción y evitar que copiar un archivo o conocer una sola clave equivalga a obtener el contenido completo.

No en su oferta comercial actual. El producto que vendemos hoy se centra en protección criptográfica, autorización, integridad de releases y distribución segura del contenido protegido.

Sí. Un atacante con control total del equipo puede intentar observar datos que el juego necesita usar. Shield protege especialmente el contenido almacenado y distribuido, la autorización y la integridad. No convertimos una limitación inherente al software cliente en una promesa falsa.

Porque cambia la escala del problema. Sin protección, copiar o abrir un archivo distribuido puede bastar para obtener grandes cantidades de contenido. Con Shield, el contenido se entrega dentro de un formato protegido, autenticado y ligado a un flujo autorizado.

El modelo de Shield no está planteado como una única contraseña estática que por sí sola entregue el contenido. La autorización del servidor, derivación de material criptográfico, integridad y estado de la release forman parte de la cadena de confianza.

Sí. Puedes separar los recursos valiosos —por ejemplo sprites, mapas, interfaces o contenido personalizado— y proteger solamente los archivos que tengan sentido para tu proyecto.

No debes tratar el paquete protegido como sustituto de tus fuentes. Conserva siempre tus GRF originales y material de desarrollo. Shield mantiene además la fuente administrativa necesaria para continuar publicando actualizaciones protegidas.

El jugador recibe el paquete protegido y firmado que necesita el runtime de Shield. Los GRF seleccionados para protección no se distribuyen como GRF abiertos destinados a ser navegados con herramientas genéricas.

Genera un THOR dirigido al GRF correspondiente y publícalo desde el flujo autorizado de Shield. El sistema valida el destino, aplica los cambios sobre la fuente administrativa, genera la nueva revisión protegida y prepara el delta que consumirá el launcher.

No. El flujo de actualización trabaja sobre la fuente administrativa preservada para ese GRF y produce una nueva release protegida sin pedirte que conviertas el cliente de producción en una copia abierta.

No en el flujo protegido. El THOR es una entrada administrativa. El jugador recibe un paquete de actualización Shield firmado y verificable.

No es el comportamiento normal del sistema. Shield compara el contenido protegido por fragmentos y publica los cambios necesarios junto con la metadata de la nueva release. El cliente reutiliza localmente los fragmentos que no cambiaron y reconstruye su paquete protegido antes de activarlo.

No. El contenido protegido permanece local en el equipo del jugador después de su distribución mediante el canal del servidor. La infraestructura de Shield participa en autorización, releases y cadena de confianza; no envía cada sprite o mapa mientras juegas.

La intención no es realizar una petición remota por cada sprite. La autorización establece el contexto necesario y el contenido protegido permanece local. Existe costo criptográfico, pero el diseño evita convertir cada acceso a un recurso en una descarga remota.

Toda protección tiene algún costo. Nuestro objetivo es mantenerlo dentro de márgenes razonables y medirlo en builds reales. El impacto depende del volumen, hardware y patrón de acceso; por eso preferimos medir antes que prometer “cero impacto”.

Sí, siempre que la integración pueda distribuir el build protegido y respetar el flujo de confianza y actualización requerido por Shield.

No como requisito general. Shield está pensado para integrarse con el flujo de lanzamiento del proyecto. La compatibilidad concreta se valida según tu launcher y la revisión del cliente.

No. El servidor puede continuar en Linux. Shield Node está pensado para convivir con la infraestructura del servidor, mientras que el cliente Ragnarok y las herramientas de administración que modifican el cliente trabajan en Windows.

El Ragexe final de cada servidor se analiza antes de preparar su integración. Si una revisión todavía no está soportada, se trata como adaptación y no aplicamos cambios a ciegas.

Puede existir un flujo de compatibilidad para integraciones legítimas, respetando los controles y licencias del proveedor. Shield no está diseñado para saltarse licencias o mecanismos de terceros.

Una licencia cubre un servidor. Esto mantiene separado el estado, los builds y la administración comercial de cada proyecto.

Sin vencimiento programado mientras SkDevSv continúe operando ese producto y la infraestructura necesaria para prestarlo. No significa una garantía de operación perpetua si el producto deja de existir.

El portal centraliza tickets y Live Chat ligados a la cuenta, licencias y servidores. El onboarding inicial también permite revisar particularidades del cliente antes de protegerlo.