Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - x64core

#661
Cita de: 85 en 27 Febrero 2013, 08:31 AM
Para el rico bepi de x64core que dice que usar el ensamblador en línea no es portable, y si pero qué me importa? si el objetivo es parchear la IAT......
si quiero lo hago todo con ensamblador en línea we
Era algo demostrativo nada más...

veamos como quedaría:

/* __asm {
mov ebx, dwGPA
mov edx, [ebx]
mov pGetProcAddress, edx
}*/


POR

typedef FARPROC (WINAPI* GetProcAddress_t) ( HMODULE hModule, LPCSTR lpProcName );

pGetProcAddress = *(GetProcAddress_t*)dwGPA;


Felicidades, ya pudiste acceder al contenido de un puntero sin usar ensamblador al menos usando tu estilo de casting ;-)
#662
Cita de: 85 en 27 Febrero 2013, 07:52 AM
para que voy a adjuntar el OLLY DBG ? necesito hacer eso?
puedo abrilo con un editor PE sólamente.  

EJ: LORD PE

Seguro no conocés nada, ni el OLLY, ni el LORD PE, windbg?

quién habló de hookear APIs? PFF

El título te lo dice amigo:

Pachear la IAT, no es hooking en general, el hooking es algo secundario en este topic, el tema era parchear la IAT.

seguro estás aprendiendo API hooking y me lo querés demostrar XD

JAJA x64 se pone,  nice bepi  ::)



Este chico es tan divertido, solo para que no continues espameando el foro, mandame algo decente por MP.

#663
Cita de: 85 en 27 Febrero 2013, 07:40 AM
mi publicación es decente, el indecente sos vos amigo.

que tiene que ver que la IAT no está siempre en esa dirección?

para algo la busqué en el PE EXPLORER !! se trata de usar el desensamblador no de hacer algo automático. Si se trata de este programa específicamente!. Ni leer sabés, nice bepi


y si, tal parece que se ha publicado 1001 vez



Cita de: 85 en 27 Febrero 2013, 07:40 AM
que tiene que ver que la IAT no está siempre en esa dirección?
Lucis como que no tenes idea de lo que vos mismo publicas, bueno no me extrañaria, ya que al parecer solo sabes usar un desesamblador y tener el estilo de un niño programador.

Y eso quiere decir que cada vez que quiero hookear la IAT tendre que usar un desesamblador y todo lio que has publicado?
Estamos en el año 2013 si no te has dado cuenta.
#664
Hola,

400000+2004=IAT
Quien dice que la IAT siempre sera almacenada en esa dirección? En ese programa tal vez, pero creo que si vas a publicar
un metodo que fue ya publicado más de 1000 veces no crees que seria al menos publicar algo decente?

__asm {
mov ebx, dwGPA
mov edx, [ebx]
mov pGetProcAddress, edx
}

porque usar ensamblador directo para acceder al contenido de un puntero?
#665
Establece el Entrypoint en tu cmpilador, si es VS podes usar esto:

#pragma comment(linker,"/ENTRY:main")

"main" en tu caso
#666
Programación C/C++ / Re: C++ y Windows 7 ??
26 Febrero 2013, 19:56 PM
Cita de: Vaagish en 26 Febrero 2013, 19:51 PM
Gracias gente!

No uso nada raro,, incluyo el <iostream> y el <conio.h>, luego un using namespace std;

void main()
{
  cout << "Hola mundo";
  getch();
}

Una cosa recontra simple,, pero justamente lo que queria probar era la compatibilidad.. y de entrada con 8 lineas de codigo ya me salta error :/
Tenes dos opciones:
1:Enlazar estaticamente, El .exe llega a tener un tamaño generalmente superior a 1MB
2:usar Win32,  GetStdHandle, Writeconsole. Si utilizas estas funciones tu programa funcionara en cualquier version de Windows.

Además siempre es bueno leer más acerca cada funcion, más funciones:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682073(v=vs.85).aspx
#667
Programación C/C++ / Re: C++ y Windows 7 ??
26 Febrero 2013, 19:44 PM
Cita de: Vaagish en 26 Febrero 2013, 19:37 PM
Hola! Y gracias por responder!
En este momento no estoy en mi computadora,, pero si no mal recuerdo es el "msvcp100.dll",, pero primero les cuento como da el error...
La cosa es asi..
Instale el visual studio 2010 en windows xp, cree un simple .exe en c++ nativo y lo corri en windows xp sin problemas,, no falta nada.. pero al pasar ese mismo .exe a windows 7, ahi salta el problema, falta el .dll
Muy bien, asi que instale el visual studio 2010 en windows 7, y ahora si funciona el .exe
Evidentemente esa libreria me la instala visual studio.. pero eso no es lo importante..

Yo quiero que mis aplicaciones en c++ nativo corran en cualquier windows (xp, 7 y 8) sin tener que descargar una libreria, o mucho peor tener que instalar visual studio,, no tiene sentido... :/

Gracias otra vez!!

Librerias tales como esas se tendran que enlazar estaticamente como dijo Eternal Idol ( si quieres que tu Programa funcione en Windows donde no tienen instalada tal li breria ) . Aunque yo en lo personal uso librerias del Propio SO para reemplazar las funciones que necesito o bien implemento las que necesito. Que tipo de funciones estas usando en tu programa? para poderte decir que hacer en ese caso. pero no te preocupes es un caso tan facil de resolver.
#668
Cita de: Xafi en 26 Febrero 2013, 17:25 PM
osea usas el segundo código, esto que quieres decir que la referencia explicita no funciona en C?
Yo suelo usar la segunda.
al hacerlo como el segundo código, no se crea ninguna variable local verdad?

Referencias no existen en C.
Si te refieres a la variable local que creaste en ambos códigos, en ambos códigos se puede acceder sin ninguna variable local.

void cambiar(int *valor){
    *valor=7;
}

void cambiar(int &valor){
    valor=7;
}

La diferencia es el operador para des-referenciar el puntero.
#669
Cita de: Xafi en 26 Febrero 2013, 16:20 PM
Es los mismo lo siguiente?

Código (cpp) [Seleccionar]
#include <iostream>

using namespace std;
int *px;
void cambiar(int *valor){
   px= valor;
   *px=7;
}
int main(int argc, char*argv[]){
   int x=0;
   cout << x << endl;
   cambiar(&x);
   cout << x << endl;
}


Código (cpp) [Seleccionar]
#include <iostream>

using namespace std;
int *px;
void cambiar(int &valor){
   px= &valor;
   *px=7;
}
int main(int argc, char*argv[]){
   int x=0;
   cout << x << endl;
   cambiar(x);
   cout << x << endl;
}


Hola,

Los dos codigos pasan una referencia a la variable, en una pasa el puntero (C) en otra pasa por referencia explicita (C++).
Yo por lo general uso la referencia por punteros.

#670
Cita de: ~ en 25 Febrero 2013, 20:22 PM
Lo mismo que hace portables a C o C++ (hacer ciertas conversiones entre distintas arquitecturas, o dejar las instrucciones como están) es lo que haría al Ensamblador portable en los mismos términos, pero por una u otra razón nadie se ha interesado hasta ahora en resolver ese problema.
No solo es el termino portable, además es la facilidad a agregar modificaciones y correcciones , por ejemplo que hay acerca de agregar variables,
array locales, en ensamblador se tendria que reescribir la completa funcion en cambio en C/C++ es simplemente agregar el tipo y nombre de la variable(s)
y luego el compilador se encarga de todo los calculos, entiendo que podría hacerse un compilador de tal idea ( no he dicho que no es posible )

Cita de: ~ en 25 Febrero 2013, 20:22 PM
Pero por ejemplo para ingeniería inversa, en los casos en los que no se puede representar código con C, un lenguaje como este sería la mejor opción, además de hacer que sea más fácil leer desensamblajes enormes.[/b]
Que quieres decir? Te estas refiriendo en que los desemsabladores mostrarian tal sintaxis en lugar, creo que los desemsambladores se hicieron para tal caso
mostrar totalmente las instrucciones de un programa como tal, diferente es poder representar algun tipo de Pseudocodigo para el desensamblaje.

Cita de: ~ en 25 Febrero 2013, 20:22 PM
La realidad es que hay tareas de programación que solo se ven elegantes con código de tan bajo nivel como este; y hay otras tareas que solo se ven elegantes con lenguajes a nivel de C o C++. Por eso sería mejor un compilador capaz de usar diferentes lenguajes de forma nativa, para que cada tarea sea lo más elegante y legible posible en su dimensión.

Por ejemplo, sea dentro o fuera de Windows, si lo que queremos es programar registros gráficos VGA estándar o no estándar, lo mejor es usar un lenguaje claro y portable, de más bajo que C. Eso hará el código extremadamente elegante.

Estas hablando de saber varios lenguajes de programación para hacer cada tipo de tareas?
No crees que es mucho? Si lo que se quiere es ahorrar tiempo, lo que quiero decir es, sabemos que algunos tareas se hacen más rapido con lenguajes de alto nivel a diferencia de "medios"/bajos, Pero agregar elegancia a un lenguaje? Más elegancia de lo que un lenguaje como C++ puede tener? Yo creo en que un lenguaje de programación es un lenguaje como tal, diferente es que una tarea en comun luce dependiendo en que lenguaje de programación fue hecha, así de simple.


Cita de: ~ en 25 Febrero 2013, 20:22 PM
Librería VGA Estándar (para 16, 32 y 64 bits, con RealC)
Por ejemplo este es código de RealC para cambiar modos en VGA:
Lo unico que veo son llamadas y llamadas a funciones que utilizan ensamblador en linea, con estilo de sintaxis C.
Aquí el tema es la potabilidad, es lo realmente creo que interesa, hay muchos lenguajes con estilo de sintaxis C o nada interesante realmente.


Cita de: ~ en 25 Febrero 2013, 20:22 PM
Y este es en Ensamblador (bastante menos legible y modificable, especialmente si leemos el resto del código en el ZIP):
Mira lo que haces, estas comparando el lenguaje lenguaje ensamblador y un lenguaje de estilo sintaxis C y hablando de legibilidad y de modificabilidad?
Eso es tan obvio, si no hay más de las muchas diferencias hay entre ensamblador y C existen?

Cita de: ~ en 25 Febrero 2013, 20:22 PM
Aquí tengo un proyecto que creé hace un tiempo que tiene la inteción de enviarle comandos a los periféricos desde una consola nativa de DOS (y emular registros del CPU para poder enviarle interrupciones paso a paso):

Proyecto LowEST (Inglés)

El código fuente está escrito en RealC, y también incluye el código de Ensamblador equivalente. Una función en RealC es menos confusa que su misma versión en Ensamblador, pero realmente es Ensamblador más fácil de leer con potencial de ser totalmente portable:
Mostrar tu código esta bien, pero como digo de nuevo aqui el tema es que dices que es conveniente, posible hacer que el lenguaje ensamblador sea portable.
La verdad me gustaría mirar ese compilador o algo interesante sobre tal tema y no comparación entre lenguajes.

Cita de: ~ en 25 Febrero 2013, 20:22 PM
Si se tiene experiencia en crear programas de Windows en Ensamblador desde el formato del Portable Ejecutable, entonces sería mucho más fácil con un lenguaje como RealC, sin necesidad de linkers o compiladores, solo un ensamblador.
Ensamblador
;NOTA: Ensamblar con el comando:
;
;        NASM pehead.asm -o pehead.exe


EXE_start:

bits 32

alig equ 16


%define round(n, r) (((n+(r-1))/r)*r)



DOS_stub_start:
 db 'MZ'


 times 0x3A db 0


 dd PEhead


DOS_stub_end:
DOS_stub_SZ equ (DOS_stub_end-DOS_stub_start)


PE_head_start:
 PEhead:

 PEhead.Signature            db 'P','E',0,0

 PEhead.Machine              dw 0x14C

 PEhead.NumberOfSections     dw 1

 PEhead.TimeDateStamp        dd 0

 PEhead.PointerToSymbolTable dd 0

 PEhead.NumberOfSymbols      dd 0

 PEhead.SizeOfOptionalHeader dw 4

 PEhead.Characteristics      dw 0x0103

PE_head_end:
PE_head_SZ equ (PE_head_end-PE_head_start)



Opt_Head_start:
 OptHead:

 OptHead.Magic                   dw 0x10B
 OptHead.MajorLinkerVersion      db 8
 OptHead.MinorLinkerVersion      db 0
 OptHead.SizeOfCode              dd round(codesize,alig) ;1024 ;Code_SZ
 OptHead.SizeOfInitializedData   dd 0
 OptHead.SizeOfUninitializedData dd codesize ;1024
 OptHead.AddressOfEntryPoint     dd PrgEntry
 OptHead.BaseOfCode              dd codesize ;1024
 OptHead.BaseOfData              dd PrgEntry
 OptHead.ImageBase               dd 0x400000
 OptHead.SectionAlignment        dd alig
 OptHead.FileAlignment           dd alig
 OptHead.MajorOSVersion          dw 4
 OptHead.MinorOSVersion          dw 0
 OptHead.MajorImageVersion       dw 0
 OptHead.MinorImageVersion       dw 0
 OptHead.MajorSubsystemVersion   dw 4
 OptHead.MinorSubsystemVersion   dw 0
 OptHead.Win32VersionValue       dd 0
 OptHead.SizeOfImage             dd round(hdrsize,alig)+round(codesize,alig) ;1024 ;EXE_SZ
 OptHead.SizeOfHeaders           dd round(hdrsize,alig) ;Headers_SZ
 OptHead.Checksum                dd 0
 OptHead.Subsystem               dw 2
 OptHead.DllCharacteristics      dw 0
 OptHead.SizeOfStackReserve      dd 0
 OptHead.SizeOfStackCommit       dd 0
 OptHead.SizeOfHeapReserve       dd 0
 OptHead.SizeOfHeapCommit        dd 0
 OptHead.LoaderFlags             dd 0
 OptHead.NumberOfRvaAndSizes     dd 3
   OptHead.ExportTable.VirtualAddress dd 0
   OptHead.ExportTable.Size           dd 0

   OptHead.ImportTable.VirtualAddress dd ImportDirectoryTable
   OptHead.ImportTable.Size           dd ImportDirectoryTable_SZ

   OptHead.ResourceTable.VirtualAddress dd ResourceTable
   OptHead.ResourceTable.Size           dd 4096 ;ResourceTable_SZ

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0

   dd 0
   dd 0
Opt_Head_end:
Opt_Head_SZ equ (Opt_Head_end-Opt_Head_start)



hdrsize equ $ - $$



Headers_SZ equ $-$$ ;(Opt_Head_SZ+PE_head_SZ+DOS_stub_SZ)






db ".code"
times 3 db 0

_virtualsize dd 2048
_virtualaddress dd PrgEntry
_sizeofrawdata dd 2048
_pointertorawdata dd PrgEntry
_pointertorelocations dd 0
_pointertolinenumbers dd 0
_numberofrelocations dw 0
_numberoflinenumbers dw 0
_characteristics dd 0x60000020



db ".rsrc"
times 3 db 0

virtualsize dd 2048
virtualaddress dd ResourceTable
sizeofrawdata dd 2048
pointertorawdata dd ResourceDirectoryEntry
pointertorelocations dd 0
pointertolinenumbers dd 0
numberofrelocations dw 0
numberoflinenumbers dw 0
characteristics dd 0x50000040





align 16
PrgEntry:
align 16
   push dword 0x20
   push dword str1+0x400000
   push dword str2+0x400000
   push dword 0
   call dword[ImportAddressTable.1_array0+0x400000]

   push dword 0x20
   push dword str1+0x400000
   push dword str2+0x400000
   push dword 0
   call dword[ImportAddressTable.1_array0+0x400000]

   push dword 0x20
   push dword str1+0x400000
   push dword str2+0x400000
   push dword 0
   call dword[ImportAddressTable.1_array0+0x400000]

   push dword 0x20
   push dword str1+0x400000
   push dword str2+0x400000
   push dword 0
   call dword[ImportAddressTable.1_array0+0x400000]
ret


align 4
str1 db "Stringz 1",0
align 4
str2 db "Srins 2",0
align 4
str3 db "Strins a3",0


;align 1048576



align 16
db "[EOF]",0










align 16
ResourceTable:




;align 8
;






ResourceDirectoryEntry:


ResourceDirectoryTable0:
 ResourceDirectoryTable0.Characteristics     dd 0
 ResourceDirectoryTable0.Time_DateStamp      dd 0x49DDFF5E
 ResourceDirectoryTable0.MajorVersion        dw 0
 ResourceDirectoryTable0.MinorVersion        dw 0
 ResourceDirectoryTable0.NumberOfNameEntries dw 0
 ResourceDirectoryTable0.NumberOfIDEntries   dw 1

   ResourceDirectoryEntry1:
     ResourceDirectoryEntry1.IntegerID           dd 3
     ResourceDirectoryEntry1.EntryRVA            dd 0x80000000+ResourceDirectoryTable2 ;(ResourceDirectoryTable2-ResourceTable)

       ResourceDirectoryTable2:
         ResourceDirectoryTable2.Characteristics     dd 0
         ResourceDirectoryTable2.Time_DateStamp      dd 0x49DDFF5E
         ResourceDirectoryTable2.MajorVersion        dw 0
         ResourceDirectoryTable2.MinorVersion        dw 0
         ResourceDirectoryTable2.NumberOfNameEntries dw 0
         ResourceDirectoryTable2.NumberOfIDEntries   dw 1


           ResourceDirectoryEntry3:
             ResourceDirectoryEntry3.IntegerID           dd 1
             ResourceDirectoryEntry3.EntryRVA            dd ResourceDirectoryTable4 ;(ResourceDirectoryTable4-ResourceTable)


               ResourceDirectoryTable4:
                 ResourceDirectoryTable4.Characteristics     dd 0
                 ResourceDirectoryTable4.Time_DateStamp      dd 0x49DDFF5E
                 ResourceDirectoryTable4.MajorVersion        dw 0
                 ResourceDirectoryTable4.MinorVersion        dw 0
                 ResourceDirectoryTable4.NumberOfNameEntries dw 0
                 ResourceDirectoryTable4.NumberOfIDEntries   dw 1

                   ResourceDirectoryEntry5:
                     ResourceDirectoryEntry5.IntegerID           dd 0
                     ResourceDirectoryEntry5.EntryRVA            dd ResourceDataEntry6 ;(ResourceDataEntry6-ResourceTable)


                       ResourceDataEntry6:
                         ResourceDataEntry6.DataRVA                  dd vsico
                         ResourceDataEntry6.Size                     dd 1024 ;vsico_SZ
                         ResourceDataEntry6.CodePage                 dd 0
                         ResourceDataEntry6.Reserved                 dd 0



;ResourceDirectoryEntry:
;  ResourceDirectoryEntry.NameRVA             dd namerva
;  ResourceDirectoryEntry.IntegerID           dd 3
;  ResourceDirectoryEntry.DataEntryRVA        dd ResourceDirectoryTable
;  ResourceDirectoryEntry.SubdirectoryRVA     dd 0
;
;
;
;ResourceDirectoryTable:
;  ResourceDirectoryTable.Characteristics     dd 0
;  ResourceDirectoryTable.Time_DateStamp      dd 0
;  ResourceDirectoryTable.MajorVersion        dw 8
;  ResourceDirectoryTable.MinorVersion        dw 0
;  ResourceDirectoryTable.NumberOfNameEntries dw 1
;  ResourceDirectoryTable.NumberOfIDEntries   dw 1
;
;
;
;ResourceDataEntry:
;  ResourceDataEntry.DataRVA                  dd vsico
;  ResourceDataEntry.Size                     dd vsico_SZ
;  ResourceDataEntry.CodePage                 dd 0
;  ResourceDataEntry.Reserved                 dd 0



align 16
vsico:
;incbin "bc.ico"

vsico_SZ equ $-vsico


ResourceTable_SZ equ $-ResourceTable

















ImportDirectoryTable:
ImportDirectoryTable_start:
  ImportTable.ImportLookupTableRVA_array0  dd ImportLookupTable_array0
  ImportTable.Time_DateStamp_array0        dd 0
  ImportTable.ForwarderChain_array0        dd 0
  ImportTable.NameRVA_array0               dd DLL_name_array0
  ImportTable.ImportAddressTableRVA_array0 dd ImportAddressTable_array0

  ImportTable.ImportLookupTableRVA_array1  dd 0
  ImportTable.TimeDateStamp_array1         dd 0
  ImportTable.ForwarderChain_array1        dd 0
  ImportTable.NameRVA_array1               dd 0
  ImportTable.ImportAddressTableRVA_array1 dd 0





ImportDirectoryTable_end:
ImportDirectoryTable_SZ equ (ImportDirectoryTable_end-ImportDirectoryTable_start)


ImportAddressTable_array0:
  ImportAddressTable.1_array0 dd Hint_NameTable_array0 ;0x80000000+477
  ImportAddressTable.2_array0 dd 0


ImportLookupTable_array0:
  ImportLookupTable.Ordinal_Name_OrdinalNum_array0 dd Hint_NameTable_array0 ;0x80000000+477
  ImportLookupTable.Hint_NameTableRVA_array0       dd 0




Hint_NameTable_array0:
  dw 0x1DC
  db "MessageBoxA",0



DLL_name_array0:
db "USER32.dll",0



codesize equ $ - PrgEntry


namerva db "ICON",0


EXE_end:
EXE_SZ equ round((EXE_end-EXE_start),alig)

Code_SZ equ round(($-PrgEntry),alig)


Lo que veo es que has hecho un pequeño programa que esta hecho basado en bytes, cadenas definidas y mnemonicos y hablas acerca de que seria más facil
en lugar de usar un linker y como dije ensamblador en linea, pero no veo nada acerca de como resuelves posibles insercion de bytes como instrucciones ( __emit de VC ), o archivos .obj ( como tu dices ) calculo de offsets, y claro implementación de la tabla relocalizadora del formato del .EXE. Realmente creo que hay mucho pero demasiado que falta y esta bien, pero si hablas de hechos que realmente son, nos gustaria mirar un poco acerca de la facilidad del uso.


Cita de: ~ en 25 Febrero 2013, 20:22 PM
Hay muchas otras convenciones en las que pensar, pero esto requiere un nivel dramáticamente alto en creación de compiladores optimizadores, convenciones de llamada estándar, y lenguajes como C y C++ (para integrarlos), además de muchos estándares para poder hacer algo realmente utilizable que interactúe bien con el resto del mundo real. Eso es lo que habría que aprender a implementar desde cero para que este tipo de ideas de un Ensamblador portable pudiera extenderse.
Y honestamente no hay mucho que hablar no cite todos tus parrafos donde mencionas la facilidad de la que hablas, escribir es facil , realmente demostrar es distinto si solo muestras un lenguaje en estilo de sintaxis de C y Ensamblador, como dije no seria nuevo o interesante,
A mi lo que me intereso fue lo que mencionabas, hacer que el lenguaje ensamblador fuera portable ( basandome en la idea que tienes: crear un compilador que pueda generar los codigos de operacion respectivos para cada arquitectura apartir de x86 o x86-64? probablemente x86 ) , la idea esta bien incluso me esperaría al menos un POC de un programa hola mundo por lo menos y pues claro tenga todas la facilidades que mencionaste anteriormente. :)

Amigo realmente crees que no estas exagerando?