elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.


 


Tema destacado: Sigue las noticias más importantes de elhacker.net en ttwitter!


+  Foro de elhacker.net
|-+  Seguridad Informática
| |-+  Análisis y Diseño de Malware
| | |-+  Abril negro (Moderadores: Man-In-the-Middle, WHK, fary)
| | | |-+  Abril Negro 2008: Taller de Formato PE by Ferchu
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: 1 [2] Ir Abajo Respuesta Imprimir
Autor Tema: Abril Negro 2008: Taller de Formato PE by Ferchu  (Leído 19,899 veces)
nhaalclkiemr


Desconectado Desconectado

Mensajes: 1.677


Máximo exponente 9DB9F1AEED2FADBDE 997BBE20FEDA92


Ver Perfil WWW
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #10 en: 15 Abril 2008, 14:51 »

Yo aunke no diga nada lo sigo...de momento se algunas cosas del PE pero hay cosas (como modificar la IAT y otras muchas cosas) k no entiendo aun...k sepais k lo seguiré...

y weno una cosa...corregidme si me ekivoco pero para sacar el offset fisico (en el archivo) teniendo un offset virtual hay que obtener la diferencia restando a el VirtualAddress el PointerToRawData de la sección en la k se encuentre ese offset virtual (y weno en el caso de k en vez de 'ofset virtual' tengamos 'direccion virtual' tambien habría que restar la ImageBase)...

Weno me explico, hace poco tuve k conseguir el EntryPoint en un archivo (pero la posicion real, el offset en el archivo), pero al obtenerlo te dan su offset virtual (no te dan la direccion virtual pork falta sumarle la Image Base), pues bien, el offset virtual no se corresponde con el fisico, para obtener el físico lo k tengo k hacer es al EntryPoint restarle la resta del VirtualAddress y del PointerToRawData de la sección en la k se encuentre el EntryPoint...sería como decir que la diferencia entre el offset virtual y el offset fisico en esa sección es VirtualAddress - PointerToRawData, de manera que para obtener el offset fisico teniendo el offset virtual habría que hacer: offset_fisico = offset_virtual - (VirtualAddress - PointerToRawData) (o lo k es lo mismo: offset_fisico = offset_virtual - VirtualAddress + PointerToRawData)...en el caso de tener el offset_fisico y kerer obtener el virtual sería:
offset_virtual = offset_fisico + VirtualAddress - PointerToRawData...esto teniendo siempre en cuenta que el VirtualAddress y el PointerToRawData son los correspondientes a la sección en la k se encuentre el offset_virtual

Weno ese es el método k utilizo yo, mi pregunta es si hay alguna forma más facil de obtener esa diferencia y si lo k digo está bien...y weno de paso ya pongo lo k hago yo por si alguien le sirve...

Saludos ;)


« Última modificación: 15 Abril 2008, 15:54 por nhaalclkiemr » En línea

StasFodidoCrypter 1.0 - 100% (old)
StasFodidoCrypter 2.0 - 85% (deserted)
Fire AV/FW-Killer - 97% (deserted)
R-WlanXDecrypter 1.0- 100%
RaPeRoO

Desconectado Desconectado

Mensajes: 9



Ver Perfil
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #11 en: 15 Abril 2008, 18:42 »

si lo explicas asi no me pierdo  ;D tio vente tu a enseñarnos informatica a mi insti


En línea

Ferсhu


Desconectado Desconectado

Mensajes: 1.214

Menos palabras y Mas codigos.


Ver Perfil WWW
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #12 en: 16 Abril 2008, 06:03 »

Citar
y weno una cosa...corregidme si me ekivoco pero para sacar el offset fisico (en el archivo) teniendo un offset virtual hay que obtener la diferencia restando a el VirtualAddress el PointerToRawData de la sección en la k se encuentre ese offset virtual (y weno en el caso de k en vez de 'ofset virtual' tengamos 'direccion virtual' tambien habría que restar la ImageBase)...

No tiene mucho sentido sacar el offset fisico de un archivo ya q el editor hexa a la unica referencia q hace es hacia el inicio. Entonces no hay offset, sino "direcccion" o posicion, Asi:

Direccion fisica = Direccion virtual - VirtualAdrress - ImageBase + PointerToRawData

*La VirtualAdrress y PointerToRawData obviamente de la misma sección.

Citar
Weno me explico, hace poco tuve k conseguir el EntryPoint en un archivo....

Para sacar la direccion del entrypoint en el archivo en el notepad.exe, como el dato del OEP en la cabecera nos dice el offset virtual, solo hay q hacer lo siguiente:

Direccion fisica = AddressOfEntryPoint - VirtualAdrress + PointerToRawData.

Direccion fisica = 0x739d - 0x1000 + 0x400 = 0x679d


Saludos!!!




En línea

Ferсhu


Desconectado Desconectado

Mensajes: 1.214

Menos palabras y Mas codigos.


Ver Perfil WWW
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #13 en: 17 Abril 2008, 08:04 »

Taller updated, agregue el segundo capitulo al primer post, para que este todo junto.
En línea

nhaalclkiemr


Desconectado Desconectado

Mensajes: 1.677


Máximo exponente 9DB9F1AEED2FADBDE 997BBE20FEDA92


Ver Perfil WWW
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #14 en: 17 Abril 2008, 16:19 »

Si ya se k se habla de direcciones en vez de offsets...pero es que tu haces esa distincion y por eso la hice yo...pork en realidad la direccion virtual hay que sumarle la ImageBase y en muchos de los datos te dan la direccion virtual sin la ImageBase...entonces era para no complicarme...

Pero weno entonces mi teoría estaba bien  :xD

Sobre lo de agregar una sección ya lo había hecho alguna vez...lo k no entiendo es pork ponemos el Bound Import Table (tanto el adress como el size) a 0...ya se k es para desvincularlo...pero y luego esa tabla no es importante? en teoría no es la Import Table la que contiene la lista de API's (importaciones)??

No se digo yo que alguna funcion tendrá...y weno puede que en notepad.exe no sea importante pero a lo mejor con otro archivo podríamos dejarlo inservible? o no? es k weno si no hay espacio por ai siempre se pueden agregar más 0's aunke el notepad.exe final ocupe más que el original...

Saludos ;)
En línea

StasFodidoCrypter 1.0 - 100% (old)
StasFodidoCrypter 2.0 - 85% (deserted)
Fire AV/FW-Killer - 97% (deserted)
R-WlanXDecrypter 1.0- 100%
Thor


Desconectado Desconectado

Mensajes: 1.176


Ver Perfil
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #15 en: 17 Abril 2008, 17:08 »

Creo que el objetivo de la bound table es no tener que rellenar la Import Address Table al arrancar el ejecutable, ejecutándose este algo mas rápido.

Aquí está explicado
Citar
Binding
      When an executable is bound (via the Bind program, for instance), the IMAGE_THUNK_DATA structures in the IAT are overwritten with the actual address of the imported function. The executable file on disk has the actual in-memory addresses of APIs in other DLLs in its IAT. When loading a bound executable, the Windows loader can bypass the step of looking up each imported API and writing it to the IAT. The correct address is already there! This only happens if the stars align properly, however. My May 2000 column contains some benchmarks on just how much load-time speed increase you can get from binding executables.
      You probably have a healthy skepticism about the safety of executable binding. After all, what if you bind your executable and the DLLs that it imports change? When this happens, all the addresses in the IAT are invalid. The loader checks for this situation and reacts accordingly. If the addresses in the IAT are stale, the loader still has all the necessary information from the INT to resolve the addresses of the imported APIs.
      Binding your programs at installation time is the best possible scenario. The BindImage action of the Windows installer will do this for you. Alternatively, IMAGEHLP.DLL provides the BindImageEx API. Either way, binding is good idea. If the loader determines that the binding information is current, executables load faster. If the binding information becomes stale, you're no worse off than if you hadn't bound in the first place.
      One of the key steps in making binding effective is for the loader to determine if the binding information in the IAT is current. When an executable is bound, information about the referenced DLLs is placed into the executable. The loader checks this information to make a quick determination of the binding validity. This information wasn't added with the first implementation of binding. Thus, an executable can be bound in the old way or the new way. The new way is what I'll describe here.
      The key data structure in determining the validity of bound imports is an IMAGE_BOUND_IMPORT_DESCRIPTOR. A bound executable contains a list of these structures. Each IMAGE_BOUND_IMPORT_DESCRIPTOR structure represents the time/date stamp of one imported DLL that has been bound against. The RVA of the list is given by the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT element in the DataDirectory. The elements of the IMAGE_BOUND_IMPORT_DESCRIPTOR are:

    * TimeDateStamp, a DWORD that contains the time/date stamp of the imported DLL.
    * OffsetModuleName, a WORD that contains an offset to a string with the name of the imported DLL. This field is an offset (not an RVA) from the first IMAGE_BOUND_IMPORT_DESCRIPTOR.
    * NumberOfModuleForwarderRefs, a WORD that contains the number of IMAGE_BOUND_FORWARDER_REF structures that immediately follow this structure. These structures are identical to the IMAGE_BOUND_IMPORT_DESCRIPTOR except that the last WORD (the NumberOfModuleForwarderRefs) is reserved.

      In a simple world, the IMAGE_BOUND_IMPORT_DESCRIPTORs for each imported DLL would be a simple array. But, when binding against an API that's forwarded to another DLL, the validity of the forwarded DLL has to be checked too. Thus, the IMAGE_BOUND_FORWARDER_REF structures are interleaved with the IMAGE_BOUND_IMPORT_DESCRIPTORs.
      Let's say you linked against HeapAlloc, which is forwarded to RtlAllocateHeap in NTDLL. Then you ran BIND on your executable. In your EXE, you'd have an IMAGE_BOUND_IMPORT_DESCRIPTOR for KERNEL32.DLL, followed by an IMAGE_BOUND_FORWARDER_REF for NTDLL.DLL. Immediately following that might be additional IMAGE_ BOUND_IMPORT_DESCRIPTORs for other DLLs you imported and bound against.

Buen tutorial, un saludo.
En línea

Ferсhu


Desconectado Desconectado

Mensajes: 1.214

Menos palabras y Mas codigos.


Ver Perfil WWW
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #16 en: 23 Abril 2008, 20:45 »

Capitulo nuevo agregado.
En línea

krackwar


Desconectado Desconectado

Mensajes: 898


Ver Perfil
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #17 en: 18 Mayo 2008, 06:04 »

exelente trabajo felisitaciones ;)
En línea

Mi blog
Bienvenido krackwar, actualmente tu puntuación es de 38 puntos y tu rango es Veteran.
El pollo número 1, es decir yo, (krackwar), adoro a Shaddy como a un dios.
fernacho

Desconectado Desconectado

Mensajes: 26

Fer el Newbie


Ver Perfil
Re: Abril Negro 2008: Taller de Formato PE by Ferchu
« Respuesta #18 en: 21 Mayo 2008, 21:12 »

Buen trabajo, a LEER!
En línea

Deseando aprender un poco mas y mas...
Páginas: 1 [2] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
tengo problemas con el tuto de Ferchu sobre PE « 1 2 »
Análisis y Diseño de Malware
Belial & Grimoire 10 4,750 Último mensaje 30 Enero 2011, 06:23
por Belial & Grimoire
a que se referia Ferchu con redondear VirtualAddres?
Análisis y Diseño de Malware
Belial & Grimoire 2 2,211 Último mensaje 9 Noviembre 2011, 19:45
por fary
Abril Negro 2008
Abril negro
WHK 0 539 Último mensaje 4 Febrero 2017, 19:30
por WHK
Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines