Mensajes

El problema es el alineamiento de la estructura, todo depende del compilador que utilices, y de los parametros que son pasados al compilador, generalmente los miembros de una estructura se alinean al tamaño de un DWORD, debido a que la accesos a posiciones de memoria por la CPU son más rapido si estan alineados , por eso mismo debes verificarlo, que compilador estas usando?

en VC++ se podes hechar una miraba a /zp
o usar

#pragma pack(push)
#pragma pack(alineamiento)

// Tu estructura

#pragma pack(pop)

[SandBoxie]

Tengo un programa que sólo te deja ejecutarse una vez al mismo tiempo.

Para ello, al abrirse comprueba que no haya otro corriendo que tenga el mismo nombre. Eso es lo único que hace. Lo sé porque estuve haciendo pruebas, y si renombro y ejecuto un exe cualquiera con el nombre del programa y después intento abrir el exe del programa que hablo, detectará que ya hay uno abierto y se cerrará.
Si le cambiamos el nombre original tampoco se abrirá.

He probado a correrlo desde SandBoxie sin resultados. También probé a ejecutarlo como otro usuario y nada, tampoco le puedo engañar.

Lo siguiente que se me ocurre es utilizar ingeniería inversa, aunque he de admitir que estoy un poco verde en el tema.

¿Alguna idea, chicos?
Muchas gracias.

DoEvents!

Si el programa se basa en ese tipo de "mutex" ( comprobar si hay ya un proceso con el mismo nombre ) entonces porque no programas un dll o injectale codigo hookeando la API encargado de eso y eliminando el buffer, Crea el proceso desde tu aplicacion y al momento de soltar el hilo principal injectale la dll y listo.

@||MadAntrax||: deverdad piensas que son protecciones complejas... simplementas copias unos bytes a un buffer y lo llamas desde un hilo creado, y honestamente lo peor del codigo en ensamblador fue esto:

call IsDebuggerPresent
cmp eax,1
jnz 0x******

Por lo visto los plugins de Olly también lo protegen de los threads que generas a partir de la aplicación principal  Ya que la llamada a la API IsDebuggerPresent no se genera nunca desde el propio ejecutable. Seguiré investigando

PD. El source de thread en ASM no es mio

Quieres decir no se llama desde el hilo principal, los hilos siempre se crean en el espacio de memoria del proceso/ejecutable.

Insisto creo que este seria mejor:

Superjuackerdeanonimouse.foro 

40

superjuacker.foro
wintxjuacker.foro
anonimousejuackers.foro

[accesible]

¿¿??

SetWindowText() también requiere el handle (de cualquier ventana accesible).

Dulces Lunes.

Bien entonces no siempre es bueno solo usar SendMessage no crees?
En cuanto a SetWindowtext La verdad que veo una función inútil, lo único que comprueba si es una handle valido y es perteneciente
al proceso del llamador de lo contrario no lo envía. pero si insistes con SetWindowtext porque crees que es mejor SetWindowText para cambiar el
texto de un Control o ventana hija ( como limitación ) en lugar de SendMessage con WM_SETTEXT?

Al final esta API llama a sendmessage()

Seguro, eso dije.

pero no te "enredas" con los mensajes es un poco mas simple.

Enredarse al escribir esto:

SendMessageW(Hwnd,WM_SETTEXT,0,lpStr);

?

P.D.: Cuando se manda el mensaje con SendMessage() me PARECE que se tiene que repintar el DC...

El texto no es una propiedad grafica nativa , no es necesario actualizar el area del cliente, no encontré algun texto que dijera incluso en la documentación oficial que era necesario actualizar el cliente. incluso se puede comprobar simplemente usando SendMessage + WM_SETTEXT .
de todas maneras si fuera necesario repintar es lo mismo que decir que usando SetWindowText tambien se necesita hacerlo.

SendMessage tiene una infinidad de funciones (Te podría "sustituir" MoveWindow(), ShowWindow() emular clicks, pulsaciones, etc ya que se especia-lisa en mandar mensajes).

SetWindowText para cambiar texto.

Dulces Lunas!¡.

SendMessage no puede "sustituir" como dices, si se utiliza SendMessage se estara saltando Mensajes de proceso de Windows tales como actualización de tamaño de
objetos de Ventanas, actualización de la region del cliente, mensajes que son usados por aplicaciones ( incluso por otros procesos ). por ejemplo
WM_PAINT para redibujar el area que ha sido cubierta por otra ventana/control de otros proceso. Crees que Microsoft creo tales funciones para nada? 
Así que porque implementar un ShowWindow o MoveWindow y hacer todo el trabajo manualmente?

Además, no hay razon de usar SetWindowText debido a que esta funcion termina usando los mensajes de windows. SendMessage es mejor
debido a que no solo puede cambiar el texto ( en este caso ) de un control del llamador sino también de otra aplicación/proceso.
Aprender muy bien a usar las funciones que ofrece Windows.

MoveWindow para mover
ShowWindow para mostrar/ocultar
SendMessage para cambiar texto

solamente necesitas el handle al control

Depura tu programa, no somos adivinos.