edición general
336 meneos
10335 clics
Veintinueve bytes de código que se convierten en 16 GB al compilar (compiler bomb)

Veintinueve bytes de código que se convierten en 16 GB al compilar (compiler bomb)

Probablemente ya conozcáis las bombas zip, las bombas xml, etc. Por decirlo de una manera sencilla, ficheros (relativamente) pequeños que producen una salida de enorme tamaño cuando son interpretados por el software nativo. El resultado, si se tiene mala leche, es provocar una auténtica denegación de servicio en la máquina que se ejecuta. Hace unos meses, en un foro de StackExchange lanzaron un reto para crear una de estas bombas abusando de un compilador. El ganador, el código más pequeño capaz de generar la salida mayor al compilarse.

| etiquetas: 29 bytes , 16 gb , código fuente , compiler bomb , digital trauma
Comentarios destacados:              
#6 #2 El sufijo "u" hace que el número -1 se interprete como un "unsigned", que es un entero sin signo usando (al menos) 4 bytes. La representación en binario de -1 interpretado como un número sin signo corresponde al número 4294967295 (el mayor entero sin signo representable con 4 bytes). Por otra parte, el estándar de C dice que si inicializas un array dando valor solo a la primera componente, se usa el mismo valor para el resto de posiciones. Es una forma de forzar a reservar memoria estática.
  1. Acabo de probarlo y funciona perfectamente. No he tenido que usar ningún flag a mayores. Menudo crack!
  2. No acabo de entender que significa -1u

    ¿Infinito unsigned?
  3. Bah.... Usando cualquier librería de la boost te peta el compilador igual y el executable queda tan grande o más.
  4. #2 sep, eso es. Es una forma abreviada de escribir 0xffffffffu.

    No tengo el compilador delante, pero debo admitir que ser me hace raro que no acepte un número con signo como índice. ¿Alguien con un PC cerca para probar lo que pasa? :-D
  5. No digo que no sea algo ingenioso, pero asignar memoria estáticamente no tiene mucho mérito. No pasa de mera curiosidad.
  6. #2 El sufijo "u" hace que el número -1 se interprete como un "unsigned", que es un entero sin signo usando (al menos) 4 bytes. La representación en binario de -1 interpretado como un número sin signo corresponde al número 4294967295 (el mayor entero sin signo representable con 4 bytes). Por otra parte, el estándar de C dice que si inicializas un array dando valor solo a la primera componente, se usa el mismo valor para el resto de posiciones. Es una forma de forzar a reservar memoria estática.
  7. //byte byte disk
    1 shell "mkdir a"
    2 shell "cd a"
    3 goto 1

    valla me paso de 29 bytes ... me quito el sombrero ... :troll:
  8. Pero a que paginas nos enviais... que el firewall de la empresa no me deja entrar en la pagina (digo que será por la palabra 'hack') :-P
  9. Corrección a mi comentario en #6: no es verdad que el array quede inicializado con el mismo valor en todas las componentes. Lo que dice el estándar es que las posiciones para las cuales no se especifique valor se inicializarán con cero. Estaba pensando en el caso particular en el que uno especifica como primera componente un cero, que produce como efecto lo que comentaba en #6. Sobre lo de que se admita que "main" sea un array en vez de una función: stackoverflow.com/a/34764930
  10. #7 Eso te pasa por saltarte la "valla".
  11. #5 la gracia es hacerlo sobre main y no dentro de main.
  12. #11 y no usar 0xffffffff, max_int o similares
  13. Cuando se enteren los del Norton Antivirus se mueren de envidia,
  14. Yo solo cuento 16 bytes de código...
  15. #12 bueno, usar -1 en unsigned es muy habitual en programación en c por que es independientemde la arquitectura (8, 16, 32 o 64 bits) y mas portable que max_int.
  16. Bah, a mi no me sorprende. Cualquier programador Java ya esta acostumbrado a que cualquier cosa mas compleja que el Hola Mundo le ocupe gigas de espacio en memoria...
  17. Cabrones! Me hacéis viejo y torpe. Os odio a todos muy democráticamente (es decir, sin distinción de sexo, credo, raza ni nada) :-) :-)

    No me he enterado de nada, ni de vuestros comentarios tampoco. Esta os la guardo, pandilla de ratreasanguijuelas :-)
  18. #7 Ademas no has entendido la "prueba", tiene que ser algo compilado, no la salida de la ejecucion del programa, un bucle infito generaria infita memoria.
    La gracia esta en que esos 29 bytes, al compilarse (no al ejecutarse) generan un ejecutable de 16GB!
  19. #16 jajjajaj @rafaojosverdes ha convertido esto en un Pregúntame de tipo: Soy informático, respondo preguntas
    (pero su pregunta no tiene sentido, porque me parece que todos los informáticos somos vírgenes, no?)
  20. #20 lo usaba para cargarme los disquetes :troll: powerbasic y hay que compilar para ejecutarse
  21. #17 Al contrario, estas suponiendo que la máquina destino implementa los negativos en complemento a 2.

    Suele ser lo habitual, pero nadie te lo garantiza.
  22. #17 Al contrario, estas suponiendo que la máquina destino implementa los negativos en complemento a 2, cuando no es necesariamente cierto.
  23. #17 la prueba era generar el MAYOR número de bytes con el MÍNIMO de bytes de código
    muy currado, bien por el tío este
  24. #14 ¿Eres tonto?
  25. #15 cierto.

    0xffffffff tampoco es 500000, como dice el artículo.
  26. #21 ¿No todos lo somos? :troll:
  27. #14 Pues no sé si el chaval es virgen o no, pero yo soy informático y ha habido épocas en mi vida que tenía la polla envuelta en paños calientes de tanto follar (y sin pagar).

    Que pasa ¿que una cosa es incompatible con la otra?

    Es decir: ¿No puedes ser virtuoso en tu trabajo y el fin de semana dedicarte a follar con todas las chicas que puedas?

    #16
  28. #24 #23 ¿Lo puedes volver a explicar? Es que con dos veces no me ha quedado claro :troll:
  29. #15 más 13 de parámetros en la línea de comandos al compilar.
  30. #29 Este se quedó en los 80.
  31. A mi me da un error "/usr/bin/ld: final link failed: Memory exhausted"
  32. Con gcc compila, lo he probado para el standard 89 y también para el 11. Lo que si da es el warning típico de no especificar el tipo de main, habría que añadir cuatro bytes más para que la compilación sea limpia, lo que dejaría el fuente en 19 bytes con salto de línea al final:

    int main[-1u]={1};
  33. #26 ¿Tu también eres virgen?
  34. #35 ¿Tu también eres tonto?
  35. #15 Los flags usados al compilar tmb cuentan
  36. #30 La primera vez me dio un error y tuve que escribir el mensaje de nuevo :o
  37. #18 hombre, si por "cualquier cosa" te refieres a un contenedor j2ee con un EAR con unas pocas miles de clases, pues sí.
  38. #40 O una simple calculadora en un ejecutable, que el instalador que te crea por defecto la jdk 8 ocupa 150mb, y eso que solo es una triste ventana de javaFX sin imágenes...
  39. #18 Ese es el nivel. Se atreve a criticar a Java alguien que no sabe diferenciar entre espacio de memoria y espacio de compilado.. anda ya..
  40. #41 Si quieres ejecutarlo sin instalar el JRE pues es normal, sobre todo si usas JFX que es una librería que no venía en las versiones anteriores, pero si asumes que vas a tenerlo en la máquina el JAR generado son unos pocos KB
  41. #42 Los distingo perfectamente, solo aprovecho la fama que tiene Java de tragamemoria para meter un chiste con calzador.
  42. #29 yo siempre he dicho que la gente no hetero somos menos aceptados en el mundo de IT porque follamos más y tal. Pero en plan coña, ojo. xD
  43. No os basta con el propio Windows como ejemplo de compilado enorme con no demasiado sentido? :shit:
  44. #39 Tiene gracia. Casi me peta el PC de la risa xD
    Disclaimer. Me he pasado el finde con el UNK6 de pokemon (Superfriki)
  45. Habrán ganado por las reglas, así que no discuto su victoria pero me ha parecido poco creativo, habría que ver que han hecho los demás.
  46. #3 Con 29 bytes de Boost no has acabado ni el primer #ifdef :-P
  47. #48 Aquí está lo que han hecho los demás por si te pica la curiosidad:

    codegolf.stackexchange.com/questions/69189/build-a-compiler-bomb

    El de python 3 es mejor según la reglas, pero se gana por votaciones.
  48. mira que he tirado líneas de C pero nunca se me hubiera ocurrido algo como esto!
  49. Soy novato en esto. Pero supongo que empleará una función recursiva muy potente.
comentarios cerrados

menéame