Sigo depurando esto y por comprobar he mirado a ver si el ID del handle del primer paŕametro de HttpSendRequest es el mismo que alguno de los que me devuelven InternetOpen, InternetConnect, HttpOpenRequest... y nada son consecutivos a éste, así que dudo mucho que se sobreescriban HANDLEs anteriores

Saludos again, estoy haciendo un programita que hookea ciertas APIs del sistema (HttpSendRequestX por ejemplo  ). Dentro del código mio que se ejecuta antes del original realizo varias operaciones. Una por ejemplo es loguear ciertos parámetros recibidos por esta API.

El logueo no me funcionaba como esperaba, ya que, por ejemplo, al hookear esta función en InternetExplorer, se logueaba sin ningún problema, pero IE no podía navegar, ya que me dice "IE no puede encontrar la página web". También al enviar los datos a través de red, se envían correctamente pero IE "se peirde".

Lo primero que pensé es que algo raro hacía en la función inyectada (como dejar la pila sucia, pero mirando con Olly, ésta se queda limpia). El fallo es más desconcertante aún cuando le he puesto que el logueo se haga solamente para ciertos dominios. Para los dominios en los que se loguean los parámetros de la API, ésta no funciona, pero en el resto la navegación por los otros dominios es normal, a pesar de ejecutarse mi código inyectado igualmente.

Comentanto y descomentando líneas de código me he dado cuenta que cuando se utiliza algún HANDLE es cuando IE no puede navegar. El logueo lo hago de dos maneras. Priemro probé a escribir en un fichero, y cuando en la función que loguea descomentaba la línea en la que abría el manejador, IE no funcionaba. Lo mismo me pasa cuando intento enviar los datos por la red, cuando descomento las líneas que me devuelven un HINTERNET, IE no puede seguir navegando. En ningún momento IE ha tenido ningún fallo grave ni nada por el estilo, solamente me dice que no puede mostrar la página web 

Parece como que al usar yo manejadores estoy tocando donde no debo... pero es que no estoy haciendo nada raro amos. Aquí podéis ver el código de logueo a través de internet: https://gist.github.com/anonymous/d0ace002ff84156870ab

No sé por donde tirar 

Saludos y gracias!

Gracias por las respuestas! La cosa andaba por donde apuntasteis, por la convención de las llamadas utilizada. He compilado la DLL con el cambio que me sugirió IEAX añadiendo __stdcall en las funciones, ya que no era suficiente añadir el __stdcall en el typedef, y va a las mil maravillas. 

Gracias también por el enlace de 85. De depurar y depurar programas había visto que el manejo de la pila era diferente de un programa a otro, pero desconocía los diferentes estándares, así que no sabía la razón de poner el "__stdcall" en el typedef.

Sigo analizando qué es lo que ocurre y he visto que la función MessageboxA, cuando la hookeo, aunque no me da ningún problema, en verdad se queda la pila sucia, y cada vez con más y más basura.

Os dejo aquí el código de las funciones inyectadas: https://gist.github.com/anonymous/63c842a743a8ea49fea9

¿Puede ser que el fallo esté ne los typedef? Me da que por algún lado el código no sabe limpiar la pila porque no "sepa" la cantidad de parámetros que le llegó.

Buenas, estoy haciendo un programa en C++ que me hookea varias funciones del sistema para monitorizar las acciones del usuario. Empecé hookeando el típico MessageBox y va sin ningún problema. El problema viene ahora cuando aspiro a algo más, como por ejemplo InternetConnect. Inyecto la DLL en el proceso sin ningún problema y se parchean bien las APIs de mi interés. La ejecución dentro de mi función no da fallos, pero el problema viene al hacer el 'retn'.

Con el Olly he visto que la pila queda niveles diferentes (que no se limpia bien al salir de la función inyectada) cuando vuelve de la llamada InternetConnectA sin hookear y hookeada. Me da la sensación de que la culpa es de mi compilador, ya que uso el g++ de MinGW. He probado el compilador de Borland y me da fallos que por lo visto se pueden arreglar si instalo la interfaz gráfica. El hecho es que yo soy más de editor de texto y terminal para programar y compilar. No sé si seguir buscando otro compilador más Microsoft y menos "linuxero" como el de MinGW o si es un fallo mio.

Básicamente mi manera de hookear es la siguiente:
1. Aprovechando el hotpatching de windows y hago un salto a los 5 bytes anteriores, donde se encuentra el salto a mi código (compilado con g++)
2. Desde mi código guardo en un fichero info de la conexión obtenida a través de los parámetros. Vamos, que no modifico los parámetros para nada. (El fallo no está en este código del fichero, probé a comentarlo y seguía dando el fallo).
3. Llamo a la función original.  (Esta dirección la obtendo sumando 2 a la dirección que me devuelve GetProcAddress, así evito el salto a mi código.
4. Devuelvo el valor que me ha dado la función original.

Mi sensación es que al mezclar código de windows con código compilado con g++ es cuando empiezan a ocurrir las cosas extrañas. ¿Puede ser esa la razón? ¿Qué usáis vosotros para crear vuestras DLL para inyectarlas?

Un saludo y gracias

Eso era! WAF, muchas gracias, ahora querría saber si ese es el comportamiento típico de un WAF o puedo atajar el problema de otra manera, o es que estoy haciendo algo mal (aunque otras veces me ha funcionado así  )

Estoy liado con una inyección SQL, pero ahora mismo estoy atrancado.
Resulta que he encontrado un parámetro vulnerable, ya he chequeado que no se hace ningún tipo de filtrado y el número de columnas que necesita el select, pero a la hora de realizar el UNION SELECT... es donde me quedo atrancado porque me da el error este:


No creo que sea un error de MySQL, ya que he  probado a hacer consultas erróneas y me salta el error de MySQL con su path y todo 
También he pensado en que puede ser que tengan un sistema que detecte las peticiones sospechosas (no me acuerdo su nombre  ). He probado a ver si es que detectaba la cadena SELECT, pero si corto ahí la consulta, es decir:

http://www.web.com/pagina.php?parametro=346+and+1=0+union+select--

lo que obtengo es un error de MySQL. También he probado utilizando distinto número de columnas en el select, por si detectaba que lo que devolvia la consulta no era del tipo que esperaba, con lo que una consulta errónea debería haberme dado un error MySQL, pero ha vuelto a darme el 101.

¿Que es lo que puede ser?

Finalmente dejaré mi WXP y seguiré los consejos de WHK de .net 4.0 mas windows installer para ahorrar basura

Gracias por las respuestas

hmmmm no sabía que esas versiones fueran inestables, eso me viene muy bien saberlo 

Por otro lado, lo que has comentado WHK de que para Olly, RDG y compañía que mejor utilice WXP, ¿Porqué? ¿Están mejor preparados para las APIs de este sistema? Este tema sí me interesa bastante

Buenas, yo suelo trabajar en Linux, pero de vez en cuando necesito Windows puntualmente, por lo que uso una máquina vistual con WXP. Quiero poner un W7 ligerito, pero estoy entre el Starter y el Home Basic.

He estado mirando diferencias:

http://reviews.cnet.com/8301-31012_7-10379487-10355804.html

Las principales características que diferencian al home basic del starter, que si multimedia, multitouch, juegos... y hasta el cambio de wallapper xD no las voy a necesitar, pero no sé si el starter es tan limitado que se me va a quedar corto. Principalmente lo que usaré será algún IDE ligerito para programar y algunas herramientas del estilo OllyDgb, wireshark, y cía.

¿al final la restricción de 3 apps en el starter la quitaron o fue un bulo?

Otra preguntilla, si finalmente me decanto por el home, como la máquina anfitrión corre a 64 bits, ¿merece la pena instalar un SO de 64 bits en la máquina virtual?