Bueno gente, estoy un poco perdido.
Windows Live Messenger (2011 15.4.x ) me esta dando dolores de cabeza.
Hasta ahora, lo que se es lo siguiente:
a) El menu NO es HMENU, es un ToolbarWindow32. Esto lo descubri usando Spy++, que me lo recomendaron en un canal de IRC, pero no se como seguir. O sea, veo el Handle, pero me es poco util.
b) Es muy probable que tenga que injectar una DLL, el tema es como trabajo con ese objeto una vez que este dentro del proceso?

En si, tengo un hecho un injector de DLL que hice siguiendo un tutorial, pero la verdad que hay muchas cosas que no me quedaron muy claras que digamos.
Por ejemplo, esto:

O sea, veamos, la idea es en el proceso_a_injectar tengo el handle del proceso,  el primer NULL es para que agarre los parametros de seguridad por default, el cero es para que use el tamaño de pila estandar para ese hilo, direccion_de_loadlibrary es en realidad un puntero a la funcion definida que en este caso es LoadLibrary desde kernel32.dll, aca empieza mi problema, el proximo es el puntero a la direccion de memoria que reserve en el proceso remoto, pero para que? acaso mi DLL despues va a ir a terminar en esa direccion? si es asi, el offset puesto en cero que le sigue esta bien porque no deberia correrla y dejar que lo ajuste a la pagina el sistema, y el ultimo NULL porque no me interesa saber cuantos bytes copio antes de fallar, sino que falle directamente.

O, existen todos estos:
int isalnum(int c);
int isalpha(int c);
int isascii(int c);
int isblank(int c);
int isdigit(int c);
int isxdigit(int c);

Que los podes encontrar en ctype.h

Dejo esos, y si lo que queres es validar una cadena:

C no inicializa las variables por defecto, lo que tomen por valor inicial es lo que hubiera en ésa zona de memoria anteriormente, asique es correcto inicializar las variables.
Dadas las cantidades de memoria que tienen los equipos hoy en dia, es muy probable que de antemano no hubiere nada escrito por ahi, pero no está de más asegurarse.

Me quedé con lo de un post anterior.
Deprecated significa DECREPITO, no banneado.
Esas funciones están decrepitas porque otra ya indexa sus funcionalidades y ha sido favorecida por algún motivo, y como tal, el uso de la nueva y no de la decrepita esta favorecida.
Y las otras que tienen poison como pragma comment van a hacer que si le pasamos al compilador (bueno, a GCC voy a dar el ejemplo) -Wall o -pedantic nos advierta o nos tire error.
Lo cierto es que todavia son usables, estan bajo una capa de transición y como venimos haciendo eso con aplicaciones de 16 bits hasta Vista, podemos esperar que duren bastante mas ahi estando.

Bueno, muchachos.
Primero que nada lo que ya implementé:
1) Cargar el binario en memoria, cambiarlo según un algoritmo básico (funciona bien, de probarlo con texto la función es biyectiva, cifra y devuelve al valor original)
2) Una vez en memoria y cifrado, moverlo a un archivo copiando byte-a-byte.

Obviamente, hasta acá y hasta ahora es inutil, porque ése código que está ofuscado no parece un PE Executable ante los ojos de Windows.

Lo que me falta averiguar es como cambio ése sector de memoria ofuscado que le estoy enchantando al stub. O sea, se que tengo que volver a usar la misma función que usé para desencriptarlo, pero ¿qué hago? ¿cargo el contenido ofuscado en memoria, lo desofusco, y cambio el CS:IP a la dirección de memoria del array de unsigned chars donde tengo cargado el codigo revertido? ¿Como puedo hacer para marcar esa zona de memoria como de código en vez de datos?

La pregunta es, ¿sirve de algo la idea?
En resumidas cuentas lo que terminaría haciendo es:
1) El crypter va a pasar el archivo por la funcion que cifra y lo va a agregar al final del stub.
2) Poner en el stub la funcion que descifra, abrir el mismo binario que está ejecutandose con modo lectura, dado el tamaño del stub original, comenzar en el siguiente byte a leer el archivo y cargarlo en memoria.
3) La zona de memoria donde lo cargaria seria un array de unsigned char (miden un byte, y no me va a poder joder el tema de los signos), éste array de char lo paso por la funcion de descifrado, cambiando los valores de nuevo a los originales.
3.5) ¿Marcar la pagina ésa de memoria como ejecutable? ¿Como lo haría?
4) asm("mov ip,&array[0]"); -> como haria para pasarle en concreto el valor de la dirección del primer elemento del array?

He estado recorriendo los ejemplos que hay en el sitio, pero no me convencieron demasiado como para copiarlos porque en particular lo estoy haciendo para aprender, y preferi empezarlo de abajo. Del mismo modo estuve leyendo apuntes externos varios, la mayoria usan Delphi (no es que sea tan dificil portarlo, al fin y al cabo es siempre la misma API de Windows, pero igual medio me molestó) o Visual Basic 6.0.
Tambien estuve recorriendo hackforums, y viendo algunos que daban escritos en Visual Basic .NET y C#, despues me dijeron que ésos son los primeros en caer victimas de piratillas porque al usar el bytecode (MSIL) es como JAVA, y siempre y cuando no usen NGEN para generar un binario nativo, el código intermedio del MSIL permite obtener el codigo fuente original. ¿Alguien tiene algo asi como CAVAJ pero para los binarios del framework .Net o me puede dar una referencia?
Saludos, desde ya muchas gracias.

EI: juntando mensajes.

Bueno, nuevamente acá yo.
Ya logré que me crypter agregue el otro binario encodificado dentro del stub, que lo restaure a su antigua gloria, pero todavia no se como hacer para empezar a ejecutar esas instrucciones.
Eso si, pasarlo por novirusthanks.org por ahora lo muestra como limpio, cosa que tal vez no dure cuando implemente lo otro..
Alguna idea en lo que me falta