En programación y seguridad de la información , un desbordamiento del búfer o desbordamiento del búfer es una anomalía por la cual un programa escribe datos en un búfer más allá de la memoria asignada del búfer , sobrescribiendo ubicaciones de memoria adyacentes .
Los buffers son áreas de memoria reservadas para almacenar datos, a menudo mientras se mueven de una sección de un programa a otra, o entre programas. Los desbordamientos del búfer a menudo pueden desencadenarse por entradas con formato incorrecto; Si se supone que todas las entradas serán más pequeñas que un cierto tamaño y el búfer se crea para tener ese tamaño, entonces una transacción anómala que produzca más datos podría hacer que se escriba más allá del final del búfer. Si esto sobrescribe datos adyacentes o código ejecutable, puede provocar un comportamiento errático del programa, incluidos errores de acceso a la memoria , resultados incorrectos y fallas .
Explotar el comportamiento de un desbordamiento del búfer es un exploit de seguridad bien conocido . En muchos sistemas, la distribución de la memoria de un programa, o del sistema en su conjunto, está bien definida. Al enviar datos diseñados para provocar un desbordamiento del búfer, es posible escribir en áreas que se sabe que contienen código ejecutable y reemplazarlo con código malicioso , o sobrescribir selectivamente datos relacionados con el estado del programa, provocando así un comportamiento que no estaba previsto por el programador original. Los buffers están muy extendidos en el código del sistema operativo (SO), por lo que es posible realizar ataques que realicen una escalada de privilegios y obtengan acceso ilimitado a los recursos de la computadora. El famoso gusano Morris utilizó en 1988 esto como una de sus técnicas de ataque.
Los lenguajes de programación comúnmente asociados con los desbordamientos de búfer incluyen C y C++ , que no brindan protección incorporada contra el acceso o la sobrescritura de datos en cualquier parte de la memoria y no verifican automáticamente que los datos escritos en una matriz (el tipo de búfer incorporado) estén dentro. los límites de esa matriz. La verificación de límites puede evitar desbordamientos del búfer, pero requiere código y tiempo de procesamiento adicionales. Los sistemas operativos modernos utilizan una variedad de técnicas para combatir los desbordamientos maliciosos del búfer, en particular aleatorizando el diseño de la memoria o dejando deliberadamente espacio entre los búferes y buscando acciones que escriban en esas áreas ("canarios").
Un desbordamiento del búfer ocurre cuando los datos escritos en un búfer también corrompen los valores de datos en las direcciones de memoria adyacentes al búfer de destino debido a una verificación de límites insuficiente . [1] : 41 Esto puede ocurrir al copiar datos de un búfer a otro sin verificar primero que los datos quepan dentro del búfer de destino.
En el siguiente ejemplo expresado en C , un programa tiene dos variables adyacentes en la memoria: un búfer de cadena de 8 bytes de longitud, A, y un entero big-endian de dos bytes , B.
carácter A [ 8 ] = "" ; corto sin firmar B = 1979 ; Inicialmente, A no contiene nada más que cero bytes y B contiene el número 1979.
Ahora, el programa intenta almacenar la cadena terminada en nulo "excessive" con codificación ASCII en el búfer A.
strcpy ( A , "excesivo" ); "excessive"tiene 9 caracteres de largo y codifica 10 bytes, incluido el terminador nulo, pero A solo puede tomar 8 bytes. Al no comprobar la longitud de la cadena, también sobrescribe el valor de B:
El valor de B ahora ha sido reemplazado inadvertidamente por un número formado a partir de parte de la cadena de caracteres. En este ejemplo, "e" seguida de un byte cero se convertiría en 25856.
En ocasiones, el sistema operativo puede detectar la escritura de datos más allá del final de la memoria asignada y generar un error de falla de segmentación que finaliza el proceso.
Para evitar que se produzca un desbordamiento del búfer en este ejemplo, la llamada a strcpypodría reemplazarse con strlcpy, que toma la capacidad máxima de A (incluido un carácter de terminación nula) como parámetro adicional y garantiza que no se escriba más que esta cantidad de datos. a A:
strlcpy ( A , "excesivo" , tamaño de ( A )); strlcpyCuando está disponible, se prefiere la función de biblioteca strncpya la que no termina en nulo el búfer de destino si la longitud de la cadena de origen es mayor o igual que el tamaño del búfer (el tercer argumento pasado a la función). Por lo tanto A, no puede tener terminación nula y no puede tratarse como una cadena de estilo C válida.
Las técnicas para explotar una vulnerabilidad de desbordamiento del búfer varían según la arquitectura , el sistema operativo y la región de la memoria. Por ejemplo, la explotación en el montón (utilizada para la memoria asignada dinámicamente) difiere notablemente de la explotación en la pila de llamadas . En general, la explotación del montón depende del administrador del montón utilizado en el sistema de destino, mientras que la explotación del montón depende de la convención de llamada utilizada por la arquitectura y el compilador.
Hay varias formas en las que se puede manipular un programa explotando los desbordamientos del búfer basados en la pila:
El atacante diseña datos para provocar uno de estos exploits y luego coloca estos datos en un búfer proporcionado a los usuarios por el código vulnerable. Si la dirección de los datos proporcionados por el usuario utilizados para afectar el desbordamiento del búfer de pila es impredecible, explotar un desbordamiento del búfer de pila para provocar la ejecución remota de código se vuelve mucho más difícil. Una técnica que se puede utilizar para aprovechar este desbordamiento del buffer se llama " trampolín ". Aquí, un atacante encontrará un puntero al búfer de pila vulnerable y calculará la ubicación de su código shell en relación con ese puntero. Luego, el atacante utilizará la sobrescritura para saltar a una instrucción que ya está en la memoria, la cual realizará un segundo salto, esta vez en relación con el puntero. Ese segundo salto bifurcará la ejecución al código shell. Las instrucciones adecuadas suelen estar presentes en códigos grandes. El Proyecto Metasploit , por ejemplo, mantiene una base de datos de códigos de operación adecuados, aunque solo enumera aquellos que se encuentran en el sistema operativo Windows . [4]
Un desbordamiento del búfer que ocurre en el área de datos del montón se denomina desbordamiento del montón y se puede explotar de una manera diferente a la de los desbordamientos basados en la pila. La aplicación asigna dinámicamente la memoria en el montón en tiempo de ejecución y normalmente contiene datos del programa. La explotación se realiza corrompiendo estos datos de maneras específicas para hacer que la aplicación sobrescriba estructuras internas como los punteros de listas vinculadas. La técnica canónica de desbordamiento de montón sobrescribe el enlace de asignación de memoria dinámica (como los metadatos malloc ) y utiliza el intercambio de puntero resultante para sobrescribir un puntero de función de programa.
La vulnerabilidad GDI+ de Microsoft en el manejo de archivos JPEG es un ejemplo del peligro que puede presentar un desbordamiento del montón. [5]
La manipulación del búfer, que se produce antes de su lectura o ejecución, puede provocar el fracaso de un intento de explotación. Estas manipulaciones pueden mitigar la amenaza de explotación, pero no hacerla imposible. Las manipulaciones podrían incluir la conversión a mayúsculas o minúsculas, la eliminación de metacaracteres y el filtrado de cadenas no alfanuméricas . Sin embargo, existen técnicas para eludir estos filtros y manipulaciones, como el código shell alfanumérico , el código polimórfico , el código automodificable y los ataques de retorno a libc . Se pueden utilizar los mismos métodos para evitar la detección por parte de los sistemas de detección de intrusos . En algunos casos, incluso cuando el código se convierte a Unicode , [6] los reveladores han tergiversado la amenaza de la vulnerabilidad como solo una Denegación de Servicio cuando en realidad es posible la ejecución remota de código arbitrario.
En los exploits del mundo real hay una variedad de desafíos que deben superarse para que los exploits funcionen de manera confiable. Estos factores incluyen bytes nulos en las direcciones, variabilidad en la ubicación del código shell, diferencias entre entornos y diversas contramedidas en funcionamiento.
Un trineo NOP es la técnica más antigua y conocida para explotar los desbordamientos del búfer de pila. [7] Resuelve el problema de encontrar la dirección exacta del buffer aumentando efectivamente el tamaño del área objetivo. Para hacer esto, se corrompen secciones mucho más grandes de la pila con la instrucción de máquina no operativa . Al final de los datos proporcionados por el atacante, después de las instrucciones de no operación, el atacante coloca una instrucción para realizar un salto relativo a la parte superior del búfer donde se encuentra el código shell . Esta colección de no operaciones se conoce como "trineo NOP" porque si la dirección de retorno se sobrescribe con cualquier dirección dentro de la región no operativa del búfer, la ejecución se "deslizará" hacia abajo por las no operaciones hasta que sea redirigido al código malicioso real mediante el salto al final. Esta técnica requiere que el atacante adivine en qué parte de la pila está el trineo NOP en lugar del código shell comparativamente pequeño. [8]
Debido a la popularidad de esta técnica, muchos proveedores de sistemas de prevención de intrusiones buscarán este patrón de instrucciones de máquina no operativas en un intento de detectar el código shell en uso. Es importante tener en cuenta que un trineo NOP no necesariamente contiene solo instrucciones tradicionales de máquina no operativa. Cualquier instrucción que no corrompa el estado de la máquina hasta el punto de que el código shell no se ejecute se puede utilizar en lugar de la no operación asistida por hardware. Como resultado, se ha convertido en una práctica común para los creadores de exploits componer el trineo no operativo con instrucciones elegidas al azar que no tendrán ningún efecto real en la ejecución del código shell. [9]
Si bien este método mejora enormemente las posibilidades de que un ataque tenga éxito, no está exento de problemas. Los exploits que utilizan esta técnica aún deben depender de cierta cantidad de suerte para adivinar las compensaciones en la pila que se encuentran dentro de la región del trineo NOP. [10] Una suposición incorrecta generalmente provocará que el programa objetivo falle y podría alertar al administrador del sistema sobre las actividades del atacante. Otro problema es que el trineo NOP requiere una cantidad mucho mayor de memoria para contener un trineo NOP lo suficientemente grande como para ser de alguna utilidad. Esto puede ser un problema cuando el tamaño asignado del buffer afectado es demasiado pequeño y la profundidad actual de la pila es poco profunda (es decir, no hay mucho espacio desde el final del marco de la pila actual hasta el inicio de la pila). A pesar de sus problemas, el trineo NOP es a menudo el único método que funcionará para una plataforma, entorno o situación determinada y, como tal, sigue siendo una técnica importante.
La técnica de "saltar al registro" permite una explotación confiable de los desbordamientos del búfer de pila sin la necesidad de espacio adicional para un trineo NOP y sin tener que adivinar los desplazamientos de la pila. La estrategia es sobrescribir el puntero de retorno con algo que hará que el programa salte a un puntero conocido almacenado dentro de un registro que apunta al búfer controlado y por lo tanto al código shell. Por ejemplo, si el registro A contiene un puntero al inicio de un búfer, entonces cualquier salto o llamada que tome ese registro como operando se puede utilizar para controlar el flujo de ejecución. [11]
DbgPrint()rutina contiene el código de operación de la máquina i386 para jmp esp.En la práctica, es posible que un programa no contenga intencionalmente instrucciones para saltar a un registro en particular. La solución tradicional es encontrar una instancia no intencionada de un código de operación adecuado en una ubicación fija en algún lugar dentro de la memoria del programa. La Figura E a la izquierda contiene un ejemplo de una instancia no intencional de la jmp espinstrucción i386. El código de operación para esta instrucción es FF E4. [12] Esta secuencia de dos bytes se puede encontrar en un desplazamiento de un byte desde el inicio de la instrucción call DbgPrinten la dirección 0x7C941EED. Si un atacante sobrescribe la dirección de retorno del programa con esta dirección, el programa primero saltará a 0x7C941EED, interpretará el código de operación FF E4como la jmp espinstrucción y luego saltará a la parte superior de la pila y ejecutará el código del atacante. [13]
Cuando esta técnica es posible, la gravedad de la vulnerabilidad aumenta considerablemente. Esto se debe a que la explotación funcionará de manera suficientemente confiable como para automatizar un ataque con una garantía virtual de éxito cuando se ejecute. Por este motivo, esta es la técnica más utilizada en los gusanos de Internet que aprovechan las vulnerabilidades de desbordamiento del búfer de pila. [14]
Este método también permite colocar shellcode después de la dirección del remitente sobrescrita en la plataforma Windows. Dado que los ejecutables se basan principalmente en la dirección 0x00400000y x86 es una arquitectura Little Endian , el último byte de la dirección de retorno debe ser nulo, lo que finaliza la copia del búfer y no se escribe nada más allá de eso. Esto limita el tamaño del código shell al tamaño del búfer, lo que puede resultar demasiado restrictivo. Las DLL se encuentran en memoria alta (arriba 0x01000000) y también tienen direcciones que no contienen bytes nulos, por lo que este método puede eliminar bytes nulos (u otros caracteres no permitidos) de la dirección de retorno sobrescrita. Utilizado de esta manera, el método a menudo se denomina "trampolín DLL".
Se han utilizado varias técnicas para detectar o prevenir desbordamientos del búfer, con diversas compensaciones. Las siguientes secciones describen las opciones e implementaciones disponibles.
Ensamblador, C y C++ son lenguajes de programación populares que son vulnerables al desbordamiento del búfer en parte porque permiten el acceso directo a la memoria y no están fuertemente tipados . [15] C no proporciona protección incorporada contra el acceso o la sobrescritura de datos en cualquier parte de la memoria. Más específicamente, no verifica que los datos escritos en un búfer estén dentro de los límites de ese búfer. Las bibliotecas estándar de C++ proporcionan muchas formas de almacenar datos en un búfer de forma segura, y la biblioteca de plantillas estándar (STL) de C++ proporciona contenedores que opcionalmente pueden realizar comprobaciones de límites si el programador solicita explícitamente comprobaciones mientras accede a los datos. Por ejemplo, una vectorfunción miembro at()realiza una verificación de límites y genera una out_of_range excepción si la verificación de límites falla. [16] Sin embargo, C++ se comporta igual que C si la verificación de límites no se llama explícitamente. También existen técnicas para evitar desbordamientos de búfer para C.
Los lenguajes fuertemente tipados y que no permiten el acceso directo a la memoria, como COBOL, Java, Python y otros, evitan el desbordamiento del búfer en la mayoría de los casos. [15] Muchos lenguajes de programación distintos de C o C++ proporcionan verificación en tiempo de ejecución y, en algunos casos, incluso verificación en tiempo de compilación, lo que podría enviar una advertencia o generar una excepción, mientras que C o C++ sobrescribirían datos y continuarían ejecutando instrucciones hasta que se obtengan resultados erróneos. , lo que podría provocar que el programa se bloquee. Ejemplos de dichos lenguajes incluyen Ada , Eiffel , Lisp , Modula -2 , Smalltalk , OCaml y derivados de C como Cyclone , Rust y D. Los entornos de código de bytes de Java y .NET Framework también requieren la verificación de límites en todas las matrices. Casi todos los idiomas interpretados protegerán contra el desbordamiento del búfer, lo que indica una condición de error bien definida. Los lenguajes que proporcionan suficiente información de tipo para realizar la verificación de límites a menudo brindan una opción para habilitarla o deshabilitarla. El análisis de código estático puede eliminar muchas comprobaciones de tipos y límites dinámicos, pero las implementaciones deficientes y los casos incómodos pueden disminuir significativamente el rendimiento. Los ingenieros de software deben considerar cuidadosamente las ventajas y desventajas de la seguridad frente a los costos de rendimiento al decidir qué lenguaje y configuración del compilador utilizar.
El problema de los desbordamientos de búfer es común en los lenguajes C y C++ porque exponen detalles de representación de bajo nivel de los búferes como contenedores para tipos de datos. Los desbordamientos del búfer se pueden evitar manteniendo un alto grado de corrección en el código que realiza la gestión del búfer. También se recomienda desde getshace mucho tiempo evitar las funciones de biblioteca estándar que no estén controladas por límites, como scanfy strcpy. El gusano Morris aprovechó una getsllamada en fingerd . [17]
Las bibliotecas de tipos de datos abstractos bien escritas y probadas que centralizan y realizan automáticamente la gestión del búfer, incluida la comprobación de límites, pueden reducir la aparición y el impacto de los desbordamientos del búfer. Los tipos de datos principales en los lenguajes en los que los desbordamientos del búfer son comunes son cadenas y matrices. Por lo tanto, las bibliotecas que evitan los desbordamientos del búfer en estos tipos de datos pueden proporcionar la gran mayoría de la cobertura necesaria. Sin embargo, no utilizar correctamente estas bibliotecas seguras puede provocar desbordamientos del búfer y otras vulnerabilidades y, naturalmente, cualquier error en la biblioteca también es una vulnerabilidad potencial. Las implementaciones de bibliotecas "seguras" incluyen "The Better String Library", [18] Vstr [19] y Erwin. [20] La biblioteca C del sistema operativo OpenBSD proporciona las funciones strlcpy y strlcat , pero son más limitadas que las implementaciones de bibliotecas completamente seguras.
En septiembre de 2007 se publicó el Informe Técnico 24731, elaborado por el comité de normas C. [21] Especifica un conjunto de funciones que se basan en la cadena de la biblioteca C estándar y las funciones IO, con parámetros adicionales de tamaño de búfer. Sin embargo, la eficacia de estas funciones para reducir los desbordamientos del buffer es discutible. Requieren la intervención del programador por llamada de función, lo que equivale a una intervención que podría hacer que las funciones análogas y antiguas de la biblioteca estándar sean seguras contra el desbordamiento del búfer. [22]
La protección contra desbordamiento de búfer se utiliza para detectar los desbordamientos de búfer más comunes comprobando que la pila no haya sido alterada cuando regresa una función. Si ha sido alterado, el programa sale con un fallo de segmentación . Tres de estos sistemas son Libsafe, [23] y los parches gcc StackGuard [24] y ProPolice [25] .
La implementación de Microsoft del modo de Prevención de ejecución de datos (DEP) protege explícitamente el puntero al Controlador de excepciones estructurado (SEH) para que no se sobrescriba. [26]
Es posible una protección de pila más sólida dividiendo la pila en dos: una para datos y otra para retornos de funciones. Esta división está presente en el lenguaje Forth , aunque no fue una decisión de diseño basada en la seguridad. De todos modos, esta no es una solución completa para los desbordamientos del búfer, ya que es posible que se sobrescriban datos confidenciales distintos de la dirección del remitente.
Este tipo de protección tampoco es del todo exacto porque no detecta todos los ataques. Los sistemas como StackGuard se centran más en el comportamiento de los ataques, lo que los hace eficientes y más rápidos en comparación con los sistemas de verificación de alcance. [27]
Los desbordamientos de búfer funcionan manipulando punteros , incluidas las direcciones almacenadas. PointGuard se propuso como una extensión del compilador para evitar que los atacantes manipulen de manera confiable punteros y direcciones. [28] El enfoque funciona haciendo que el compilador agregue código para codificar automáticamente los punteros XOR antes y después de su uso. En teoría, debido a que el atacante no sabe qué valor se utilizará para codificar y decodificar el puntero, no se puede predecir a qué apuntará el puntero si se sobrescribe con un nuevo valor. PointGuard nunca se lanzó, pero Microsoft implementó un enfoque similar a partir de Windows XP SP2 y Windows Server 2003 SP1. [29] En lugar de implementar la protección del puntero como una característica automática, Microsoft agregó una rutina API a la que se puede llamar. Esto permite un mejor rendimiento (porque no se usa todo el tiempo), pero impone al programador la carga de saber cuándo es necesario su uso.
Debido a que XOR es lineal, un atacante puede manipular un puntero codificado sobrescribiendo solo los bytes inferiores de una dirección. Esto puede permitir que un ataque tenga éxito si el atacante puede intentar explotar varias veces o completar un ataque haciendo que un puntero apunte a una de varias ubicaciones (como cualquier ubicación dentro de un trineo NOP). [30] Microsoft agregó una rotación aleatoria a su esquema de codificación para abordar esta debilidad de las sobrescrituras parciales. [31]
La protección del espacio ejecutable es un enfoque para la protección contra el desbordamiento del búfer que impide la ejecución de código en la pila o el montón. Un atacante puede utilizar desbordamientos de búfer para insertar código arbitrario en la memoria de un programa, pero con la protección del espacio ejecutable, cualquier intento de ejecutar ese código provocará una excepción.
Algunas CPU admiten una función llamada bit NX ("No eXecute") o XD ("eXecute Disabled"), que, junto con el software, se puede utilizar para marcar páginas de datos (como las que contienen la pila y el montón) como legibles. y escribible pero no ejecutable.
Algunos sistemas operativos Unix (por ejemplo, OpenBSD , macOS ) se entregan con protección de espacio ejecutable (por ejemplo, W^X ). Algunos paquetes opcionales incluyen:
Las variantes más nuevas de Microsoft Windows también admiten la protección del espacio ejecutable, denominada Prevención de ejecución de datos . [35] Los complementos propietarios incluyen:
La protección del espacio ejecutable generalmente no protege contra ataques de retorno a libc o cualquier otro ataque que no dependa de la ejecución del código del atacante. Sin embargo, en sistemas de 64 bits que utilizan ASLR , como se describe a continuación, la protección del espacio ejecutable hace que sea mucho más difícil ejecutar dichos ataques.
La aleatorización del diseño del espacio de direcciones (ASLR) es una característica de seguridad informática que implica organizar las posiciones de áreas de datos clave, que generalmente incluyen la base del ejecutable y la posición de las bibliotecas, el montón y la pila, de forma aleatoria en el espacio de direcciones de un proceso.
La aleatorización de las direcciones de memoria virtual en las que se pueden encontrar funciones y variables puede hacer que la explotación de un desbordamiento del búfer sea más difícil, pero no imposible. También obliga al atacante a adaptar el intento de explotación al sistema individual, lo que frustra los intentos de los gusanos de Internet . [38] Un método similar pero menos efectivo es rebase de procesos y bibliotecas en el espacio de direcciones virtuales.
El uso de la inspección profunda de paquetes (DPI) puede detectar, en el perímetro de la red, intentos remotos muy básicos de explotar desbordamientos de búfer mediante el uso de firmas de ataque y heurísticas . Esta técnica puede bloquear paquetes que tengan la firma de un ataque conocido. Anteriormente se usaba en situaciones en las que se detectaba una larga serie de instrucciones sin operación (conocidas como trineo NOP) y la ubicación de la carga útil del exploit era ligeramente variable.
El escaneo de paquetes no es un método eficaz ya que sólo puede prevenir ataques conocidos y hay muchas maneras de codificar un trineo NOP. El código shell utilizado por los atacantes puede hacerse alfanumérico , metamórfico o automodificable para evadir la detección mediante escáneres heurísticos de paquetes y sistemas de detección de intrusos .
Comprobar si hay desbordamientos del búfer y corregir los errores que los causan ayuda a prevenirlos. Una técnica automatizada común para descubrirlos es la fuzzing . [39] Las pruebas de casos extremos también pueden descubrir desbordamientos de búfer, al igual que el análisis estático. [40] Una vez que se detecta un posible desbordamiento del búfer, se debe parchear. Esto hace que el enfoque de prueba sea útil para el software que está en desarrollo, pero menos útil para el software heredado que ya no recibe mantenimiento ni soporte.
Los desbordamientos de búfer se entendieron y documentaron parcialmente públicamente ya en 1972, cuando el Estudio de planificación de tecnología de seguridad informática presentó la técnica: "El código que realiza esta función no verifica las direcciones de origen y destino correctamente, lo que permite que partes del monitor se superpongan con "El usuario. Esto se puede utilizar para inyectar un código en el monitor que permitirá al usuario tomar el control de la máquina". [41] Hoy en día, el monitor se denominaría núcleo.
La primera explotación hostil documentada de un desbordamiento de buffer fue en 1988. Fue una de varias hazañas utilizadas por el gusano Morris para propagarse a través de Internet. El programa explotado era un servicio en Unix llamado finger . [42] Más tarde, en 1995, Thomas Lopatic redescubrió de forma independiente el desbordamiento del búfer y publicó sus hallazgos en la lista de correo de seguridad de Bugtraq . [43] Un año después, en 1996, Elias Levy (también conocido como Aleph One) publicó en la revista Phrack el artículo "Smashing the Stack for Fun and Profit", [44] una introducción paso a paso a la explotación de sistemas basados en pilas. Vulnerabilidades de desbordamiento del buffer.
Desde entonces, al menos dos importantes gusanos de Internet han aprovechado los desbordamientos del búfer para comprometer una gran cantidad de sistemas. En 2001, el gusano Code Red aprovechó un desbordamiento de búfer en Internet Information Services (IIS) 5.0 de Microsoft [45] y en 2003, el gusano SQL Slammer comprometió máquinas que ejecutaban Microsoft SQL Server 2000 . [46]
En 2003, los desbordamientos de búfer presentes en los juegos con licencia de Xbox fueron explotados para permitir que software sin licencia, incluidos los juegos caseros , se ejecutara en la consola sin necesidad de modificaciones de hardware, conocidos como modchips . [47] El Independence Exploit de PS2 también utilizó un desbordamiento de búfer para lograr lo mismo en PlayStation 2 . El truco de Crepúsculo logró lo mismo con la Wii , usando un desbordamiento de búfer en The Legend of Zelda: Twilight Princess .
{{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite web}}: Mantenimiento CS1: copia archivada como título ( enlace )