¿Es posible la inyección de código a través de la modificación de paquetes?
Por ejemplo, si un juego envía un paquete que declara puntaje = 99, ¿puedo modificar el paquete para puntuar = * código * o algo similar?
Supongo que una pregunta similar sería, ¿es posible ejecutar código no API en un entorno API?
Sí, en el sentido de que puede falsificar y enviar dicho paquete.
Primer obstáculo: ¿sigue siendo un paquete válido ? Esto depende de la estructura del paquete. Muchos juegos aprovechan las bibliotecas existentes que usarán formatos estándar como JSON o XML, por lo que no será fácil falsificar un paquete que contenga el código deseado y aún sea sintácticamente correcto para el formato de datos involucrado.
Entonces, ¿el servidor aceptará el paquete? La mayoría de los desarrolladores de juegos suelen preguntarse qué pasaría si alguien modificara
"score": 999
en
"score": 999999999
Si bien sospecho, desde algunas tablas de clasificación que veo en Google Play, que no todos los desarrolladores consideraron esta posibilidad lo suficiente, el método habitual de bajo nivel, baja seguridad y rápido para detener el 99% del aspirante a "winnerz" sería también incluya el hash del valor y de un secreto cliente ( == no seguro ):
"score": 99,
"hash": "ff24e8a1f3fddb010095102bce5a013c"
Un miembro del 1% restante de los jugadores podría anular esto fácilmente al desenterrar el secreto del juego binario, o incluso tratar de sacarlo del mismo binario: la mayoría de las veces el hash para un esquema tan simplista será algo como MD5 ("SECRET" + SCORE) o quizás MD5 (SCORE + "SECRET"), y SECRET será una de las entradas en la tabla de cadenas binarias, en claro.
Así que envías el código modificado con el hash apropiado, y pasará el examen.
Si la defensa es aún más estricta, su etapa será casi imposible de superar, sin embargo: el juego contiene la clave pública del servidor y la utiliza para cifrar la puntuación por RSA, sin siquiera molestarse en enviar en el claro.
Puede ignorar esta dificultad si sabe que el lado del servidor de desbordamiento de búfer está en el código que lee la variable , ya sea que esté encriptado con RSA o no (es decir, antes de incluso se descifra).
En este punto, has logrado enviar una cadena al servidor con la esperanza de que haga algo con él.
Si el servidor hace tontamente algunos supuestos codificados en la longitud de la cadena, eso podría ser suficiente para un desbordamiento de búfer. Es posible que tenga que preparar algunas sustituciones ad hoc para evitar el envío de una carga de código con ceros binarios, que pueden interrumpir la operación de copia de cadenas, pero es factible (y se ha hecho).
Pero ahora surge otra dificultad. Ha inyectado algo en algún lugar en el espacio de proceso del servidor. ¿Cómo maneja esto para que resulte en algo "útil" (desde el punto de vista de un atacante)? Podría muy bien ser que todo lo anterior solo provoque que el servidor tenga problemas o funcione mal por períodos más largos.
Por ejemplo, si un juego envía un paquete que declara un puntaje = 99 podría entonces modificar el paquete para puntuar = código o algo similar?
Todo depende de cómo se interpreta en el extremo del lado del servidor. Si score se interpreta como un identificador, = como un delimitador y 99 como un valor numérico, entonces la ejecución del código solo sería posible a través de un desbordamiento, si existiera tal vulnerabilidad. Sin embargo, si lo que se envía se interpreta como un código ejecutable, sí, esto sería posible.
Supongo que una pregunta similar sería, ¿también es posible ejecutar código no API en un entorno API?
No estoy seguro de lo que quieres decir con esto. El entorno donde se ejecuta el código tiene que ser capaz de entenderlo para que se ejecute. Si la API tiene suficiente espacio de seguridad, la ejecución de código arbitrario puede ser difícil.