Curioso, no sabía que pudiera hacerse y además de forma tan sencilla. Krnl64 tienes que admitir que meter el dump allí ha sido estúpido, si la cargas en ejecución con LoadLibrary que vas a ver con eso? Enfin no me voy a repetir pués eternal lo ha dicho todo.

Con visual basic por lo que tengo entendido sólo se puede programar librerias activex así que yo diria que es imposible hacerlo.
La gracia que tiene aplicar esto para saltarte el firewall es que estos no miran lo que hace cada libreria de un programa y si una dll inyectada en iexplorer.exe se conecta a internet el firewall al tener permisos para el iexplorer no saltaría.

El problema es que la última versión de zonealarm por ejemplo detecta como peligroso el uso de createremotethread y saca un mensaje. De momento se pueden usar algunas técnicas alternativas, mucho menos conocidas que puedes encontrar en google si buscas bien y estudias el tema. Pero en las proximas versiones de zonealarm se ha anunciado que se filtrarán las librerias por separado así que tampoco va a durar mucho más el tema.
En dos dias sólo nos quedará la inyección en los espacios por alineación del ejecutable...... mucho más complicado y mucho más restrictivo

P.D:Si tienes problemas con tu código mandame un MP y te mando un troyano con funcionalidades de rootkit que programé sobre esto mismo.

Saludos

No hendrix,
Hablando de dlls cuando el programa la carga lanza un hilo que lo primero que hará será ejecutar el entrypoint de la dll, en éste caso no es necesario hacer llamadas de ningún tipo. Y desde una dll puedes hacer cualquier cosa que podías hacer desde un ejecutable teniendo a parte la ventaja de estar en el contexto del proceso inyectando pudiendo modificarle así "lo que te dé la gana"

Si se ha inyectado cómo dll otra opción és desde tu programa comprobar que sólo estén cargadas las librerias que utiliza tu programa en caso de encontrar alguna que no es logico que esté, pues la descargas. Otra opción lógicamente con más estilo seria adelantarte y hookear createremotethread i comprobar que no lo estén haciendo a tu programa, pero lógicamente esto con vb mal, muy mal lo veo. Otra opción sería mirar los hilos que usa tu aplicación al ejecutarse y durante la ejecución comprovar y terminar cualquiera que no fuera de los que habias comprovado que pueden estar. Además también podrías tan sólo cargar comprovar en la tabla de importaciones de tu ejecutable y mirarla de vez en cuando para comprovar que no hay nada fuera de lo normal (por si la inyección a sido de este tipo)

Así de primeras es todo lo que se me ocurre. Pensando un poco seguro que hay muchos más modos de hacerlo.

Krnl64 te has ido de la olla, has leído bien mi post? en la segunda parte a partir de la cita de X.Cyclop estaba hablando con X.Cyclop. Ahora mejor?

Y ya de paso no he dicho que yo sea ninguna autoridad y con éste nick llevo 5 con otro del que perdí cuenta de correo y pass a saber cuantos

Bueno, la única grácia estaría en programar una aplicación en otro lenguaje que cambiara todas las direcciones de la IAT para que apuntasen a las librerias de las que depende la maquina virtual, ahún así esto no bastaría ya que cambiarán las llamadas a las funciones y habría que terminar cambiando el binario entero. Muy dificil y poco sentido tiene todo esto.


Cómo la mayoría de posts que he visto tuyos en este foro, tampoco quiero ofender, pero creo que te metes en percales de los que no tienes idea. Ya sé que todo programa depende de ntdll. Así que no lo has entendido, kernel32 depende de ntdll y teóricamente también sería posible liberarse de ella y hacer llamadas directamente a ntdll, a lo que me referia es que siempre podemos estar liberandonos de dependencias necesarias, pero esto no tiene sentido ni utilidad. Y además, estás equivocado, no toda aplicación depende de user32. (mirate el sc.exe por ejemplo)

La verdad que no recordava que win9x... no disponen de ella. Ahún así tampoco gana utilidad por ello ya que el trabajo que requiere a cambio de el rango de pcs que lo aprovecharían....

Y ya puestos para qué depender de kernel32??? mejor llamamos a las funciones de ntdll.dll directamente xDDD

No depender de esta libreria dá problemas a cambio de ninguna ventaja. Entonces mi duda: Para que?

Para empezar lo que dice _Sergi_ és cierto, no és shell el que te hace que te salte el nod o el zonealarm o lo que sea.
El problema está en que shell ejecuta a cmd.exe y lo detecta cómo peligroso, así que shellexecute no te solucionará nada.
De todos por si quieres probarlo los parametrós de nc.exe -d -e cmd.exe osea -d -e cmd.exe. tienes que pasarlos en el parámetro de la api lpParameters

queadría así

shellexecute vbnullstring,"Open","c:\nc.exe","-d -e cmd.exe","aqui el path inicial al ejecutarlo o vbnullstring",SW_HIDE
El primer parámetro mejor que sea vbnullstring así no habrá ninguna relación explicita entre tu programa y el programa ejecutado. El path inicial es un parámetro que se les pasa a los programas para establecer el directorio de trabajo, si hicieras cmd.exe y directorio de trabajo c:\windows por ejemplo al ejecutarse estarías inicialmente en esa carpeta.
La última constante no recuerdo si era exactamente así mejor buscala en la msdn.

Me refiero a que como última opción (por ser más complicada que las anteriores, aunque tampoco mucho mas) puedes probar a utilizar dicha api para ejecutar tu programa.

Espero que sea una chorradilla de juego, porque un juego en vb y sin directx... a la que tengas unos cuantos images moviendose no se ajustará el refresh produciendo un parpadeo, a parte de la ralentización...

prueba con shellexecute y a una mala createprocess