Extrem kleine Asm-Programme

Kannst dich noch ungefähr an de seite erinnern?

masterofx32

#pragma comment(linker,"/NODEFAULTLIB")
#pragma comment(linker,"/ENTRY:WinMain")

#pragma comment(linker,"/MERGE:.rdata=.data")
#pragma comment(linker,"/MERGE:.text=.data")

#pragma comment(linker,"/SECTION:.data,ERW,ALIGN:64")
//#pragma comment(lib,"msvcrt.lib")

//Nicht mittels pragma definierbar:
//#pragma comment(linker,"/ALIGN:64");
//#pragma comment(linker,"/STUB:smallstub.dat");

#include <windows.h>

typedef BOOL (WINAPI *PBEEPFUNC)(DWORD,DWORD);

int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
	((PBEEPFUNC)0x7C838A53)(500,100);
	((PBEEPFUNC)0x7C838A53)(600,100);
	((PBEEPFUNC)0x7C838A53)(700,100);	
}

Ergibt bei mir mit Visual Studio 7.1 eine unter Windows XP lauffähige 576 Byte große EXE-Datei. Die Funktion Beep wird direkt über die Adresse aufgerufen, da die Kernel32.dll eigentlich bei jedem Prozess an die gleiche Adresse gemappt wird und man sich somit den statischen Import für die Funktion sparen kann. Der Standard-DOS-Stub, den VS7.1 anhängt ist etwa 180byte groß, mit der Linkeroption STUB kann aber ein eigener Stub eingefügt werden. Dieser muss angeblich mindestens 64Byte groß sein aber ich konnte noch keinen erstellen, den der Linker als gültiges DOS-Programm erkannt hat. Theoretisch könnte man den DOS-Stub auch komplett weglassen (manuell nach dem Compilieren). In dem Fall und könnte somit weitere 180 Byte einsparen. Ansonsten könnte man vielleicht noch die Directories im Optional Header entfernen, aber da bin ich mir nicht so sicher, ob es dann noch lauffähig ist.
Alles in Allem ist diese EXE natürlich ein wackeliges Konstrukt und allein schon wegen des Section Alignments nicht mehr standardkonform.

Weist du wo ich genaueres dazu finde?
MFg Hans

volkard

Hans94 schrieb:

Danke.
Und wie kann ich möglichst kleine Programme erstellen,die auch was machen??

für batch-programme war es immer wichtig, testen einlesen zu können. da hab ich mal ne com mit 5 bytes gesehen, die ein zeichen einliest und zurückgibt.

volkard schrieb:

da hab ich mal ne com mit 5 bytes gesehen, die ein zeichen einliest und zurückgibt.

also das kleinste was ich hinbekomme ist 9byte gross:

mov ah,01                2byte
mov dh,02                2byte
int 21h                  2byte
xchg dx,ax               1byte
jmp 0104                 2byte

5 byte: platz fuer nen int ein mov und evtl noch ein xchg koennt ich mir vorstellen. also 5 byte sollten doch ganz schoen knapp bemessen sein

ps. lasse mich gerne eines besseren belehren

masterofx32

Das sind doch aber alles keine gültigen Win32-Anwendungen und darum ging es dem Threadersteller ja wohl auch. Dass man ein reines Assembler-Programm ohne Rücksicht auf ein spezielles Executableformat oder Betriebssystem (wobei DOS ja mit den COM-Dateien ja auch recht sparsam ist) sehr klein bekommen kann, ist ja klar.

Genau.Also am interessantesten sah der c++ Beispielcode von masterofx32 aus.
Weis jemand einen link oder ähliches mit mer informationen?
Nfg Hans

masterofx32

Das lesen:

Prtable Executable File Format Specification.htm
Win32 Portable Executable File Format.pdf

Und dann solltest du dir die Optionen anschauen, die dein Linker dir bietet und wie diese sich auf die erstellte EXE auswirken. PEView

Hallo
Ich hab ein Problem,der USB Treiber eines ACER USB-Sticks wird nicht mehr erkannt nicht auf Linux und auch nicht auf Windows.Ich bekomme nicht mal ein Signal meines Linuxsystems wenn der USB-Stick eingesteckt ist.Bios hingegen erkennt das der USB
Stick eingesteckt ist.Von ACER bekomme ich keine Treiber mehr.Kann man da mit Assembler was machen so das das Teil wenigstens erkannt wird und man es wieder formatieren kann?...

masterofx32

Trexter schrieb:

Hallo
Ich hab ein Problem,der USB Treiber eines ACER USB-Sticks wird nicht mehr erkannt nicht auf Linux und auch nicht auf Windows.Ich bekomme nicht mal ein Signal meines Linuxsystems wenn der USB-Stick eingesteckt ist.Bios hingegen erkennt das der USB
Stick eingesteckt ist.Von ACER bekomme ich keine Treiber mehr.Kann man da mit Assembler was machen so das das Teil wenigstens erkannt wird und man es wieder formatieren kann?...

Ja, Assembler kann alles, damit kann man sogar DIREKT auf Hardware zugreifen - Mann, ist das toll! :p

Was haben die letzten 2 Beiräge Bitte schön mit dem Thema zu tun??
Naja.Ich habe gelesen,dass die Kernel32.dll und user32.dll immer an der gleichen Stelle im Speicher geladen sind.Wenn das stimmt,wo ist das?
Was macht die Präprozessordirektive "Pragma".
Mfg Hans

Ringding

Ich habe gelesen,dass die Kernel32.dll und user32.dll immer an der gleichen Stelle im Speicher geladen sind.

Auf der gleichen Windows-Version schon, aber die Adresse ist höchstwahrscheinlich bei XP und 2000 jeweils eine andere, möglicherweise spielen da auch installierte Service Packs eine Rolle.

Das ist nicht so wichtig.Mir geht es darum,dass ich bei meinem PC mit Win XP und keinem ServicePack weis wo diese dlls sich befinden.
Wenn sie sich in meinem System immer an der selben Stellé befinden und ich weis wo diese ist,bin ich zu Frieden.
Was mich interessiert ist,wie ich rausbekomme wo sich die dlls befinden.
Gruß Hans

Ringding

Zeigt dir jeder Debugger an. Oder du schaust dir die DLLs mit dumpbin (vom Visual Studio) an.

Und was macht die Anweisung "Pragma" im Beispielcode von Masterofx32 ??

masterofx32

Hans94 schrieb:

Und was macht die Anweisung "Pragma" im Beispielcode von Masterofx32 ??

Dem Compiler bescheid sagen, wie er etwas machen soll. Im Fall von #pragma comment (linker, xxx) werden die Optionen an den Linker weitergegeben.

//Nicht zu irgendeiner Standardbibliothek linken
#pragma comment(linker,"/NODEFAULTLIB")

/*WinMain als Funktion angeben, in die das Betriebssystem beim Ausführen
der EXE springen soll. Das wäre standardmäßig die Funktion WinMainCRTStartup
aus der Laufzeitbibliothek, die dann unsere eigene WinMain aufgerufen hätte.
Die Laufzeitbibliothek gibt es in dem Projekt aufgrund des vorherigen
Parameters aber nicht mehr also muss direkt WinMain als Einsprungspunkt angegeben werden.*/
#pragma comment(linker,"/ENTRY:WinMain") 

//Section .rdata und .text mit in die Section .data packen
#pragma comment(linker,"/MERGE:.rdata=.data")
#pragma comment(linker,"/MERGE:.text=.data")

/*Ausrichtung von 64 Byte und Lese-,Schreib- und Ausführzugriff für .data-Section setzen,
  da sie sonst nur Daten enthalten würde und keinen ausführbaren Code */
#pragma comment(linker,"/SECTION:.data,ERW,ALIGN:64")

Hans94 schrieb:

Das ist nicht so wichtig.Mir geht es darum,dass ich bei meinem PC mit Win XP und keinem ServicePack weis wo diese dlls sich befinden.
Wenn sie sich in meinem System immer an der selben Stellé befinden und ich weis wo diese ist,bin ich zu Frieden.
Was mich interessiert ist,wie ich rausbekomme wo sich die dlls befinden.
Gruß Hans

Die Adresse an welche die dll's im Speicher geladen werden kannst du mit GetModuleHandle() ermitteln.

z.B
HMODULE KernelBase;
KernelBase = GetModuleHandle("kernel32.dll");
Wenn du das meinst.

Am sonsten muss du wie alle Viren/Shellcodeprogrammierer vorgehen, und zwar so:

1. kernel32.dll image base address ermitteln (siehe unten)
2. Wenn du kernel32.dll gefunden hast, dann suchst du in seiner ExportTable nach
Funktionen, in der Regel sind das nur zwei:
a) LoadLibraryA() anderen dll's zu laden
b) GetProcAddress() Adressen von Funktionen zu bekommen
3. Jetzt mit diesen zwei funktionen kannst du alle Funktionen die du brauchst finden und aufrufen.

MASM32

find_kernel:
			xor	eax, eax 						; eax = 0
			ASSUME FS:NOTHING
			mov 	eax, fs:[eax+30h]					; Extract the PEB
			test	eax, eax						; Check for Windows 9x
			js 	kernel_9x 						; If signed jump to windows 9x lookup
		kernel_nt:
			mov 	eax, [eax+0Ch] 					; Extract the PROCESS_MODULE_INFO pointer from the PEB
			mov 	esi, [eax+1Ch] 					; Get the address of flink in the init module list
			lodsd 							; Load the address of blink into eax
			mov 	eax, [eax+8h] 					; Grab the module base address from the list entry
			jmp 	find_kernel_finish				; Fall down to the bottom
		kernel_9x:
			mov 	eax, [eax+34h] 					; Undocumented offset (0x34)
			lea 	eax, [eax+7Ch] 					; Load the address of eax+0x7c to keep us in signed byte range
			mov 	eax, [eax+3Ch] 					; Undocumented offset (0xb8)
		find_kernel_finish:
	       ; kernel32.dll image base ist nun im EAX

Also schau mal lieber das hier an: http://72.14.207.104/search?q=cache:ygC8U4urr18J:www.hick.org/code/skape/papers/win32-shellcode.pdf+win32+shellcode&hl=de