Mensajes

No estas inicializando suma, siempre inicializa las variables. Ej.:

Código (c) [Seleccionar] Expandir

int suma = 0;

Gracias por las respuestas Estaba yo haciendome una librería, y no sabía si dejar el tema de llamadas con registros, o cambiarlo a la pila. Pero la verdad, los registros me parecen más sencillos jaja

Si, pero ojo que los registros son finitos y si las funciones tienen muchos parametros tenes que recurrir a la pila igual; sino usa punteros a estructuras para pasar los parametros ... que normalmente terminan siendo variables locales en la pila tambien 

En x86 stdcall usa sola la pila pero en x64 se usan primero los registros.

http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention

Para depurar la pila sin duda, cuando se usan registros cada funcion los va sobreescribiendo y analizar un dump es doloroso.

Lo normal hoy en dia es usar registros, es la convencion de llamada stdcall en x64 y (el Kernel) Linux tambien usa registros. Igual son limitados, al final terminas usando la pila ...

Eso depende de la convencion de llamada, la de C limpia la pila el llamador despues de llamar, en stdcall el llamado pero eso se hace justo al retornar con retn (no es que se quiten los valores, simplemente se ajusta el puntero ESP). Ambas casos los podes analizar creando un sencillo programa en C que llame a la API de Windows y a printf por ejemplo.

Que error mas tonto jeje.  

Te funciono el CreateRemoteThread()?Me tira error 5 , osea AccesoDenegado. Puede ser que sea por que lo estoy corriendo en WIN7 x64 .Lei que algunos tienen el mismo problema , pero en win8 corre bien.

Edito:
En win7 x64 me tira acceso denegado.
En win xp sp3 x86 funciona bien.
En win xp sp 2 x86 funciona bien.
En win xp x86 funciona bien.

Gracias!

PD:Conoces algun buen libro orientado a la API de windows? De teoria de windows toy leyendo Windows Internals 6.Aunque tiene practica , no es sobre la api de windows.

PD2:Perdon por las molestias , soy mas de unix , unix like. Poseo poco conocimiento en windows , pero estoy tratando de aprender.

Si, aunque yo lo probe con el notepad, tal vez sea cosa de diferentes sesiones (el proceso puede ser un servicio) ... o tal vez estas tratando de trabajar con un proceso de 64 bits y tu programa es de 32 bits ... si es asi proba generando un ejecutable de 64 bits.

Solo conozco el "Windows via C/C++" de Jeffrey Richter.

[!=0]

if(WriteProcessMemory(procesoHandle,MyFuncAddress,(void*)FuncionInyectar,size_FuncionInyectar,NULL)!=0)

Esta mal la condicion, cuando retorna 0 es que fallo.

PD. Ya vi el mensaje (aunque use notepad.exe), cambiando las dos comprobaciones de WriteProcessMemory.

[Note]

No lo se, puede ser algo historico ... estas funciones vienen de 16 bits y es posible que las estructuras tengan campos heredados obsoletos como:

Note  The module identifier, which is specified in the th32ModuleID member of MODULEENTRY32, only has meaning in 16-bit Windows.

Si, 5 es ACCESS_DENIED, sin el codigo no se puede mas que adivinar.

Si claro, antes del while, pero no antes de asignar el campo dwSize. Ya te dije la razon: la funcion de la API no escribe nada en ese campo; por lo menos es asi cuando usas TH32CS_SNAPMODULE. Antes tenias un valor indefinido, ahora esta inicializado a 0 y la API NO lo cambia nunca.

Poniendo antes del while:

Código (c) [Seleccionar] Expandir

ZeroMemory(&moduleEntry, sizeof(MODULEENTRY32));

No parece que la API rellene ese campo, en principio no lo necesitas y tal vez lo hace cuando enumeres los modulos de todos los procesos y no de uno en particular.

Ni la menor idea, solo uso Visual Studio realmente, yo cree un proyecto y obtuve tu error inmediatamente.

Despues hice:
Project>>Add File>>libroCalificaciones.cpp

Y ya genero bien el ejecutable.