[Info] Medidas antipiratería en Switch (Traducción)

Bien, después de un tiempo trabajando en esto hoy les traigo la traducción de un post publicado por Scires en el que trata asuntos bastante interesantes sobre el sistema antipiratería que utiliza Switch. Se utiliza un lenguaje bastante técnico, pero que eso no te asuste, puede que no entiendas los detalles, pero seguramente llegaras a comprender como funciona el sistema antipiratería.

(Inicio de la traducción)


Hola a todos, después de investigar cómo es que la Switch obtiene la autorización para jugar a un juego en online, aprendí que Nintendo ha implementado una serie de medidas antipiratería muy fuertes en este ámbito – Ellos pueden detectar perfectamente cuando una copia de algún juego fue comprada legítimamente. He pensado en hacer un post explicando el proceso, ya que es muy interesante a nivel técnico.

Resumen

Esto es lo que sucede cuando intentas conectarte a online en un juego:

  1. La consola verifica que puedas conectarte a internet
  2. La consola verifica que pueda recibir el token de autorización para ir al online — Eso si no está baneada
  3. La consola autoriza iniciar sesión en la cuenta de Nintendo
  4. La consola obtiene el token de autorización especifico del title que será jugado

A grandes rasgos, todo esto tiene sentido.  Ahora vamos a los detalles técnicos:

Tu consola verifica que pueda conectarse a internet

Este paso casi se explica solo, pero lo incluyo por el mero hecho de ser minucioso. Tu consola se conecta a “ctest.cdn.nintendo.net” periódicamente, y revisa la respuesta de un encabezado especial — “X-Organization: Nintendo”. Si ese encabezado está presente, tu consola concluye que tiene acceso a internet. En caso contrario concluye que no tiene acceso.

Ahora vamos a algo más interesante

Algunos antecedentes

Para aquellos que no han leído mi otro post relacionado a la red de Switch (Nota del traductor: Sigo trabajando en la traducción de ese otro post), recomiendo que lo hagan — es muy interesante. Bueno, en realidad, solo hay algo importante que recordar de aquel post, así que lo repito aquí:

En switch, solamente bugyo(el servidor de la eShop) no es autentificable — los otros servidores autentifican las solicitudes y rechazará todas las solicitudes que carezcan de los certificados correctos. Adicionalmente, los certificados ahora son únicos para cada consola y son quemados de fábrica. Las key privadas del certificado son almacenadas encriptadas usando un keydata solo disponible a TrustZone (Un núcleo del CPU aislado y enfocado a la seguridad, el cual provee una API de criptografía) y el módulo ssl lo recupera en el arranque al interactuar con el servicio de configuración para recuperar los datos cifrados y luego solicita que el módulo spl lo pase a TrustZone para descifrarlo a través de los comandos “GenerateAesKek” y “DecryptPrivk”.

Nótese que a diferencia del 3DS, esto significa que Nintendo sabe que consola es la que realiza una solicitud determinada, por lo que Nintendo puede bloquear el mal uso de certificados, dejándolos permanentemente fuera de cualquier red de Nintendo.

La consola verifica que pueda recibir el token de autorización para ir al online

Nintendo tiene un servidor especial para enviar los tokens de autorización — “dauth-lp1.ndas.srv.nintendo.net” (Device AUTHorization, y lp1 es el entorno de “producción en vivo” para servicios en línea). Una cosa que es importante resaltar es que estos tokens no permiten autorizar todas las operaciones del sistema — Son para manejar partes especificas del sistema, especificado por el client ID en la petición del token. Entonces, así es como funciona la autorización del dispositivo:

  1. La consola se conecta al endpoint “/challenge” de dauth (Device AUTHorization), enviando un argumento “key_generation” que informa al servidor sobre cual revisión de la master key está usando la consola.
  2. Dauth devuelve como un json una cadena aleatoria “challenge” y una cadena constante “data”.
  3. La consola trata la cadena “data”, decodificada en base-64, como una fuente de clave criptográfica, y utiliza los servicios SPL para transformarla con la keydata de la TrustZone y cargarla en un espacio de claves AES.
  4. La consola genera una solicitud para autorizar los datos — esto se hace formateando la cadena “challenge=%s&client_id=%016x&key_generation=%d&system_version=%s” con la cadena challenge, con el client ID solicitando un token, la versión de la master Key, y la versión actual del sistema.
  5. La consola calcula un CMAC AES-128 usando la key de la trustzone que obtuvo de la solicitud de autorización, agrega “& mac =% s” a los datos de solicitud (formateando con el CMAC codificado url-safe base 64), desactiva la solicitud al endpoint “/ device_auth_token”.
  6. Si todo va bien, dauth devuelve un token para la consola. (Si la consola está baneada, como una de las mías, recibirá un mensaje de error informando que la consola no puede usar los servicios en línea).

Este es un esquema personalizado bastante efectivo — para obtener un token, se requiere que el solicitante pueda realizar operaciones criptográficas exclusivas de TrustZone para la versión actual del sistema. Siempre que TrustZone no se vea comprometido con el último firmware, esto es totalmente seguro. Sin embargo, TrustZone está comprometido en todas las versiones del sistema debido a shofusel2, para bien o para mal. Esto significa que el único beneficio real aquí es que dauth proporciona un lugar ideal para implementar baneos a consolas — casi todas las funcionalidades en línea interesantes requieren un token de dauth de algún tipo, incluida la compra e instalación de nuevos juegos del eShop, por lo que las consolas que se bloquean aquí no pueden hacer mucho además de instalar actualizaciones del sistema.

Tu consola autoriza iniciar sesión en la cuenta de Nintendo

Esto es poco interesante, no hay nada que exclusivo de Switch aquí. La consola realiza una autorización oauth bastante estándar interactuando con “api.accounts.nintendo.com” — este es el mismo proceso realizado en una PC, por lo que no voy a entrar en detalles aquí.

El único resultado significativo de este componente es que permite a Nintendo bloquear cuentas específicas, y dado que todas las solicitudes requieren un certificado de cliente, cualquier cuenta bloqueada se puede asociar inmediatamente a una consola.

Tu consola obtiene el token de autorización especifico del title que será jugado

Este es un componente realmente interesante, y es donde radica la medida de seguridad más fuerte de Nintendo.

Al igual que dauth, Nintendo tiene un servidor especial para esto: “aauth-lp1.ndas.srv.nintendo.net” (Application AUTHorization). Para conectarte a Internet en un juego, debes obtener un token del endpoint “/ application_auth_token”. Así es como funciona esto, a grandes rasgos:

  1. La consola recibe un token de autorización de dauth para el aauth del client ID.
  2. La consola recupera su certificación para jugar al title con el que intenta conectarse en línea y lo envía a aauth.
  3. Si todo va bien, aauth devuelve un token de autorización de la aplicación.

Bien, eso no es demasiado complicado. Pero lo que es realmente interesante es la parte donde la consola recupera su certificación para jugar al title con el que intenta conectarse en línea.

Ahora una explicación más técnica y detallada sobre lo que ocurre en ambos casos:

Cartuchos de juegos

  • Si está jugando con un cartucho, su certificación es el certificado único del cartucho. Esto está firmado por Nintendo usando RSA-2048-PCKS # 1 en el momento en que se graba el cartucho, y contiene información encriptada sobre el cartucho (esto incluye qué juego está en el cartucho, entre otros detalles desconocidos).
  • En el caso de los cartuchos, los datos cargados en aauth son “application_id=%016llx&application_version=%08x&device_auth_token=%.*s&media_type=GAMECARD&cert=%.*s” formateados con el ID del juego, la versión del juego, el token recuperado de dauth y el certificado del cartucho (recuperado de FS a través del comando “GetGameCardDeviceCertificate”), formateado como url-safe base64.
  • Este código se encuentra en .text + 0x7DE1C para 5.0.0.

Juegos Digitales

  • La certificación para un title digital es el ticket de la consola. Para obtener más detalles técnicos sobre lo que hay dentro de un ticket, consulte mi publicación anterior sobre eShop / CDN (Nota del traductor: Sigo trabajando en la traducción de ese otro post). Los detalles importantes son que los tickets contienen el title ID del juego que certifican, el Device ID de la consola que autorizan, el Account ID de la cuenta de Nintendo utilizado para la compra y están firmadas por Nintendo con RSA-2048 (no se puede falsificar).
  • En este caso, la consola habla con el servicio “es” y envía un comando para recuperar una copia encriptada del ticket junto con la clave de cifrado. Este cifrado es AES-128 CBC, utilizando una clave generada al azar a través de la generación de números aleatorios criptográficamente seguros. La clave misma está encriptada usando RSA-OAEP 2048. Para omitir algunos detalles técnicos, esta es una encriptación unidireccional que solo Nintendo puede revertir, por lo que incluso si obtuvieras el resultado del comando “es” no podrías determinar la clave de cifrado utilizada (y, por lo tanto, no se puede desencriptar el ticket).
  • Los datos cargados en aauth en este caso son: “application_id=%016llx&application_version=%08x&device_auth_token=%.*s&media_type=DIGITAL&cert=%.*s&cert_key=%.*s” formateados con el ID del juego, la versión del juego, el token recuperado de dauth, el ticket encriptado codificado con url-safe base64 y la key cifrada codificada con url-safe base64.
  • Este código se encuentra en .text+0x7DE98 para 5.0.0.

Y eso es todo (con el caso adicional de que, si la consola no puede encontrar un certificado, se envía una solicitud especial “NO_CERT”, pero esto es bastante irrelevante porque el envío de una solicitud NO_CERT deja la consola baneada). En ambos casos, aauth valida la certificación y devuelve un token solo si la certificación es válida.

Impacto practico

Estas medidas antipiratería son extremadamente fuertes. Nintendo hizo un gran trabajo aquí.

En el caso de los cartuchos, Nintendo puede detectar si el usuario que se conecta tiene datos de una tarjeta de juego autorizada por Nintendo para el title correcto. Esto resuelve el problema de la era-3ds en el que los encabezados de los cartuchos se podían compartir entre juegos. Además, hay una buena cantidad de datos desconocidos (encriptados) en un certificado que se está cargando, y los certificados también están vinculados a Cuentas de Nintendo cuando se canjean los puntos Gold. El intercambio de certificados debe ser bastante detectable para Nintendo.

En el caso de juegos digitales, Nintendo previene perfectamente la piratería en línea. Los tickets no se pueden falsificar y Nintendo puede verificar que el Device ID en el ticket coincide con la Device ID para la conexión del certificado (provocando un ban en caso de no coincidir), y que el Account ID del ticket coincide con la cuenta Nintendo autorizada para iniciar sesión. Los usuarios que piratean juegos, obviamente, no pueden tener tickets firmados correctamente para sus consolas y, por lo tanto, no pueden conectarse en línea sin obtener una ban inmediato.

Fuente original


(Fin de la traducción)

Adicionalmente cabe destacar que este documento fue publicado antes de cualquier CFW que permitiera la carga de backups, por lo que cuando se menciona que una acción causa “baneo inmediato” eran puras suposiciones.

Eso no quiere decir que se puedan usar copias piratas sin temer a un baneo, no se sabe con certeza que es lo que impide a Nintendo activar los baneos instantáneos. Puede que lo haga por oleadas, puede que este esperando a que se acumulen cierta cantidad de usuarios para banear a todos de golpe, puede que lo este dejando pasar ya que es posible que la piratería favorezca las ventas de la consola, etc… Todas son meras suposiciones, pero de lo que si podemos estar seguros es que si alguna vez jugaste online con algún juego obtenido de forma ilegitima, tu consola ya esta marcada.

 

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *