Hola, queria saber si es posible evitar las inyecciones de archivos DLL y EXE en tal proceso, recorri el foro en busca de informacion pero no se habla mucho de como bloquear las inyecciones en Visual Basic.
Yo ya he probado de varias formas pero siempre logran inyectar cosas raras en mi programa :-\
asi que nose, busco opiniones o ideas para poder evitarlas. ;)
Saludos desde tucuman.
a no ser que enganches las apis que se usan... no veo otra forma
Sips....creo que si no hookeas las apis que usan para inyectarse creo que no lo vas a poder parar... :-\ :-\ :-\
Salu2
si puedes pararlo, depura tu propio proceso. te haces un "lanzador" que depure el ejecutable y no podran injectarle.
Cita de: Cara_Webo en 30 Mayo 2006, 15:39 PM
si puedes pararlo, depura tu propio proceso. te haces un "lanzador" que depure el ejecutable y no podran injectarle.
Me puedes explicar como es eso? :-\
pues digamos que creas un pequeño programa que aparentemente no tenga nada que ver con el original, este creara el proceso de tu programa "original" y depsues con DebugActiveProcess lo depura. al estar en depuracion cuando quieran acceder a el les dira acceso denegado. de todos modos t lo pueden injectar en el que carga el programa.
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.
Aprovechando este hilo voy a pedir algo que tiene mas o menos relacion kon eso....
Lo que estoy intyentando hacer yo es el FWB (Firewall Bypass), es decir, introducir mi proceso en un proceso "seguro" para el Firewall y asi que ni se immute.....
Lo que no entiendo es que tengo que ahcer, si tiene que inyectar el kodigo en el .exe "seguro", no??? pero, que kodigo tengo que inyectar??? el que va a hacer la conexión por internet???o komo ago eso???
Salu2 & Thank's... ;) ;)
Cita de: _Hendrix_ en 12 Junio 2006, 20:58 PMLo que no entiendo es que tengo que ahcer, si tiene que inyectar el kodigo en el .exe "seguro", no??? pero, que kodigo tengo que inyectar??? el que va a hacer la conexión por internet???o komo hago eso???
Efectivamente lo que tenes que hacer es ejectura lo que quieras dentro de un proceso que el firewall considere como seguro, el explorer.exe por ejemplo, o que al preguntarle al usuario este le de paso.
Bien...leiendo este texto lo entendi....
http://foro.elhacker.net/index.php/topic,90669.0/prev_next,prev.html
Ahora solo me kedan algunas dudas....komo inyecto el kodigo de "escritura" (es decir, en este kaso el kodigo de eskritura seria el Codigo inyectado!!! del texto de slasher). Pues komo inecto esto???
Porke por ejemplo esto:
Shell "mspaint.exe"
No kreo que funcionase...o si????
Help me Please.... ;) ;)
Cita de: _Hendrix_ en 12 Junio 2006, 21:11 PMAhora solo me kedan algunas dudas....komo inyecto el kodigo de "escritura" (es decir, en este kaso el kodigo de eskritura seria el Codigo inyectado!!! del texto de slasher). Pues komo inecto esto???
En C se suele hacer una funcion que no llame a ninguna API directamente sino que reciba un puntero a una estructura con las direcciones que necesita ... tambien podrias intentar hacer una DLL, de esa manera con inyectar la DLL mediante LoadLibray (esto ya explicado por ahi varias veces: VirtuaAllocEx para poner el nombre + CreateRemoteThread sobre LoadLibraryA) no tendrias que preocuparte tanto del codigo inyectado que funcionaria directamente.
Pero desde una DLL podria hacer llamadas a internet sin ningun problema???? :-\ :-\ :-\
Salu2 y Gracias... ;) ;)
Cita de: _Hendrix_ en 12 Junio 2006, 21:28 PM
Pero desde una DLL podria hacer llamadas a internet sin ningun problema???? :-\ :-\ :-\
Por supuesto que si.
:o :o :o :o
La tendre que krear yo a la DLL, no????
Weno, lo de inyectar DLL ya lo se hacer....luego, kuando la aya inyectado tengo ek hacer lo que expliko Slasher pero redirigir la llamada de la funcion a la DLL mia????
Salu2
Cita de: _Hendrix_ en 12 Junio 2006, 21:53 PMLa tendre que krear yo a la DLL, no????
Si.
Cita de: _Hendrix_ en 12 Junio 2006, 21:53 PMWeno, lo de inyectar DLL ya lo se hacer....luego, kuando la aya inyectado tengo ek hacer lo que expliko Slasher pero redirigir la llamada de la funcion a la DLL mia????
Eh no se a que te referis pero generalmente en C se pone el codigo que queres en el entry point (punto de entrada, la funcion que es llamada por Windows con lo eventos de una DLL).
Me refiero a que supongo que inyectando la dll no bastara para ejekutar su kontenido sin provokar una llamada a la funcion que kontiene esa DLL...no????
Esa llamada se hace kon lo que expliko Slasher en el link que postee mas arriba????
Salu2
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"
a ver si alguien me resuelve una duda que tengo.
Si tú inyectas código en otro proceso, se ejecuta la función que inyectas, pero si inyectas una dll, se ejecuta toda la dll? es decir, a lo que me refiero, es que si yo quiero que el programa entero se ejecute en otro proceso, tengo que renombrarlo a .dll e inyectarlo?
En qué se diferencia el code injection, de la dll injection?
Cita de: Lympex en 13 Junio 2006, 13:55 PM
a ver si alguien me resuelve una duda que tengo.
Si tú inyectas código en otro proceso, se ejecuta la función que inyectas, pero si inyectas una dll, se ejecuta toda la dll? es decir, a lo que me refiero, es que si yo quiero que el programa entero se ejecute en otro proceso, tengo que renombrarlo a .dll e inyectarlo?
En qué se diferencia el code injection, de la dll injection?
Lo unico que se puede inyectar como tal es codigo, pero ese codigo puede CARGAR una DLL. Esa DLL ejecutara como ya se dijo su entry point.
Ahora me toka a mi preguntar... :P :P ;) ;)
Komo konsigo relacionar la inyeccion de la DLL kon que me konekte un peograma a internet???
Porke yo keria hacer esto apra que el FW ni se koske.... :-\ :-\
Si por ejemplo, hiciera un server de troyano, tendria que poner todo el codigo en la DLL y luego dentro de la DLL hacer lalmadas a sus propias opciones que estan dentro de esa DLL????
Salu2
Cita de: _Hendrix_ en 13 Junio 2006, 15:29 PMSi por ejemplo, hiciera un server de troyano, tendria que poner todo el codigo en la DLL y luego dentro de la DLL hacer lalmadas a sus propias opciones que estan dentro de esa DLL????
Todo lo que hagas en la DLL va a ser hecho desde el programa que la carga, da lo mismo que sea cargada mendiante una inyeccion de codigo o por un programa diseñado para cargarla.
Ok...pues a eso ya lo pille....Gracias... ;) ;) ;)
Otra duda (esta mas peñeñita...), si inyectara la DLL en un proceso del sistema (SYSTEM) tendria esos privilegios la DLL inyectada???
Porke a eso yo ya le veo muchas posibilidades....
Salu2
Cita de: _Hendrix_ en 13 Junio 2006, 16:02 PMOtra duda (esta mas peñeñita...), si inyectara la DLL en un proceso del sistema (SYSTEM) tendria esos privilegios la DLL inyectada???
Si.
Weno, tengo este kode para inyectar DLL:
Option Explicit
Public hModule As Long
Public hProcess As Long
Public dwSize As Long
Public dwPid As Long
Public dwBytesWritten As Long
Public dwTid As Long
Public SE As SECURITY_ATTRIBUTES
Public Const PAGE_READONLY As Long = &H2
Public Const PAGE_READWRITE As Long = &H4
Public Const PAGE_EXECUTE As Long = &H10
Public Const PAGE_EXECUTE_READ As Long = &H20
Public Const PAGE_EXECUTE_READWRITE As Long = &H40
Public Const MEM_RELEASE As Long = &H8000
Public Const MEM_COMMIT As Long = &H1000
Public Const MEM_RESERVE As Long = &H2000
Public Const MEM_RESET As Long = &H80000
Public Const STANDARD_RIGHTS_REQUIRED As Long = &HF0000
Public Const SYNCHRONIZE As Long = &H100000
Public Const PROCESS_ALL_ACCESS As Long = (STANDARD_RIGHTS_REQUIRED Or SYNCHRONIZE Or &HFFF)
Public Const INFINITE As Long = &HFFFFFF
Public Type SECURITY_ATTRIBUTES
nLength As Long
lpSecurityDescriptor As Long
bInheritHandle As Long
End Type
Private Declare Function VirtualAllocEx Lib "kernel32" (ByVal hProcess As Long, ByVal lpAddress As Long, ByVal dwSize As Long, ByVal flAllocationType As Long, ByVal flProtect As Long) As Long
Private Declare Function VirtualFreeEx Lib "kernel32" (ByVal hProcess As Long, lpAddress As Any, ByVal dwSize As Long, ByVal dwFreeType As Long) As Long
Public Declare Function CreateRemoteThread Lib "kernel32" (ByVal hProcess As Long, lpThreadAttributes As SECURITY_ATTRIBUTES, ByVal dwStackSize As Long, lpStartAddress As Long, lpParameter As Any, ByVal dwCreationFlags As Long, lpThreadId As Long) As Long
Public Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Public Declare Function GetWindowThreadProcessId Lib "user32" (ByVal hWnd As Long, lpdwProcessId As Long) As Long
Public Declare Function OpenProcess Lib "kernel32" (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As Long) As Long
Public Declare Function WriteProcessMemory Lib "kernel32" (ByVal hProcess As Long, lpBaseAddress As Any, lpBuffer As Any, ByVal nSize As Long, lpNumberOfBytesWritten As Long) As Long
Public Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As String) As Long
Public Declare Function GetProcAddress Lib "kernel32" (ByVal hModule As Long, ByVal lpProcName As String) As Long
Public Declare Function WaitForSingleObject Lib "kernel32" (ByVal hHandle As Long, ByVal dwMilliseconds As Long) As Long
Public Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long
Sub Main()
Inject App.Path & "\Ejemplo.dll", "Notepad"
End Sub
Public Function Inject(szDll As String, szTargetWindowClassName As String) As Boolean
Dim hWnd As Long
Dim k32LL As Long
Dim Thread As Long
SE.nLength = Len(SE)
SE.lpSecurityDescriptor = False
'Encontrar la ventana y abrir el proceso
hWnd = FindWindow(szTargetWindowClassName, vbNullString)
GetWindowThreadProcessId hWnd, dwPid
hProcess = OpenProcess(PROCESS_ALL_ACCESS, False, dwPid)
If hProcess = 0 Then GoTo Inject_Error
k32LL = GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA")
'Reservamos memoria
hModule = VirtualAllocEx(hProcess, 0, LenB(szDll), MEM_COMMIT, PAGE_READWRITE)
If hModule = 0 Then GoTo Inject_Error
WriteProcessMemory hProcess, ByVal hModule, ByVal szDll, LenB(szDll), dwBytesWritten
Thread = CreateRemoteThread(hProcess, SE, 0, ByVal k32LL, ByVal hModule, 0, dwTid)
If Thread = 0 Then GoTo Inject_Error
'Clean up a bit
WaitForSingleObject Thread, 100
VirtualFreeEx hProcess, hModule, 0&, MEM_RELEASE
CloseHandle Thread
Exit Function
Inject_Error:
Inject = False
MsgBox "error"
Exit Function
End Function
Es de cKrispin creo....Y lo que me pasa es que kon una DLL echa en VB ni me fucniona....Krispin explika que mejor ahcer las DLL en C...pero no hay ni una remota posibilidad de que en VB funcionen las DLL's???
Salu2
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
Aca se explica como hacer una DLL "verdadera" en VB:
http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html
Eternal Idol.
Estas equivocado. Aun siguiendo ese procedimiento, no se hacen Dll's verdaderas.
No exportan funciones.
La prueba la tienes en que Si desensamblas una DLL hecha con ese procedimiento, mantiene la referencia a MSVBVM.DLL.
Es decir, que sin ese archivo no funcionara la DLL creada.
Otra forma de ver que no es 1 DLL normal es con RunDll32
Si creamos 1 DLL en VB con una funcion por ejemplo, y ponemos Rundll32 midll.dll,nombrefuncion dara error de entrypoint. Una DLL de "verdad" ejecutaria la funcion
Lo mejor es hacerla en C. ( yo se muy poco)
ah, hablando de inyeccion creo que la DLL generada de esta forma no sirve para eso.
Salu2
Cita de: Krnl64 en 15 Junio 2006, 04:44 AMEstas equivocado. Aun siguiendo ese procedimiento, no se hacen Dll's verdaderas.
¿Seguro que estoy equivocado? Te doy la posibilidad de leer el articulo COMPLETO (son 3 paginas) de nuevo y retractarte ...
Veras Eternal Idol, he leido varios articulos de como crear DLL "verdaderas" en VB. Entre ellos ese.
Creo que no estoy equivovocado. Te pediria que lo comprobaras.
Yo he probado todas las maneras posibles, incluso creando 1 compilador nuevo que reemplazaba a C2.EXE
Pero no son DLL's verdaderas. Lo que no son, son DLL's ActiveX.
Mantienen el vinculo a la maquina virtual de VB.
mira, posteo 1 fragmento de una DLL que cree en VB:
00000000 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 MZ.......ÿÿ..
00000010 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ¸.......@.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 C0 00 00 00 ............À...
00000040 0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68 º.´.Í!¸LÍ!Th
00000050 69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F is program canno
00000060 74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20 t be run in DOS
00000070 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode....$.......
00000080 29 0B DC DB 6D 6A B2 88 6D 6A B2 88 6D 6A B2 88 ) ÜÛmj²ˆmj²ˆmj²ˆ
00000090 EE 76 BC 88 6C 6A B2 88 04 75 BB 88 6F 6A B2 88 îv¼ˆlj²ˆu»ˆoj²ˆ
000000A0 84 75 BF 88 6C 6A B2 88 85 75 B6 88 6C 6A B2 88 ,,u¿ˆlj²ˆ...u¶ˆlj²ˆ
000000B0 52 69 63 68 6D 6A B2 88 00 00 00 00 00 00 00 00 Richmj²ˆ........
000000C0 50 45 00 00 4C 01 04 00 31 37 7E 44 00 00 00 00 PE..L.17~D....
000000D0 00 00 00 00 E0 00 0E 21 0B 01 06 00 00 50 00 00 ....à.! ..P..
000000E0 00 30 00 00 00 00 00 00 90 13 00 00 00 10 00 00 .0...........
000000F0 00 60 00 00 00 00 00 11 00 10 00 00 00 10 00 00 .`...........
00000100 04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 .............
00000110 00 90 00 00 00 10 00 00 DC 0E 01 00 02 00 00 00 ......Ü....
00000120 00 00 10 00 00 10 00 00 00 00 10 00 00 10 00 00 ............
00000130 00 00 00 00 10 00 00 00 40 59 00 00 50 01 00 00 .......@Y..P..
00000140 C4 53 00 00 28 00 00 00 00 70 00 00 FC 08 00 00 ÄS..(....p..ü..
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160 00 80 00 00 80 05 00 00 00 00 00 00 00 00 00 00 .€..€..........
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000190 58 02 00 00 20 00 00 00 00 10 00 00 38 01 00 00 X.. ......8..
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001B0 00 00 00 00 00 00 00 00 2E 74 65 78 74 00 00 00 .........text...
000001C0 90 4A 00 00 00 10 00 00 00 50 00 00 00 10 00 00 J......P.....
000001D0 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 60 ............ ..`
000001E0 2E 64 61 74 61 00 00 00 F4 03 00 00 00 60 00 00 .data...ô...`..
000001F0 00 10 00 00 00 60 00 00 00 00 00 00 00 00 00 00 ....`..........
00000200 00 00 00 00 40 00 00 C0 2E 72 73 72 63 00 00 00 ....@..À.rsrc...
00000210 FC 08 00 00 00 70 00 00 00 10 00 00 00 70 00 00 ü...p......p..
00000220 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 40 ............@..@
00000230 2E 72 65 6C 6F 63 00 00 B8 05 00 00 00 80 00 00 .reloc..¸...€..
00000240 00 10 00 00 00 80 00 00 00 00 00 00 00 00 00 00 ....€..........
00000250 00 00 00 00 40 00 00 42 EC CF 3A 40 10 00 00 00 ....@..BìÏ:@...
---------------------------AKI
00000260 00 00 00 00 00 00 00 00 4D 53 56 42 56 4D 36 30 ........MSVBVM60
00000270 2E 44 4C 4C 00 00 00 00 00 00 00 00 00 00 00 00 .DLL............
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Si te interesa, detallo el proceso que segui y pongo el code.
Por ahora, sigo diciendo que no son DLL's "verdaderas" y que no valen para inyeccion.
Espero tu contestacion
Salu2
Bueno, este era el mensaje que no queria tener que publicar:
Cita de: Krnl64 en 15 Junio 2006, 04:44 AMEstas equivocado. Aun siguiendo ese procedimiento, no se hacen Dll's verdaderas.
La verdad es que NO, el que esta equivocado sos vos y en gran forma.
Cita de: Krnl64 en 15 Junio 2006, 04:44 AMNo exportan funciones.
Leyendo tremenda barbaridad me vienen a la mente dos preguntas: ¿Leiste el articulo? ¿Llevaste el procedimiento a la practica? ¿De verdad lo leiste? ¿Seguro que lo probaste?
Cita de: Krnl64 en 15 Junio 2006, 04:44 AMLa prueba la tienes en que Si desensamblas una DLL hecha con ese procedimiento, mantiene la referencia a MSVBVM.DLL.
Es decir, que sin ese archivo no funcionara la DLL creada.
Entonces mi DLL mono.dll escrita en assembly no es verdadera ya que depende de mi otra DLL perro.dll escrita en C ... ¿Acaso no eso es lo que estas diciendo? Mas aun, trazando un claro paralelismo entre la MSVBVMXX.dll y la MSVCRT.dll (Run Time de C) tenemos que una DLL escrita en C y con la Run Time enlazada dinamicamente TAMPOCO es una DLL "verdadera".
Bueno, la respuesta es que nuevamente estas equivocado, que siga dependiendo de MSVBVMXX.DLL no prueba absolutamente nada mas que eso. Por favor, antes de decir que alguien esta equivocado hay que sopesar si uno sabe de lo que esta hablando.
Y desensamblar la DLL para ver que tiene una dependencia es una incongruencia, en el codigo no vas a ver la dependencia ya que la misma es simplemente una llamada a una direccion alojada en una tabla. Para ver las dependencias se usan programas mucho mas simples que un desensamblador como el Dependency Walker.
Cita de: Krnl64 en 15 Junio 2006, 04:44 AMSi creamos 1 DLL en VB con una funcion por ejemplo, y ponemos Rundll32 midll.dll,nombrefuncion dara error de entrypoint. Una DLL de "verdad" ejecutaria la funcion
Vuelvo a la anterior: ¿De verdad leiste el articulo? En la segunda pagina se muestra como creando una DLL ActiveX da el error que comentas ya que ciertamente por defecto VB no permite exportar funciones pero en la tercera pagina explica como hacer que el enlazador exporte las funciones que queres mediante un par de metodos diferentes ...
Cita de: Krnl64 en 15 Junio 2006, 04:44 AMah, hablando de inyeccion creo que la DLL generada de esta forma no sirve para eso.
No hay que creer, sino probar y saber: estas equivocado (de nuevo).
Cita de: Krnl64 en 16 Junio 2006, 07:22 AMVeras Eternal Idol, he leido varios articulos de como crear DLL "verdaderas" en VB. Entre ellos ese.
No lo leiste bien entonces.
Cita de: Krnl64 en 16 Junio 2006, 07:22 AMCreo que no estoy equivovocado. Te pediria que lo comprobaras.
Estas equivocado en todo excepto en que la DLL sigue dependiendo de la maquina virtual de VB pero como ya dije antes eso no significa absolutamente nada.
Cita de: Krnl64 en 16 Junio 2006, 07:22 AMPero no son DLL's verdaderas. Lo que no son, son DLL's ActiveX.
Esto es erroneo, si leyeras atentamente el articulo (tal vez no entendes por el idioma) te darias cuenta de que explica justamente como no caer en este error.
Cita de: Krnl64 en 16 Junio 2006, 07:22 AMMantienen el vinculo a la maquina virtual de VB.
Si ... pero eso no implica nada.
Cita de: Krnl64 en 16 Junio 2006, 07:22 AMmira, posteo 1 fragmento de una DLL que cree en VB:
Lo mismo que antes, desensamblar o hacer un dump para ver las dependencias es ridiculo, incluso el mismo DUMPBIN te las muestra (DUMPBIN /imports).
Cita de: Krnl64 en 16 Junio 2006, 07:22 AMPor ahora, sigo diciendo que no son DLL's "verdaderas" y que no valen para inyeccion.
Cada uno puede decir lo que quiera por eso yo digo que no tenes ni idea de este tema.
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.
Llevais razon, Error gordo el mio.
Lo que pasa cuando llevas mucho tiempo sin dormir.
Bueno, gracias a vuestra explicacion me quedo claro el concepto.
Salu2
Cita de: Krnl64 en 18 Junio 2006, 21:01 PMLlevais razon, Error gordo el mio.
Efectivamente; todos nos equivocamos y es muy buena la capacidad de reconocerlo.
Cita de: Krnl64 en 18 Junio 2006, 21:01 PMBueno, gracias a vuestra explicacion me quedo claro el concepto.
De nadas ;)