Esta vez he cumplido, me he entretenido mucho y he sufrido muchos dolores de cabeza, por culpa del AntiRunPE. ¿Alguien se imagina lo complicado que puede ser escribir en memoria sin tener WriteProcessMemory? ¿Alguien se imagina lo complicado que puede llegar a ser, una vez que tras 20 pruebas, encuentras una que escribe en memoria, utilizar otra diferente a OpenProcess? Pues nuestro amigo, tal y como vimos, nos deja inutilizadas, tanto una como otra, y os puedo asegurar que he rozado la locura, pero... Todo esfuerzo tiene recompensa... ¡Y lo he conseguido! Un programa que tras ser ejecutado en el AntiRunPe, ejecute sus acciones maléficas. Muahahahha
Siempre que he leído a los grandes de CracksLatinos, una de las cosas que más me molestaba, era... ¿Por que son todos mejores que yo? Saben siempre donde pinchar, y aciertan... Por lo que contaré la aventura real, y para aquellos que no quieren tochaco, al final tienen el módulo en VB, que saltea al Anti RunPE.
Primero de todo sabía que tenía que restaurar lo que modificaba el programa de physmera, así que debía comenzar luchando para restaurar el orden de: OpenProcess y WriteProcessMemory. Los 2 apis que utiliza un runpe normal y corriente.
El primer golpe, fue hacerlo todo estupendo de la muerte, para WriteProcessMemory, horas después de estar escribiendo un código funcional, me daría cuenta de que OBVIAMENTE al estar hookeadas, no me funcionarían. ¡PALMFACE! Sí, no estuve muy lucido.
Mi siguiente idea fue... Si puedo cargar una DLL en memoria, ¿la podré descargar? ¿La podré Recargar? Como idea es maravilloso, me hookean el código, recargo la librería y tengo todo de nuevo funcional y todo mi anterior trabajo, podía reutilizarlo. Vale... No encontré ninguna formula mágica para hacer eso xDD.
Recordando algún tuto, sabía que GetProcAddress, y LoadLibraryA, me podrían permitir cargar una librería en memoria, con ayuda de Ollydgb (mi fiel compañero sancho en esta batalla), pude comprobar que es correcto, carga una Liberia en memoria, de dicha Liberia saca la parte donde está WriteProcessMemory, ¿y sabéis que? :D, ¡No sirve! Me lleva directo a la zona hookeada!! Si ya está en memoria, lo reutiliza...
Ahora ya sí que sí, no puedo fallar... ¡La api RtlMoveMemory! Sí, hace justo lo que necesito, sólo tengo que cambiar un poco la idea inicial, no pasa nada, reescribo todo el código para esta api, lo ejecuto, ¡ostión!, ¿pero que!!?, ale a estudiar por que me falla, con una búsqueda normal, nada, con una búsqueda de un ratito largo, alguien hace la indicación de que la escritura a la librería tiene una protección, que ha de saltarse dándole permisos de "lectura, escritura y ejecución", miro con olly.. Y curiosamente tiene estos permisos... Me estudio como aplicar el api VirtualProtect, para darle los permisos... y... ¡Funciona! (por cierto, con WriteProcessMemory esto no es necesario y me enfado mucho :P)
Para comprobar si alguien está usando el programa de physmera, leo en memoria el primer byte de Write..., esto es así, por que desde el primero ya lo modifica, para ello sólo necesito llamar a OpenProcess, ReadProcessMEmory, y recibir el valor, comparar y proceder a la acción requerida.
Ya tenemos, la zona de memoria con los permisos buenos, ya tenemos una forma de restaurar la api, y de comprobar si nos han hookeado, lo probamos todo y.. ¡Funciona! ¡Funciona perfectamente! (esto, el sábado por la tarde). Por fin, puedo añadir el modulo a un RunPE normal, y probar su correcta ejecución. Perfecto, desde mí modulo de VB, todo correcto. Esto al final está tirado...
Creo un stub funcional con mi amada y cariñosa calculadora de Windows, y con mi modulo perfectamente funcional, lo ejecuto y!! Mi programa no detecta nada, y el de pysmera, funciona como si tal cosa... A buscar que esta fallando... De alguna vez trastear con cracking, recordaba que OpenProcess, no puede ser llamado 2 veces, por distintos programas... ¿sabéis quien necesita el handle de OpenProcess? ¡¡ReadProcessMemory!! ¡Estoy como al comienzo! Esto no funciona, por que no detecta si me hookearon o no, y ante la duda funciona sin modificar nada...
De nuevo, toca estudiar, como cerrarle un handle a otro proceso... Vueltas y más vueltas, prueba aquí, prueba allá... No encuentro nada que me permita esta forma de intrusión en otro proceso, por lo que toca estudiar sobre OpenProcess, y descubro, que se puede duplicar, sólo necesito tener... ¡EL HANDLE ORIGINAL! Sí, duplicateHandle, me pide el original, fantástico... Otro api, que no me sirve... De veras, todo esto en ASM, me hubiese llevado mucho menos rato xD.
Buceando, descubro que puedo conseguir un handle funcional con GetCurrentProcess :D, probamos y desde código, funciona perfectamente, cumple con lo que necesito... Ahora sólo nos queda probarlo con el AntiRunPE, lo ejecuto y por fin... por fin... Hace el baile en la memoria, y se ejecuta mi calculadora... Eso sí, recibiendo un error en el programa que realiza el unpack, lo pasamos a olly, y veo que la rutina del error, se decide si el fichero que busca "existe". Le hago una copia del solitario (por que es muy inofensivo). Y ¡Tachan! Aplicación engañada en apenas.. ¿3 días? XD
Resumen:
-Cargamos librería
-Cargamos dirección del procedimiento
-Leemos en memoria
-Comparamos si esta hookeado seguimos
-Harcodeamos (winXP sp3). Los datos de WriteProcessMemory
-Lo pasamos a un array de bytes (Esto es por mi comodidad)
-Desprotegemos las zonas de memoria afectadas
-Copiamos a memoria los datos buenos
-Liberamos la librería de memoria
-Copiamos el solitario pa tocar las narices.
-¡Fin!
¿Ahora a que parece fácil?
Aquí, adjunto tanto el Carbon Crypter, con el que hice las pruebas, como el módulo de VB, válido para Windows XP SP 3. Ya que las direcciones estan hardcodeadas.
Link de descarga
Mostrando entradas con la etiqueta crypter. Mostrar todas las entradas
Mostrando entradas con la etiqueta crypter. Mostrar todas las entradas
28/3/11
21/3/11
Sexo con crypters
Algunos ya saben que me gusta mantener mis relaciones sexuales con un alto contenido en binario, tras un par de noches de insomnio, me recorria una duda... ¿Cómo funcionaría el Runpe Killer de Psymera? Lo que conozco de dumpear un proceso, requiere que se encuentre ya en memoria, para poder acceder al mismo. Con esta premisa, ¿Podría saltar desde algún sitio hasta mi bicho? Es decir, quien lo quisiera analizar, estaría obligado a infectarse, y si se realiza bien, no se daría cuenta de que ocurrió.
Nota: El destino del tutorial, no es ir infectando, ni haciendo mal. Es demostrar que con una utilidad, "segura", en este caso, una aplicación de defensa, que bien podría ser un antivirus, un firewall, o cualquier otra herramineta. Se tiene tambien que tener siempre cuidado. Por este motivo, es útil, trabajar en máquinas virtuales.
Por lo que aquí, comienza mi aventura analizando algo que no sea un serial.
Probando puntos clave, decido poner un BP (Break Point), en sitios que se me ocurre tendrán que cargar, los bp son:
-GetThreadContext
-CreateProcessA
-SetThreadContext
-WriteProcessMemory
-VirtualAllocEx
-ReadProcessMemory
Si alguien pregunta ¿Por que? Creo que yo, utilizaría esos, para realizar una aplicación de este tipo, sí, SetThreadContext, quizá es un poco abusivo, pero yo el sexo con binarios lo hago duro.
La primera en la frente, bajé un crypter público de indetectables, precisamente algunos de los que nombra el killer, no tenía ganas de codearme uno, y así hacia el reto más complicado, desconocia los vicios programando de ambos bichos.
Primera parada; Puerta de Arganda, lo siento. CreateProcess, me dice que hemos llegado, me llama la atención un punto, el flag del programa está en Deatached_process ¿Por qué? ¿Qué es esto? No me queda muy claro en la especificación de win32 sdk, viene a ser para el correcto funcionamiento de aplicativos de consola. Personalmente creo que no sería necesario pero...
Si me quedo haciendo el bobo, el programa sale directamente en memoria, y tenemos la infección completada, aquí tengo una pista, al salir del ret, descubro que es lo que ocurre... Un SuspendThread, justo antes un push eax, que contiene la dirección del proceso que ha creado recientemente.
De nuevo, si tardo, no sólo lo ejecuta 1 vez, si no que pueden llegar a ser hasta 4 (aumentando en 5 segundos cada vez el tiempo de pausa en sleep). Supongo que busca algo en el proceso creado, al no encontrarlo, lo llama de nuevo. Todo esto, es opinión, aun no lo he analizado.
Traceando veo que realiza una busqueda de EAX = 1, cuando intenta escribir en el proceso, si ha fallado, vuelve a intentarlo una y otra vez, por este motivo se me estaba ejecutando tantas veces; Para solucionarlo con un editor hexadecimal, cambié el EP, por EB FE, un salto sobre si mismo, así dejo el proceso loopeando, y puedo tardar cuanto tiempo quiera, simplente debo recordar restaurar el valor correcto una vez finalizado.
La aplicación realiza:
-Abre la aplicación
-Espera 20 milisegundos ¿? No tengo muy claro, el por que... Supongo que da cuartel para que abra. De ahí que si en 20 milisegundos, no controló la aplicación, la vuelva a llamar (esto es malo, significa INFECTADOS). Personalmente, sin animo de molestar al programador, yo, la hubiese ejecutado directamente pausada. Me evito el trabajo de dormir mi aplicación, y puedo asegurarme que no me infecto. De todos modos, el programador, ya avisa de esta posibilidad.
-Crea una nueva sección donde meterá la ruta del ejecutable, es decir la que utilizará despues, cuando modifica WriteProcessMemory.
-Escribe en la nueva sección creada en el ejecutable,
-GetProcessAddress; Ahora empieza lo divertido
-Localiza: OpenProcess
-Parchea OpenProcess, con 12 bytes, que sólo hacen mover 0 a EAX, para indicar que todo fué bien.
-Localiza: WriteProcessMemory
-Parchea WriteProcessMemory con 127 bytes, guarda los registros, y procede a copiar todo lo que entra en la api, directamente sobre un fichero, cuya ruta está indicada en la sección nueva que crea el programa.
-Finalmente al pulsar el botón, unpack, nos reanuda el proceso, con todas las modificaciones que se han realizado anteriormente.
Mi reto ahora consiste en A) Parchear de forma que el programa realize la carga en suspendido, y no como lo hace actualmente, (por seguridad), B) añadir un código, haré un modulo que exportaré para que lo use quien quiera, que nos permita saltar el actual Runpe Killer; tambien el parcheado por mi.
Pero tanto para obtener el programa como para obtener el modulo tendreis que esperar al próximo post, que con una poca suerte, no será dentro de 3 o 4 meses.
Pd: Por último y no menos importante, agradecer el trabajo a psymera, espero que no se ofenda por algún comentario que hago, de verdad, no son con maldad, lo que has programado está genial. Simplemente aporto una visión diferente.
Un saludo,
WiNSoCk.
Nota: El destino del tutorial, no es ir infectando, ni haciendo mal. Es demostrar que con una utilidad, "segura", en este caso, una aplicación de defensa, que bien podría ser un antivirus, un firewall, o cualquier otra herramineta. Se tiene tambien que tener siempre cuidado. Por este motivo, es útil, trabajar en máquinas virtuales.
Por lo que aquí, comienza mi aventura analizando algo que no sea un serial.
Probando puntos clave, decido poner un BP (Break Point), en sitios que se me ocurre tendrán que cargar, los bp son:
-GetThreadContext
-CreateProcessA
-SetThreadContext
-WriteProcessMemory
-VirtualAllocEx
-ReadProcessMemory
Si alguien pregunta ¿Por que? Creo que yo, utilizaría esos, para realizar una aplicación de este tipo, sí, SetThreadContext, quizá es un poco abusivo, pero yo el sexo con binarios lo hago duro.
La primera en la frente, bajé un crypter público de indetectables, precisamente algunos de los que nombra el killer, no tenía ganas de codearme uno, y así hacia el reto más complicado, desconocia los vicios programando de ambos bichos.
Primera parada; Puerta de Arganda, lo siento. CreateProcess, me dice que hemos llegado, me llama la atención un punto, el flag del programa está en Deatached_process ¿Por qué? ¿Qué es esto? No me queda muy claro en la especificación de win32 sdk, viene a ser para el correcto funcionamiento de aplicativos de consola. Personalmente creo que no sería necesario pero...
Si me quedo haciendo el bobo, el programa sale directamente en memoria, y tenemos la infección completada, aquí tengo una pista, al salir del ret, descubro que es lo que ocurre... Un SuspendThread, justo antes un push eax, que contiene la dirección del proceso que ha creado recientemente.
De nuevo, si tardo, no sólo lo ejecuta 1 vez, si no que pueden llegar a ser hasta 4 (aumentando en 5 segundos cada vez el tiempo de pausa en sleep). Supongo que busca algo en el proceso creado, al no encontrarlo, lo llama de nuevo. Todo esto, es opinión, aun no lo he analizado.
Traceando veo que realiza una busqueda de EAX = 1, cuando intenta escribir en el proceso, si ha fallado, vuelve a intentarlo una y otra vez, por este motivo se me estaba ejecutando tantas veces; Para solucionarlo con un editor hexadecimal, cambié el EP, por EB FE, un salto sobre si mismo, así dejo el proceso loopeando, y puedo tardar cuanto tiempo quiera, simplente debo recordar restaurar el valor correcto una vez finalizado.
La aplicación realiza:
-Abre la aplicación
-Espera 20 milisegundos ¿? No tengo muy claro, el por que... Supongo que da cuartel para que abra. De ahí que si en 20 milisegundos, no controló la aplicación, la vuelva a llamar (esto es malo, significa INFECTADOS). Personalmente, sin animo de molestar al programador, yo, la hubiese ejecutado directamente pausada. Me evito el trabajo de dormir mi aplicación, y puedo asegurarme que no me infecto. De todos modos, el programador, ya avisa de esta posibilidad.
-Crea una nueva sección donde meterá la ruta del ejecutable, es decir la que utilizará despues, cuando modifica WriteProcessMemory.
-Escribe en la nueva sección creada en el ejecutable,
-GetProcessAddress; Ahora empieza lo divertido
-Localiza: OpenProcess
-Parchea OpenProcess, con 12 bytes, que sólo hacen mover 0 a EAX, para indicar que todo fué bien.
-Localiza: WriteProcessMemory
-Parchea WriteProcessMemory con 127 bytes, guarda los registros, y procede a copiar todo lo que entra en la api, directamente sobre un fichero, cuya ruta está indicada en la sección nueva que crea el programa.
-Finalmente al pulsar el botón, unpack, nos reanuda el proceso, con todas las modificaciones que se han realizado anteriormente.
Mi reto ahora consiste en A) Parchear de forma que el programa realize la carga en suspendido, y no como lo hace actualmente, (por seguridad), B) añadir un código, haré un modulo que exportaré para que lo use quien quiera, que nos permita saltar el actual Runpe Killer; tambien el parcheado por mi.
Pero tanto para obtener el programa como para obtener el modulo tendreis que esperar al próximo post, que con una poca suerte, no será dentro de 3 o 4 meses.
Pd: Por último y no menos importante, agradecer el trabajo a psymera, espero que no se ofenda por algún comentario que hago, de verdad, no son con maldad, lo que has programado está genial. Simplemente aporto una visión diferente.
Un saludo,
WiNSoCk.
4/8/09
¿Como es un crypter? ¿Para que es? y más...
Poco a poco voy a ir soltando y desplegando conocimientos para que todo el mundo pueda optar a entender un poco más lo que utiliza y lo que programa.
¿Qué es un crypter?
Pese a que podré ser colgado por un experto, podríamos definir sin equivocarnos que un crypter será la herramienta que nos transforme un fichero A en un fichero B, realizando cambios (muchos o pocos), sobre el fichero original A, y añadiendole o no alguna funcion que antes no tenia.
¿Para que nos sirve un crypter?
-Habitualmente se utiliza para evitar la decompilación del código, al menos tratar de complicarlo.
-Saltar la heuristica de los antivirus.
-Simplemente camuflar un fichero bajo la apariencia de otro (normalmente, haciendo creer que es inofensivo)
¿Hay tipos de crypter?
Existen 2, pese a que podriamos catalogarlos en más.
-Runtime pueden llegar a ser ejecutados, sin que sean detectados por un anti virus por ejemplo.
-Scantime no son ejecutados, simplemente cuando un antivirus scanea en busca de firmas, heuristica, etc, no detectará nada extraño sobre este fichero.
¿Como funciona un crypter?
Lo normal es que existan 2 ficheros, el primero se encangará de realizar el pastel, es decir, mezclar, batir y aliñar nuestro programa. El segundo, será un lanzador o stub, se encargará de situar el código de nuestro programa en memoria.
¿Puedes ser más técnico?
Aquí es la zona que a mi me gusta, y en la que creo despistaré a unos cuantos.
Previo a entrar en materia supongamos que tenemos un fichero virusmortal.exe, el código de mi virusmoral, será: linea que hace todo el mal.
Un crypter, leera el código de mi programa, en este caso situará en una variable: "linea que hace todo el mal", suponemos que los antivirus detectan por firma la palabra "mal". nota; tristemente el funcionamiento de los antivirus es bastante parecido a esto.
Si guardamos el contenido de la variable, de nuevo en un fichero nuestro antivirus (de ahora en adelante AV), saltará y nos avisará. Por lo tanto algo tiene que hacer el crypter, dependiendo del programador, aplicará una tecnica, ya sea dar la vuelta a la cadena, o encriptarla con xor, con base64, por comodidad yo utilizaré base64.
El programa pasará la cadena que tenia en la variable, por una funcion que me codificará el el texto almacenado, en base64, nos quedaría: "bGluZWEgcXVlIGhhY2UgdG9kbyBlbCBtYWw=". Si guardamos esto de nuevo en virusmortal.exe, NO funcionará, ha perdido el poder de ser ejecutado. Tendriamos un fichero en scantime.
Aquí es donde entra a funcionar el stub, este tambien es un fichero ejecutable, suele funcionar con un código similar a este pseudocódigo:
-Busco mi ruta
-Leo todo mi código
-Ejecuto en memoria todo lo que hay debajo de mi.
Como se puede observar si ejecutamos este fichero, no pasará nada, pues por si solo es completamente inofensivo. Un crypter nos mezclará el código obtenido antes en base64 y pondrá encima de dicho código el stub. El código finalmente quedaría:
-Busco mi ruta (ej: c:\bichito_encriptado.exe)
-Leo todo mi código: Rutinas varias para ejecutar código, des-encriptar, etc.
-Ejecuto en memoria el código des-encriptado: "bGluZWEgcXVlIGhhY2UgdG9kbyBlbCBtYWw=".
El stub... Un poco más a fondo.
Tal y como se ha podido ver, una gran parte del trabajo lo tendrá el stub. Para el programador, es el que más juego puede proporcionar pues se le pueden añadir tantas rutinas como se quiera. Es decir, podriamos meter todo lo necesario para tener un fichero con nuestro código virico, pero no solo eso, si no a su vez que este se replicase por usb por ejemplo. Cosas que se me ocurren podrian ser:
-Replicacion de usb.
-Replicacion por programas de P2P.
-Modificar el fichero host. Para esquivar actualización de los Av.
-Añadir rutinas que imposibiliten o dificulten el analisis. Is debugger present, anti-anubis....
-Crear un nuevo proceso, para asi poder mostrar que la aplicacion funciona y no un simple mensaje de error...
-Modificar algún fichero de sistema o varios, ej: Salvapantallas para que pueda cargar nuestro amigo, taskmngr,explorer,firefox...
Por supuesto cuantas más opciones más fácil será detectarlo, pues facilitas las firmas a las compañias AV, si detectan ejecución en memoria, más leer fichero... blanco y en botella.
NOTA IMPORTANTE: Toda esta información es para aquellos que os dedicais al analisis, detección, programación, por hobby o por trabajo. Nunca deberá ser utilizada para cometer maldades... Sobra recordar que ir infectando máquinas por ahí es un delito y tiene penas de prisión.
¿Qué es un crypter?
Pese a que podré ser colgado por un experto, podríamos definir sin equivocarnos que un crypter será la herramienta que nos transforme un fichero A en un fichero B, realizando cambios (muchos o pocos), sobre el fichero original A, y añadiendole o no alguna funcion que antes no tenia.
¿Para que nos sirve un crypter?
-Habitualmente se utiliza para evitar la decompilación del código, al menos tratar de complicarlo.
-Saltar la heuristica de los antivirus.
-Simplemente camuflar un fichero bajo la apariencia de otro (normalmente, haciendo creer que es inofensivo)
¿Hay tipos de crypter?
Existen 2, pese a que podriamos catalogarlos en más.
-Runtime pueden llegar a ser ejecutados, sin que sean detectados por un anti virus por ejemplo.
-Scantime no son ejecutados, simplemente cuando un antivirus scanea en busca de firmas, heuristica, etc, no detectará nada extraño sobre este fichero.
¿Como funciona un crypter?
Lo normal es que existan 2 ficheros, el primero se encangará de realizar el pastel, es decir, mezclar, batir y aliñar nuestro programa. El segundo, será un lanzador o stub, se encargará de situar el código de nuestro programa en memoria.
¿Puedes ser más técnico?
Aquí es la zona que a mi me gusta, y en la que creo despistaré a unos cuantos.
Previo a entrar en materia supongamos que tenemos un fichero virusmortal.exe, el código de mi virusmoral, será: linea que hace todo el mal.
Un crypter, leera el código de mi programa, en este caso situará en una variable: "linea que hace todo el mal", suponemos que los antivirus detectan por firma la palabra "mal". nota; tristemente el funcionamiento de los antivirus es bastante parecido a esto.
Si guardamos el contenido de la variable, de nuevo en un fichero nuestro antivirus (de ahora en adelante AV), saltará y nos avisará. Por lo tanto algo tiene que hacer el crypter, dependiendo del programador, aplicará una tecnica, ya sea dar la vuelta a la cadena, o encriptarla con xor, con base64, por comodidad yo utilizaré base64.
El programa pasará la cadena que tenia en la variable, por una funcion que me codificará el el texto almacenado, en base64, nos quedaría: "bGluZWEgcXVlIGhhY2UgdG9kbyBlbCBtYWw=". Si guardamos esto de nuevo en virusmortal.exe, NO funcionará, ha perdido el poder de ser ejecutado. Tendriamos un fichero en scantime.
Aquí es donde entra a funcionar el stub, este tambien es un fichero ejecutable, suele funcionar con un código similar a este pseudocódigo:
-Busco mi ruta
-Leo todo mi código
-Ejecuto en memoria todo lo que hay debajo de mi.
Como se puede observar si ejecutamos este fichero, no pasará nada, pues por si solo es completamente inofensivo. Un crypter nos mezclará el código obtenido antes en base64 y pondrá encima de dicho código el stub. El código finalmente quedaría:
-Busco mi ruta (ej: c:\bichito_encriptado.exe)
-Leo todo mi código: Rutinas varias para ejecutar código, des-encriptar, etc.
-Ejecuto en memoria el código des-encriptado: "bGluZWEgcXVlIGhhY2UgdG9kbyBlbCBtYWw=".
El stub... Un poco más a fondo.
Tal y como se ha podido ver, una gran parte del trabajo lo tendrá el stub. Para el programador, es el que más juego puede proporcionar pues se le pueden añadir tantas rutinas como se quiera. Es decir, podriamos meter todo lo necesario para tener un fichero con nuestro código virico, pero no solo eso, si no a su vez que este se replicase por usb por ejemplo. Cosas que se me ocurren podrian ser:
-Replicacion de usb.
-Replicacion por programas de P2P.
-Modificar el fichero host. Para esquivar actualización de los Av.
-Añadir rutinas que imposibiliten o dificulten el analisis. Is debugger present, anti-anubis....
-Crear un nuevo proceso, para asi poder mostrar que la aplicacion funciona y no un simple mensaje de error...
-Modificar algún fichero de sistema o varios, ej: Salvapantallas para que pueda cargar nuestro amigo, taskmngr,explorer,firefox...
Por supuesto cuantas más opciones más fácil será detectarlo, pues facilitas las firmas a las compañias AV, si detectan ejecución en memoria, más leer fichero... blanco y en botella.
NOTA IMPORTANTE: Toda esta información es para aquellos que os dedicais al analisis, detección, programación, por hobby o por trabajo. Nunca deberá ser utilizada para cometer maldades... Sobra recordar que ir infectando máquinas por ahí es un delito y tiene penas de prisión.
Suscribirse a:
Entradas (Atom)