16/9/11

Formas de conocer chicas

Está claro, lo vemos día tras día. El mundo de internet es para el porno. Lo sé, no he descubierto nada nuevo. Existen webs de anuncios, contactos, rasca y gana :P. Tenemos un poco de todo. Y alguno estará dudando, si esto era o fue, un blog de informática. Pues sí, y no deja de serlo. Al ataque.

Primero, tenemos a una chica vasca. Muy guapa ella. Decide, salir en TV, para explicar que su teléfono, era de una prostituta, y luchar, por sus 9€ (Joder con la crisis) para que le den otra línea. Yo, viendo a la muchacha, a pesar de que explica que tiene novio, soy un valiente. Pensé en llamar a la TV, y decirles que me parecia muy atractiva, que si les importaría darme su teléfono para conocerla y tal, pero realmente lo vi poco optimo. No creo que colaboren en este tipo de peticiones, a pesar de que suelo ser muy educado.

Ella y su momento: http://www.eitb.com/es/videos/detalle/736622/euskadi-directo-mi-numero-movil-era-prostituta/

Simplemente, visionando el vídeo, empiezan a dar enlaces, referencias, para que la noticia tenga un poco más de chicha. Por lo que empiezo a tirar de la manta, y simplemente buscar lo que me ofrecen en la noticia.


La primera en la frente. Click en el enlace, y sorpresa, ya han dado de baja el anuncio. Tenia la necesidad de descubrir el teléfono, para hacerle ver mi interes, y demostrarle que valgo más que su novio, a pesar de los kilometros que nos separan. Decido probar con la cache de google.



Como se puede comprobar, continua completamente visible, he tapado 2 dígitos, por que desconozco hasta que punto es legal o no. Y por que tampoco me interesa, continuar jodiendo la vida a la pobre chica. Sé que la gente de la TV, va a continuar mostrando información que a mi juicio se pasa de lo necesario para informar. Ahora, eso sólo es mi opinión.

PD: A los interesados en mi estado sentimental con la chica. Confesar que he preferido no molestarla, a pesar de saber que tras ver mi interes, no tendría duda alguna y se vendría conmigo, pero hoy, no tengo ganas de estropear la relación de nadie.

16/6/11

Tutorial. Hotel Mogul {Reversing / Cracking}

En vista de lo chungo que está el asunto, pondré lo típico que recomendará mi abogado en el futuro. Toda la información aquí referida, es para aprender, estoy en contra de la pirateria y el reggeton, etc... (El etc, significa, vease el texto tipico de cese de responsabilidad y esas cosas). Por si acaso, no adjunto crack. Aquí que cada perro se lama...

Siento, la calidad de las imagenes, si haceis click, se ven perfectamente. Insisto, lo siento.

Comienzo
Descripción Protección del juego basada en límite de tiempo. Sólo permite probarlo durante 30 minutos, después cobra 7€.
Descarga: http://am05.mirror.alawar.com/ HotelMogul Es_11484.exe
Una vez instalado el juego, nos encontramos que tiene 2 ejecutables. El primero llamado: HM, y el segundo HM.wrp. Ya comienza a oler raro. Si ejecutamos el primero aparece una NAG, indicando que queremos hacer, jugar 30 minutos o pagar. Y si ejecutamos el HM.wrp no hace nada. Parece que se cierra.
Peid nos indica:
HM.wrp = Nothing Found
HM = ASProtect 1.2x - 1.3x [Registered] -> Alexey Solodovnikov [Overlay]
Como el que ofrece Resistencia (y es el único que hace algo), es el HM, será el que procese por el OllyDbg. Indicar que el otro fichero visto desde olly, tiene un RET, nada más empezar. Salta a Kernerl32.ExitThread y finaliza la aplicación.
Visto lo visto, uno ya empieza a pensar que uno actuará de Padre y llamara al hijo modificándole en memoria y posteriormente ejecutar. O bien, edita el ejecutable y lo deja operable de nuevo, monitorizando y posteriormente restaurando (con el peligro que esto podría acarrear), o por último que copie el fichero en “tmp”, por suponer algo, y de nuevo, modificar y ejecutar. ¿Resultado?
CreateProcess ¡! Como en cualquiera de los casos, me huele a una llamada a esta api, probaré a monitorizarla. Esto lo intuyes por viejo. Así que: BP CreateProcessA. No sin antes, proceder a quitar la protección de ASP. No lo incluiré en el tutorial por que ya existen muchos, si bien utilicé un programa; Por comodidad.
Probamos a ejecutar, pasamos todos los errores, y damos a probar el juego. ¡Tachan! ¡Falla! :D El juego arranca sin mayor problema (falla para nosotros, no el programa). Cambio de idea,
BP CreateProcessW. Y repetimos el proceso. Esta vez, sí, ha parado.
En EDI, vemos la ruta del programa, justo el ejecutable que no hacia nada… Y también lo apreciamos en los parámetros de llamada del proceso. Por lo que ejecutamos hasta el RET, y F8, para ver que podemos ver por la que creo será la zona caliente…
Contenido de EDI
Llamada y parametros
¡Importante el proceso lo ejecuta SUSPENDIDO!
Salimos en 1004CE45, si vamos traceando un poco, vemos abajo en la línea 1049F3E, un DebugActiveProcess, esto, ya me hace sospechar de que el aplicativo, funciona a modo Debugger. Attachea, modifica, y libera. Pero vamos a comprobarlo.
Pues no, hay un salto que nos lleva hasta 10049F8B, un poco más abajo vemos VirtualProtectEx, es decir va a modificar los permisos de la dirección: 0056E17, curiosamente el EP del proceso que falla, justo donde se encuentra el RET, y modifica 2 bytes. Modificará o al menos permitirá modificar el C3 90, que existe. Le otorga permisos de Ejecución / Lectura / Escritura.
Parametros de VirtualProtectEx
Traceando un poco más, nos lleva hasta un WriteProcessMemory, esta api, es la encargada de modificar los valores en MOMORIA del proceso. De nuevo la dirección a modificar es el EP del otro proceso. 2 bytes el tamaño. Si miramos que hay en el Buffer: E8 14.
Valores en buffer
Ya tengo claro que modificando en el otro ejecutable estos 2 valores, pasará a funcionar, pero para muestra siempre es mejor un botón.
La siguiente api que utiliza, no la conocía, FlushInstructionCache. Si la CPU no reconociese las modificaciones, ejecutaría lo que estaba anteriormente, con esto, indicando el EP y los valores modificados (2 bytes). Lo refresca. Y siempre ejecutará lo nuevo.
Por último en 1004A034 se utiliza ResumeThread, y ya tenemos nuestro juego funcionando. Para finalizar, si se parchea el EP de HM.wrp con los valores E8 14. Nos arrancará el juego siempre, sin necesidad de de utilizar el Loader.
Notas adicionales (Nada que ver con cracking).
Bueno, me he liado un poco al ver DebugActiveProcess, al final, no se utilizaba en la aplicación, esto me hace pensar que esta compañía, tiene una aplicación de botón gordo. Es decir, usa la misma para todos los juegos, y le mete una protección u otra de forma genérica. Si la primera falla, mete la segunda, y así sucesivamente.

8/4/11

Amante de los animales



Con el título del post, quizá alguno se pregunte, ¿Qué chorrada tendrá lista esta vez?, y sí, otro post que no tiene nada que ver con la línea de los anteriores. Aquí cada post es de su padre y de su madre. Al grano.

No hace muchos días, en un blog comentaban, lo maravilloso que sería darle una sorpresa a tú hijo, haciendole ver que facebook, ahora eras amigo del inocente Raton Pérez, y sí, sin duda el simpatico animal, es inocente, pero ¿quien está detrás? Hay que pensar, que al mantener esta amistad, podrías estar teniendo sin saberlo, "amistades peligrosas", ya que pasas a compatir todo tu muro, perfil, etc, en público para esta persona. Algunos dirán que podrías configurar el perfil para evitar esta "fuga" de datos, y es correcto, en facebook sí. ¿y en tuenti?

Pues en tuenti, tambien tenemos fauna y flora, ratones amistosos y reyes magos fántasticos, el problema es que la ingenieria social, es poco funcional en personas de "tuenti" años. Por lo que el mensaje debe ser mas original y adaptado a esta franja de edad... ¿Qué mejor que un amante de los animales? Me permitiré el chiste de ¿Qué tipo de amante? Nada mas ver la cuenta, dije, mira, una protectora, tendrá un bonito perfil público, en el que compartir datos e información. Cual es mi sorpresa cuando dicho perfil es privado. Bueno, podrían sólo poner eventos. Así, no es necesario compartir el perfíl.

Será cosa de la informática que me mantiene alerta, será que simplemente soy un paranoico y veo cosas raras en todas partes, o simplemente tengo razón, y detrás de este amante de los animales tenemos un caso de un amigo "voyeur", que se distrae viendo las fotos de gente que no conoce, de gente que no le importa, y de gente que sin lugar a duda, es amante de los animales.

Y casi como reza el anuncio si teneis alguna duda, dejad un comentario.

28/3/11

Sorteando maleficios

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

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.