Abril Negro 2008: Taller de Formato PE by Ferchu

[nhaalclkiemr]

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

[RaPeRoO]

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

[Ferсhu]

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.

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!!!

[Ferсhu]

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

[nhaalclkiemr]

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 

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

[Thor]

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

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.

[Ferсhu]

Capitulo nuevo agregado.

[krackwar]

exelente trabajo felisitaciones

[fernacho]

Buen trabajo, a LEER!