Y además de eso, siguiendo una receta para gustarle a cual o tal compañía como bien nombras más arriba en tu mensaje. 

En Unix puedes usar el comando file para obtener algo de información, la naturaleza de un fichero se deduce de su encabezado y el magic number, más que de su extensión. Por eso uno podría hacer un archivo de texto con extensión .xyz y aún así sería un archivo de texto.

Por ejemplo haciendo file en un Makefile, nos da lo siguiente.


También puedes usar strings para ver si el contenido es legible o puedes deducir algo más.

Para futura referencia en Unix puedes checar si un puerto está ocupado usando netstat

Ejemplo para ver quién usa el puerto 8080


Si por otro lado quieres saber qué puerto está usando un binario cuyo nombre conoces:


Si tienes dudas, checa ExplainShell (https://explainshell.com)

Y un buen ejemplo hoy en día es Twitter/X, donde hay muchísimos posts que son simplemente engagement farming (buscadores de interacciones) siempre con las mismas temáticas, a veces hasta diciendo cualquier atrocidad para que los enojados les respondan (genrando más interacciones)

Y ni hablar de los bots que se meten a opinar en el contenido orgánico de forma ultra artificial como "Oh veo que ha dejado tu novio ¡ánimo! ¡el sol sale para todos!" 

Hola a todos, espero que estén muy bien. En este hilo les voy a contar un pequeño experimento que acabo de hacer con ChatGPT 4.0.

Desde hace un tiempo utilizo esta herramienta para pulir mi contenido, sobre todo cuando escribo en algún idioma que no es mi lengua madre o cuando retomo algún lenguaje de programación al que no esté muy acostumbrado. Sin embargo no suelo usarlo para generar cosas desde cero, y hoy decidí hacer una excepción al pensar "¿Qué tan bueno sería ChatGPT para armar un commodity ransomware?" Me planteé este experimento con el único parámetro de no colocar ni una sóla línea de código de mi parte, y limitarme a dar comentarios o acotaciones para "dirigir" al LLM.

Tuve muchas dudas al principio: ¿cómo va a plantearse la cifrado? ¿va a importar una librería como OpenSSL? ¿va a intentar invocar VeraCrypt como algunos ransomwares de bajo presupuesto? ¿cómo se las arreglará si le digo que trabaje con Ruby y lo limito a una versión viejita como la 2.7? Eran muchas preguntas y la única forma de averiguarlo era intentando.


Introducción

Comencé la conversación indicándole a ChatGPT las bases del proyecto:

- La intención es meramente educativa.
- Vamos a usar Ruby 2.7.
- Docker (nada de K8S, sólo Docker).

Instantáneamente generó tres archivos: el Dockerfile (archivo para construir la imagen del contenedor donde correrá el ransomware), el Gemfile (archivo de librerías de Ruby, similar al requirements.txt de Python) y obviamente, el ransomware que usaría OpenSSL para cifrar los archivos de la víctima (código fuente disponible al final de este hilo).




Análisis del código

A primera vista el código era bastante minimalista y directo. El Dockerfile crea un entorno de pruebas donde podrá correr el ransomware y cifrar dos archivos específicos, el ransomware parecía suficiente, pero el LLM cayó en un error muy común de algunos desarrolladores Ruby: declarar gemas en el Gemfile sin garantizar que sus dependencias a nivel SO estén presentes (especialmente si vas a utilizar Docker).


Casi inmediatamente actualizó el código fuente con las correcciones para instalar libssl-dev en el SO. A primera vista todo parecía funcional por lo que era hora de darle un nombre a nuestra creación.


Chococat Ransomware

Porque alguien tiene que ocupar el lugar que dejó BlackCat.



Ahora que teníamos una identidad era hora de crear una nota de rescate y nuestra propia billetera crypto para cobrar. Así fue como aprendí que ChatGPT sabe demasiado para ser inocente tiene un buen estilo para la extorsión:


Nota: los cuadrados negros deberían ser gatitos negros, pero el foro no los renderiza correctamente.

Ya tenemos nuestro ransomware falso listo para pasar a la etapa de pruebas construyendo el entorno con Docker:



Continuamos creando una carpeta y dentro de la misma dos archivos que serán cifrados por nuestro "ransomware":



Ejecutamos nuestro ransomware desde Docker, montando la carpeta víctima como volúmen y... oh si, nuestros archivos fueron cifrados:



Ahora probemos desencriptarlos para... oh no:



El ransomware dice que la llave de desencriptación y la nota de rescate fueron creadas pero... no están. Analizando en detalle la situación vemos que los crea en "./", es decir, dentro del propio WORKDIR de Docker que a diferencia de los volúmenes montados no tiene persistencia, se elimina al finalizar la ejecución del contenedor.

En otras palabras, no podemos descifrar los archivos de la víctima. Hicimos la gran Babuk Ransomware. Se lo expliqué a nuestro amigo ChatGPT y hasta lo tomó con cierto humor:



Nuevamente corrigió de inmediato el error y segundos después de ejecutar por segunda vez el entorno de pruebas, tuve la nota de rescate ante mis ojos:



A su lado en la misma carpeta, también tenía la llave de desencriptación:



Sin embargo, al revisar la llave noté algo importante: no tenía un formato amigable para que una eventual víctima pudiera usarla.



Si vamos a ser - en palabras de ChatGPT - un negocio respetable de cifrado tenemos que incorporar un servicio técnico de primer nivel y eso incluye el desarrollo y distribución de un desencriptador o decrypter. Unos segundos después de pedirlo, ya lo tenía listo para incorporarlo a nuestro lucrativo proyecto. Al probarlo, automáticamente detectó la llave y devolvió a su forma original los archivos cifrados.



La parte divertida - el experimento - había terminado. Ahora tocaba la parte aburrida, documentar... pero es algo que también le pedí que haga por su propia cuenta.


Próximos pasos

Fue una grata sorpresa ver que ChatGPT interpretara el proyecto al pie de la letra con mínimos errores (y muy específicos). Voy a mantener esa conversación en mi agenda para quizás en un futuro cercano agregar nuevas funciones como ofuscación de código, compilación de un único binario portable o detección de patrones de interés en el sistema víctima (como nombres o extensiones de archivos, copias de seguridad, etc). Acepto ideas y sugerencias.


Outro

Me sorprendió la facilidad con la que pudimos armar una PoC (prueba de concepto) casi sin errores y en menos de veinte minutos. Aproveché a charlar un poco más del tema con ChatGPT (siendo que anteriormente era muy evasivo al hablar de esto) e incluso le hice algunas preguntas ambiguas como:


Esta última pregunta tiene trampa. ChaCha, Camellia y Serpent son algoritmos de cifrado mientras que Whirlpool es una función de hashing. ChatGPT marcó esta diferencia e incluso me la explicó en detalle y con ejemplos de código.

Sé que esta es una pequeña PoC educativa y no representa la complejidad del panorama actual de la escena ransomware, pero aún así me pareció un experimento divertido. Recordemos que ni una línea de código es de mi autoría, yo solo di una idea y el LLM fabricó el producto y la nota de extorsión.

No es mi idea entrar en el juego de vender pánico por la IA, por el contrario, me llevé una grata sorpresa por la habilidad y madurez del modelo de ChatGPT. Sin embargo, es bueno reconocer que en manos equivocadas facilitaría muchísimo la tarea de "ser malo".

Por cierto, la conversación entera sobre este proyecto está publicada acá: https://chatgpt.com/share/08186c24-2974-40c5-9cb9-8e0b17b2f8bf (e incluye un saludo para la gente del foro).

El código fuente puede ser descargado de acá: https://mega.nz/file/wcc1TLRZ#WvxA-sWoXI6E_W5TrxFQ5At4CYj6yxMoCbVBW5_2xto.

Espero que les haya gustado y como siempre toda crítica constructiva es bienvenida.

Los dejo, es hora del crimen.

Hola!

Claro, cuando cargas una partida tienes dos posibilidades:

- Si lo haces desde el emulador (cargando el savefile como un quicksave) estás cargando un "state" (estado general) del cartucho en un momento dado, incluyendo los valores de la memoria. Esto claramente sobreescribe cualquier código que tengas activado. Lo interesante es que si activas un truco y haces un quicksave, como este es en realidad una modificación de la memoria queda almacenado cuando vuelvas a cargarlo.

- Si lo haces desde el juego (con el menú correspondiente) podrías disparar una rutina que "normalice" (limpie) todos los valores primero y luego coloque los de tu partida. Eso explicaría por qué no funciona.

En tu caso estás cargando dos partidas diferentes, dudo que funcione. Intenta cazar trucos en una misma partida ya sea nueva o cargada desde el menú contextual del juego y no con save-states, quicksaves u otras opciones del emulador.

Saludos!

¿Cómo estás Tachikomaia? Gracias por comentar!

El filtro de "old value" es justo el que doy como ejemplo acá cuando digo "busquemos una posición de memoria que tenga el valor 150 pero antes tenía valor 151" (ahí está el old value, 151). Los demás filtros aplican distintas lógicas para ayudarte a aislar esa posición.

Yo hacía eso mismo que mencionas en Final Fantasy Tactics y Resident Evil 2 (PSX), había situaciones donde muchos cheats "chocaban" entre sí y rompían todo, y entonces desactivaba gradualmente hasta que funcione  

Buenísimo análisis de Mario Tennis, recuerdo haberlo jugado (pero no hackeado) para Game Boy, así que era una versión ultra básica aunque sí contaba con medidores de fuerza y un doble como tú dices. Lo del bloc de notas lo hacía también con algunos Sharks como el de PSX (que venía en CD) porque no tenía más espacio en la Memory Card (y era una época de crisis como para ir a comprar una extra   ).

En los juegos "más complicados" pasa eso que mencionas, a veces se require más de un código y hay varios motivos:

- Hay varios sectores de memoria que componen el valor que queremos modificar.

- Hay un sector "testigo" - como un token canario - que guarda una copia de un valor específico y se va modificando a la par que el original. Si hay una diferencia inesperada entre los valores, se considera el del canario como válido y se "arregla" la diferencia reestableciendo el valor desde ahí. Esto lo puedes ver en juegos donde modificas por ejemplo el dinero, y este hace un "flash update" (lo ves actualizarse y de golpe volver al valor anterior en menos de un segundo).

- Existen barreras lógicas que monitorean que el valor esté en un rango esperado. Aunque la posición de memoria soporte el valor que estás expresando, una rutina de control podría decir "momento, no está bien que tengas este item/dinero/stat en este punto (o no está bien que lo tengas en ningún momento)" y le aplica una corrección.

- Podría ser que el juego en cuestión utilice alguna aleatorización de direcciones/espacio de memoria y por eso a veces los códigos funcionen y otras veces no (en las consolas sobre las que hago esto que son viejitas nunca lo he visto, pero quizás alguien pueda darnos más contexto en máquinas más modernas).

Para la consulta de Tsubasa no lo he visto en detalle pero es una buena pregunta, si funciona como un stat oculto suele ser bastante engorroso aislarlo (porque muchas veces también lo calculas a ciegas). Me pasaba en ciertos RPG con stats ocultas como "lealtad" / "amistad" (que no te avisaban tampoco cuando un personaje subía o bajaba el stat, ni te mostraba el valor exacto). Encontrarlo era difícil incluso usando los filtros: "debe ser un stat que subió porque la pelea salió bien"... si, pero la EXP y otros stats subieron también... y había 8 personajes en el tablero... si hacemos algunas multiplicaciones de stats * personajes...   (como decís, es un misterio a veces).

Lo de las fórmulas de Mario Tennis de momento te la debo, no lo sé honestamente   pero me lo llevo de tarea, porque está dentro de las consolas donde suelo destripar cartuchos   .

Esa última pregunta es buenísima porque es algo muy común de encontrar y te obliga a ejercitar mucho la lógica. En términos de programación para que una condición se cumpla pueden haber escenarios tan simples como complejos. Vamos a tomar el caso que me dices sobre los cristales que se rompieron (no jugué ese juego pero para el caso sirve):

Puede ser algo tan sencillo como que el programador haya hecho algo así:


O también


Y esto se traduciría en nuestro depurador como un cambio en una variable que pasó de "00" (0 o "falso") a "01" (1 o "verdadero"). Este es el tipo de caso sencillo que exploto en el cartucho del thread, una simple variable fácil de aislar. Cambiar este valor marcaría el evento como hecho.

Pero también existe la posibilidad que el programador haga algo como esto:

(recuerda que no jugué ese juego y estoy inventando condiciones para este ejemplo)


Puede ser que este cambio de escenario sea disparado tras monitorear varios aspectos (variables) y no sea fácil aislarlo. Quizás el evento nunca sea realmente marcado en la memoria como que "ocurrió", por ejemplo en GameBoy se puede usar el cambio de escena que inicia como el nombre indica un nuevo escenario. En el cartucho de ejemplo nunca marco "se dispara el escenario 3", sino "se cumplieron ambas condiciones del escenario 2, ejecuta un cambio de escena" (como en el último ejemplo que invocamos la función evento_romper_cristales()). Esa función puede no retornar ni escribir un valor, y su paso por la máquina no nos deja un registro claro, más allá de que el escenario avance.

Exactamente esto me pasó con The Dark Eye (https://en.wikipedia.org/wiki/The_Dark_Eye_(video_game)) donde logré dar por completados algunos escenarios pero olvidé marcar otras condiciones que ocurren a medio camino, quedándome soft-locked, y es común que te suceda en juegos que requieren muchos items y condiciones para progresar como las sagas Resident Evil, quizás logres bypassear una puerta molesta, pero en el trayecto para descubrir lo que la abre levantarías un item que te serviría más adelante (y que ahora no tienes por haber bypasseado).

Es mucho prueba y error. Ojalá te haya dado algunas ideas para intentar destripar esos juegos un poco más. Te dejo un abrazo y gracias por comentar.

Hola a todos, tras algunos años de ausencia he decidido volver al foro (https://foro.elhacker.net/foro_libre/presentacion-t521505.0.html;msg2278764#msg2278764), y qué mejor manera de hacerlo que ensuciándonos un poco las manos destripando cartuchos de Game Boy.

En este thread voy a compartirles un proyecto didáctico en el que estuve trabajando para explicar las bases de Game Hacking a usuarios que se acercaban al tema por primera vez.


Introducción

Seguramente muchos de ustedes ya han experimentado en su época con Cheat Engine, o incluso habrán llegado a conocer los llamados "game enhancers" como Game Genie o Game Shark. Algunos venían en formato CD (Game Shark para PSX) y otros eran un dispositivo de hardware dedicado que interconectaba la consola con el cartucho que quisieramos "mejorar" (Game Shark para Game Boy).

Estos "mejoradores" de juegos nos permitían activar "cheats" o "trucos" de una forma simple y efectiva: modificando los valores almacenados en memoria (ya sea una sola vez, por ejemplo para agregarnos dinero o items; o permanentemente evitando su modificación, por ejemplo para evitar perder puntos de salud y ser inmortales).

Acá les dejo una foto del mío, un GameShark para Game Boy que apareció en Uruguay sellado y con sus plásticos originales.







Hoy en día los propios emuladores traen plugins para cumplir la función de un GameShark (o Game Genie), por lo que decidí programar un cartucho de pruebas para - como mencioné al principio - poder explicar de forma virtual y simple los conceptos básicos de game hacking para cualquier interesado, y evitar que se pierda esta hermosa costumbre de destripar cosas para aprender cómo funcionan.


Game hacking en Game Boy

Como este proyecto apunta mayormente a la manipulación de registros de memoria (el "qué" - contenido - y el "dónde" - posición de memoria) no vi una necesidad imperiosa de incursionar en frameworks de desarrollo como gbdk o GBASM (el "cómo", en este caso), por lo que decidí utilizar GBStudio para ahorrar tiempo (y salud mental). Llamé a este proyecto "DVHR" (Damn Vulnerable Hack Rom), y decidí agregarle varios sprites para que sea tan didáctico como fuese posible. La emulación fue hecha con VisualBoyAdvance, el cual trae integrado un emulador de Game Shark.

El cartucho representa el viaje de un personaje desconocido por tres escenarios (desafíos) hasta llegar a reunirse con otros personajes desconocidos. La idea de esta premisa tan genérica es poder adaptar la narrativa a cualquier público que esté siguiendo el tutorial.



El primer escenario representa un problema clásico para toda aventura: la necesidad de fondos para emprenderla. Si miramos los indicadores superiores en la siguiente captura, veremos que nuestra bolsa está vacía (valor "0") y de no solucionar este inconveniente, no podemos avanzar al siguiente escenario.



En la esquina inferior izquierda el cartucho nos sopla la solución: 0101 98CB ¿pero qué significa esta cadena?

Este es un código Game Shark, a grandes rasgos:

0101 representa un valor.

98CB representa una posición de memoria.

Este código colocará los valores "0101" en la posición "98CB". Si espiaramos esa posición de la memoria en el cartucho en ese preciso momento, veríamos que el valor es "0". Esa posición está guardando el valor de nuestro dinero, por lo cual modificarla nos permitirá "mejorar" nuestra experiencia de juego.



Utilizando el plugin de Game Shark de VisualBoyAdvance podemos ingresar este "cheat" e incluso guardarlo con un nombre amigable (como en los Game Shark originales).

Al colocar este código el juego dará por concluído el desafío y nos llevará al siguiente escenario, donde un Goblin nos cortará el paso.



Para resolver este escenario deberemos modificar dos registros, uno donde se almacena el "Escudo" (y colocarlo en 1) y otro donde se almacenan los puntos de Salud del Goblin (colocándolos en 0 para... "mejorar" nuestra experiencia de juego).

Nuevamente el juego nos sopla dos cadenas, que nos ayudarán a entender mejor la estructura de los códigos Game Shark:

0101 9ACB: Colocar el valor "0101" en la posición "9ACB".

0100 9CCB: Colocar el valor "0100" en la posición "9CCB".

De acá podemos inducir dos cosas importantes (de nuevo, a muy grandes rasgos):

- Del primer sector de la cadena (los primeros 4 dígitos), los últimos dos son los que modifican el valor de las variables. En el primer caso vamos a colocar el valor en "01" (Escudo) y en el segundo en "00" (HP del Goblin), a pesar que ambos empiezan por "01".

- Hasta ahora, todas las posiciones de memoria que estamos modificando terminan en "CB", por lo que si bien no son contiguas, comparten un espacio acotado y relativamente cercano. Esto también podemos saberlo leyendo los documentos técnicos sobre manejo de memoria de la consola y la documentación de los MBC (Memory Bank Controllers). Pero un recién interesado en el tema claramente no disfrutará haciéndolo.

Agregando estos dos códigos nos haremos con un nuevo escudo, una piel de Goblin y un nuevo desafío. O mejor dicho... dos.



Esta vez tenemos dos enemigos que nos cortan el paso: una Serpiente y un Murciélago, pero ya no hay soluciones disponibles. Al parecer, los puntos de Salud (HP) de la Serpiente oscilan entre 2 y 4 (y tenemos que bajarlos a 0) y los del Murciélago oscilan entre 6 y 8 (y claramente, también hay que bajarlos a 0).

Tenemos la siguiente estructura de códigos:

0100 ??CB: Colocar el valor "0100" en la posición "??CB".

0100 ??CB: Colocar el valor "0100" en la posición "??CB".

Sabemos que hay que colocar en "00" dos valores ubicados en la misma "vecindad" (espacio) de memoria donde vinimos trabajando hasta el momento. Parece que se nos ha agotado la suerte pero no, es hora de aprender a buscar cheats como en la vieja escuela... rompiendo.

Un feature que tenían los Game Sharks (no todos, sino algunas versiones) es la capacidad de "buscar" trucos... ¿cómo funciona? buscando un valor específico a lo largo de la memoria y siguiendo eventuales cambios para aislar e identificar posibles posiciones de memoria de interés.

En palabras más simples, supongamos que nuestro personaje tiene un valor específico de "Oro", por ejemplo, 151. Mapeamos el valor 151 y nuestro "mejorador" de juegos va a darle seguimiento, dándonos una lista de todas las posiciones de memoria del juego que estén guardando ese valor (que podrían ser muchísimas). Gastamos 1 de Oro y el valor ya no es 151, sino 150. Ahora no buscamos "qué posición tiene en este momento el valor 150", sino "qué posición tiene en este momento el valor 150 y anteriormente tenía el valor 151". Esto desencadena un proceso de eliminación que nos irá arrojando cada vez menos candidatos hasta identificar la posición específica que queremos manipular. Una suerte de "Adivina quién" pero con un depurador.

El "Game Shark" integrado en la mayoría de los emuladores permite este comportamiento, así que vamos a buscar valores de interés. Comencemos por el valor "techo" del HP de la Serpiente: 4.



Aparentemente, ninguna posición de memoria está guardando ese valor, por lo que sabemos que no es el que estamos buscando. Repitamos el proceso para el valor "techo" del HP del Murciélago: 8.



Bingo, encontramos varios candidatos y uno está en la vecindad que buscamos ("CB").

Acá es donde varios habrán notado algo extraño: la notación de la dirección de memoria está "al revés" ("CB" está primero que "A0"). Esta diferencia en la notación es común, a veces ciertas instrucciones o direcciones se representarán "al revés" según el programa (o plug-in) que estmos utilizando. Los que en algún momento de sus carreras hayan usado debug.exe en Windows para programar en ASM sabrán a lo que me refiero.

Vamos a colocar ese valor en "0", y continuamos repitiendo el proceso con los demás valores (2 y 3 para la Serpiente) hasta aislar las posiciones de memoria sospechosas.



Acá es donde viene útil una advertencia amistosa: cuando estén buscando cheats o manipulando la memoria de un programa en general, es muy común que a veces identifiquemos mal una dirección, alteremos su valor y suframos consecuencias inesperadas. En los cartuchos de Game Boy el peor escenario posible es un Kernel Panic, nada que no se resuelva reiniciando la consola o el emulador. Pero es ideal tener sumo cuidado cuando se manipula la memoria de algún otro proceso "más serio" que no esté aislado por un emulador ni sea un simple juego didáctico.

Ejemplo de un Kernel Panic en Game Boy:



Una vez que aislamos las posiciones de memoria sospechosas y cambiamos los valores necesarios, lograremos resolver el desafío.



Si prestan atención verán debajo la solución del mismo. Si prestan aún más atención, verán que el cheat resaltado en el Game Shark no se corresponde a esas soluciones, sino que fue un error de mi parte al intentar aislar e identificar la posición de memoria (y afortunadamente, no causó un Panic).



Finalmente nuestro personaje llegó al final de su aventura (sea cual sea su objetivo) y pudimos explicar de forma didáctica una introducción básica a cómo funciona el Game Hacking de la vieja escuela.


Outro

Espero que el hilo no se haya hecho tedioso ni extenso. Desde ya es un gusto estar de vuelta con ustedes, y cualquier crítica constructiva siempre es bien recibida.

Espero que les haya gustado, nos vemos en la próxima.


Referencias y links de interés
- Tweet con las fotos originales: https://twitter.com/MauroEldritch/status/1591444536152449024
- Una historia de cartuchos piratas: https://twitter.com/MauroEldritch/status/1740129623814414704
- Descargar una copia de DVHR: https://mega.nz/file/Jc0kTITD#v8PQbbZojCN1yuoPhtFqoQ9HxLyHb6CH4IyUjuUEO9I
- GBStudio: https://www.gbstudio.dev/es/
- VisualBoy: https://visualboyadvance.org/

Ningún Goblin fue lastimado durante la producción de este artículo.

Gracias estimado, es bueno estar de vuelta 

Hola Daniel y gracias por la bienvenida!

Si, en este caso hay varios que no volví a ver por aquí, pero bueno intentaré abrir algunos threads para revivir un poco las temáticas que teníamos en esa época 

Lo mismo digo, a su disposición y un gusto estar de vuelta, saludos!