Om nog even terug te komen op de topic ik ben er in middels achter
hoe de null bytes eruit te krijgen.

Het was :

section .data
msg db "hello";

section .text

global _start
_start:

xor ecx,ecx
xor bl,bl
mov al,4
mov bl,1
mov ecx,msg
mov dl,4
int 0x80
mov bl,0
int 0x80

Maar hier verbaasde met toch nog iets met xor ebx, ebx en xor bl, bl
kreeg ik geen null bytes meer in mov bl,0.Dus vraag me af waarom
het met xor eax,eax niet dee en met mov al,4 niet eens xor nodig heb.
Weet iemand mischien hier het antwoord op?

mov ax,4 resulteerd in :
66 b8 04 00

mov ax,4 kun je ook schrijven als:
mov al,04
mov ah,00

mov al,04 heeft geen nul-byte

mov ah,00 kun je schrijven als:
mov ah,FF
xor ah,ah ( FF XOR FF = 00)

Greetingz,
Jacco

mov ah,00 kun je schrijven als

Thx, Met mov al,04 en mov ah ,00 wordt het een stuk duidelijker.Maar
als ik het goed begrijp is al + ah = ax , Moet ik dan de code nie
vervangen vanwege mov al,04 naar iets van :

xor ah,ah
mov al,04
mov ah,00

zodat al + ah weer ax wordt? Want als ik me niet vergiste was al 8
bytes en ah 8 bytes die nodig zijn voor ax omdat die 16 bytes is toch?

sinds wanneer is dit een programmeer forum ?

al en ah zijn 8 bits (niet bytes)
al en ah vormen samen het (16-bits) ax register

Greetingz,
Jacco

Jah, Ben momenteel bezig te leren hoe assembly werkt om zo
applicaties te kunnen testen en bugs in een programma op te sporen
om er vervolgens een patch voor te schrijven zodat het moeilijker
wordt het te exploiten.

Ik ben namelijk van mening wanneer je de zelfde technieken toepast
als een hacker zou doen je het moeilijker maakt voor een hacker om
het programma te kunnen exploiten.Ook kan je zo makkelijker na
security oplossingen zoeken om bv traps in een programma te zetten
waardoor een hacker misschien zou denken dat een backdoor is
maar eigenlijk een alarm hier door denkt die dat die controle heeft
over het programma maar weet je gelijk dat er iemand aanval heeft
geplaatst.

Eens Skismo.
Maar ergens zie ik in dingen die Anoniem doet,hetzelfde
als (robertoh) graag deed, zoals kwas wa ant prutse mee XP.
Waar zit die gozer eigenlijk?

Jacco thx!

waarom ga je software reversed patchen? (reversed engineerd
bugs opzoeken en reversed patchen.. ?) Handiger is 't
open-source software te gebruiken imho, hoef je ook niet
eerst assembly te leren maar kun je direct met 'n
'gemakkelijkere' taal aan de slag.

Ik wil ze niet reversed gaan patchen het is alleen voor het opsporen
van bugs en makkelijker dingen kan terug vinden met een debugger .

Niels thx, Ik had al gekeken met mov al,4 in objdump hier in gaf die
netjes b0 04 aan alleen had ik geen rekening gehouden met die
overige 24 bits :D

Ja, dat vraag ik me ook af. Anders wordt de vraag als er sprake is van CGI Null Byte attack en er een pakket dump moet worden gecontroleerd of er sprake is van een echte aanval (of niet).

Dus geachte Null-byte Anoniem: wil je in het vervolg dit forum alleen gebruiken voor security-related topics?

Uh ja en dat de oorspronkelijke vraagsteller shellcode niet snapt en hier
vragen stelt om hoe zijn programmeerprobleem op te lossen is wel security
gerelateerd? Dat is wel een tikkeltje vergezocht vind je niet? Kan je hier ook
wel een c 101 cursus neerplaatsen, mischien leert de gemiddelde security
officer daar ook nog wat van.

Als het nu een shellcode vraag betrof, maar dit is gewoon off-topic.

Ik weet ook wel dat het over shell code gaat Niels, en ik
weet ook dat Null byte attacks bestaan, maar hier gaat het
over een programmeer probleem. Als de schrijver per
se een veiligheidsprobleem had genoemd had ik er vrede mee
gehad.

Mijn excuses voor het plaatsen van de topic ik dacht alleen omdat
misschien wel meer mensen het leuk vonden om er wat van te leren
die misschien tegen het zelfde probleem aan liepen.

Wat ik jammer vind bij security.nl is dat er geen dat er geen categorie
bij kan komen voor dit onderwerp. Bedoel iedereen heeft het over
exploits en bugs. Maar ga je echt dieper op de theorie in van het
onstaan van exploits valt het in een keer onder programeren wat
eigenlijk niet zo is omdat het oogmerk op security valt en niet op
programering.

Tevens vindt ik het zonde dat een een site als security.nl wel de
inofrmatie update van patches voor bugs en zo.Maar dat er geen
mogelijkheid is assembly onder de knie te krijgen waaruit alle
exploits zijn onstaan.Persoonlijk vindt ik namelijk voor mensen
die als netwerkbeheer , programeur of welke baan ook die
met netwerk beveiliging in aanraking komen op z'n minst een
beetje kennis nodig moeten hoe assembly werkt.

He,
Er is een dunne lijn tussen ergens dieper op in gaan en iemand uitleggen
hoe assembly werkt. Jij bent duidelijk bezig met het laatste, zoals je zelf al
zegt. Het feit dat je dat op security.nl post maakt het oogmerk dan niet
plotseling 'security'.

Het is mischien wel jammer dat er geen categorie voor bestaat, maar
security en programmeren zijn 2 heeel diverse onderwerpen. Ik raad je dan
ook aan om gewoon op andere sites je probleem neer te zetten. Trust me,
ook al zou je het hier plaatsen, veel reacties zul je niet krijgen omdat de
gemiddele security offcier gewoon niet de kennis daarvoor heeft.

Wat je laatste statement betreft,voor mensen die netwerkbeheer of
beveiliging doen of programmeur, dat was vroeger ook zo, helaas gaan we
steeds meer naar de highlevel talen. assembler zijn de meeste mensen te
lui voor.

Jammer en eigenlijk ook zonde voor Security .nl
Er zijn genoeg leergierigen die meedenken omdat het betreffende
onderwerp meehelpt om je kennis te vergroten.
Diegeen die nu weggestuurt wordt ,gaat zijn heil misschien
elders zoeken,en dat kan voorkomen worden door de doelstelling
van deze Site iets te verruimen,zodat mensen die wat
te bieden hebben,hier graag zullen posten.
Een weggestuurde hond heb je ook niet zomaar terug.

Nu had ik hier ook al op gereageerd,maar mijn boodschap
is weggehaald,jammer voor mij maar ik vond het jammer
dat Anoniem van 14 okt :11.29 zich terug trok.
Maar wat ik nu lees van Twan Blum vind ik niet fair.
Komt hij een keer van achter de gordijnen, en gaat gelijk
van leer tegen Peter.
Ik hoop niet dat hiermee de situatie terug keert van een tijdje
geleden,toen hij ook al onder vuur lag.
Als je ziet hoeveel inzet Peter V aan Security.nl geeft,is er altijd
wel een moment om gelijk er op in te hakken.
Iedereen is nu eenmaal kwetsbaar, als je hier veel schrijft.
Ik hoop dat Twan dit begrijpt,want laat A.U.B. iedereen in
zijn waarde.

Nee, Twan dit komt gelukkig niet veel voor.
Maar hoe meer ik je reactie lees, hoe meer ik zie dat je wel
een erg grove aanval op Peter plaatste.
Niet netjes ,want het kan ook op een andere manier.

Nee, Twan dit komt gelukkig niet veel voor.
Maar hoe meer ik je reactie lees, hoe meer ik zie dat je wel
een erg grove aanval op Peter plaatste.
Niet netjes ,want het kan ook op een andere manier.

Om nog even terug te komen op de topic had ik nog een vraagje als dat
zou mogen.Hoe kan het eigenlijk dat 8 bits registers en een 32 bit
register samen kunnen gaan.Want wanneer ik mov ecx,msg verrander
na cx of cl geeft nasm een melding dat het een 32bit register moet zijn.
Ik dacht altijd dat alleen een 8 bit register of alleen 16 bits of alleen 32
bits met elkaar konden communiseren.Dan moeten er toch nog een
hope null-bytes ergens anders verstopt zitten?

Peter zegt dat je dit soort vragen niet moet posten omdat hij zelf ook
weleens hiervan beticht is. Van "fouten" leert men. Ook al heeft de vraag
wel met security te maken, het lijkt niet te passen niet in de
oorspronkelijke context van security.nl. Ik ben blij dat er lezers zijn die de
vraag kunnen beantwoorden, maar het zijn er hier veel meer die dat niet
kunnen. En met zi'n vraag als deze leert een onbekende met assembly
helemaal niets, daar gaat de vraag te diep voor.

OT ga naar de Intel site en download de references (PDF, gratis) voor Intel processoren. Daar staat precies in hoe, wat, waar en waarom.

Deze vraag gaat volledig over security en is dus on topic. Voor iedereen
die niet begrijpt wat de connectie met security is of voor wie het te
technisch wordt: verstuur a.u.b. geen commentaar. Dat maakt de reacties
een stuk beter leesbaar.

Twan is denk ik terecht een beetje boos op reageerders die niet weten
waar het over gaat en toch menen negatief te moeten reageren.

Ik ben het ook met Twan eens dat reacties niet moeten worden gegeven
om het reageren. Er zou nuttige en correcte informatie in zou moeten
staan. Herhaaldelijk reacties lezen als "Zucht! Alweer een patch, en ik heb
net gepatcht" is vervelend.

Ik ben het er gedeeltelijk mee eens. Ja, buffer overflows vallen inderdaad onder de categorie security. Proberen de nullen uit een stuk assembly te halen horen m.i. meer thuis in de categorie creatief assembly programmeren en zijn, inhoudelijk gezien, best interessant maar niet echt een security issue. Verder denk ik ook dat de gemiddelde security.nl lezer geen idee heeft waar je het over hebt (uitzonderingen daar gelaten). Wat dit onderwerp betreft denk ik dat bijv. een uitleg over waarom die nul bytes een issue zijn m.b.t. shellcode beter op z'n plaats is. Overigens zijn nullen niet het enige probleem waar je rekening mee dient te houden. Denk ook aan filters die alleen printable ASCII karakters doorlaten ;)

Het is creatief programmeren t.b.v. een security vraagstuk. Je kunt echt
geen zinnig antwoord verwachten als je dergelijke vragen stelt op een
programmeurs forum. Dat gebeurt hopelijk wel als je de vraag op een
security forum stelt. Gelukkig wordt die veronderstelling hier ook
bevestigd door diverse inhoudelijke reacties van mensen die weten waar
het over gaat.

Code zonder NULL bytes is interessant voor gebruik in omgevingen
waarbij die NULL bytes leiden tot problemen. Shellcode heeft daarom
vaak geen NULL byte. NULL bytes kunnen bijvoorbeeld tot problemen
leiden in de taal C, waar het "einde van een string" betekent. Als je een
NUL in je string hebt, is dat ook meteen het einde van die string. Als de
shellcode in een string moet passen, mogen daar dus geen NULL bytes
in zitten.

Persoonlijk vind ik het interessant om te proberen zulke code heuristisch
te herkennen op grond van het ontbreken van NULL bytes, of juist door
het herkennen van specifieke workarounds die zijn toegepast om NULL-
loze code te maken. Mogelijk zelfs zonder emulator kun je zo verdachte
code herkennen.

De reden die Anoniem zelf geeft in de posting vrijdag 13 oktober 2006
14:56 is ook interessant, lees maar na.

Links:
http://en.wikipedia.org/wiki/Shellcode

Indien de anoniem die dit topic begon echt in Shellcode will
duiken kan ik 'The Shellcoders Handbook' aanraden. Er zijn
ook andere boeken zoals Buffer Overflow Attacks (auteur:
James C Foster) alleen hier heb ik zelf geen ervaring mee.

The Shellcoders Handbook beschrijft ook shellcodes die door
de ASCII filters heenkomen zoals SirDice hierboven oppert
(en vele andere)

Bij een bakker zie toch ook voornamelijk mensen die brood komen kopen?
Het maakt mij ook niets uit. En als ik kan zal ik zeker mijn steentje bijdragen. Dit onderwerp valt alleen niet meer onder de "algemene kennis" maar onder de "vergevorderde kennis".
Je hebt niet echt verstand van shellcode nodig. Shellcode's zijn allemaal variaties op dezelfde actie ( execve("/bin/sh") bijv. ). Waar je wel verstand van moet hebben is assembly en een zekere mate van creativiteit om een "standaard" shellcode dusdanig te veranderen zodat er alleen opcodes overblijven die binnen een bepaalde range vallen. Niet onmogelijk en al meerdere malen gedemonstreerd. Als je een beetje gaat zoeken op Internet kom je verschillende varianten tegen.
Dat vraag ik me dus af, of je zelf shellcode moet kunnen schrijven om een stuk code te kunnen analyseren. Zoals ik al zei, het zijn allemaal variaties op hetzelfde thema. Ik weet wat shellcode is, wat het doet, waarom het werkt en hoe. Ik kan, als ik er voor ga zitten, er vast wel een paar maken maar wat word ik daar wijzer van? Het is dan meer zoiets als sudoku, gewoon een puzzeltje. Leuk om de tijd mee te doden.

oh vandaar dat wist ik niet want had dat al getest met c en gdb onder linux
wat overigens intresant was.Want kon de ascii code van hello nergens
terug vinden maar alleen 0x080490a4.

Dus heb toen een simpel programmatje geschreven onder c met:

#include <stdio.h>

int main(){
char msg[] ="hello";
printf(msg);

Wat die met gdb weer gaf gdb:

push %ebp
mov %esp,ebp
sub $0x18,esp
and $0xffffffff0,esp
mov $0x0,eax
msub,eax,esp
mov 0x8048444,eax
mov eax,0xfffffffe8(ebp)
mov mov 0x8048448,eax
mov ax,0xffffffec(ebp)
sub $0xc,esp
lea 0xffffffe8(ebp),eax
push eax
call 0x8048268
add $0x10,esp
leave, ret

Opvallend is dat dat de a.out hello assembly waar alles 8 bites zijn
precies op mov ecx,0x080490a4 na.En in gdb de 8 bytes van a.out
in eens verranders zijn in 16 bit en 32 bit regsiters.Dus verbaasde
me een beetje van het resultaat.

Als je een thread start over shellcode's kun je verwachten
dat er reacties op komen die te maken hebben met
shellcode's. Het zegt verder niets over de kennis van de
gemiddelde security.nl bezoeker. Je kunt namelijk niet zien
hoeveel mensen de thread hebben gelezen, 'm niet begrijpen
en daardoor niet reageren. Vandaar mijn vergelijking met de
bakker. Mensen die geen brood nodig hebben zul je niet in
een bakker aantreffen.

Als je echter kijkt naar het geheel, welke soort vragen,
welke opmerkingen en de hoeveelheid dan kun je wel een
redelijk beeld krijgen van de gemiddelde security.nl
bezoeker. En geloof me, de meeste hebben echt geen idee waar
dit over gaat.

Begrijp me niet verkeerd. Ik keur de post niet af, ik plaats
alleen wat kanttekeningen. Security is een heel breed
begrip. Een firewall beheerder hoeft echt niet te weten wat
shellcode is of wat het doet. En misschien weet hij/zij wel
wat shellcode doet (de gevolgen) maar moet je ook shellcode
kunnen maken om wat tegen te kunnen doen? Ik kan geen
exploits maken en toch vind ik altijd wel een effectieve
manier om ze tegen te houden.

Is deze string nog gevult eigenlijk met 0 bytes ?En is er misschien een
manier in gdb dat je pointer kan terug vinden van de geheugenlocatie?

Strings worden inderdaad afgesloten met een NULL byte in C.
Dat is de kern van het probleem, strcpy zal bijvoorbeeld
stoppen met kopieren als deze een NULL tegenkomt.

Maar als ik char msg[] ="hello"; zou vervangen door char msg[] ="x68x63
x6cx6cx6f"; zou die dan nog afgesloten worden met een null-byte?

Ik zie net Niels z'n uitleg voor ik op verstuur drukte, maar
ik stuur dit toch maar omdat ik Niels zo te zien aanvul op
enkele punten.

Als we uitgaan van jouw C-code:
char msg[] ="hello";
dan gaat het om een standaard ASCII C string.

Een ASCII C string is -bij normaal gebruik- nooit
gevuld met bytes die de waarde 0 hebben, want hij
eindigt met zo'n byte met waarde 0 (als het goed is).

Met jouw bovenstaande C source reserveert de compiler ergens
minstens 6 bytes (5 voor "hello", 1 voor de afsluitende 0 en
mogelijk 2 extra ongebruikte plaatsen om op een veelvoud van
4 uit te komen) in wat uiteindelijk je executable file
wordt, en onthoudt het adres daarvan "in msg". Dat wil
zeggen, overal in de source waar je naar "msg" refereert,
vult de compiler dat adres in. Het is dus eigenlijk gewoon
een label.

In de call printf(msg); heeft printf bij aanvang geen
idee hoe lang de string is; printf leest gewoon byte voor
byte uit het geheugen vanaf het gegeven adres in "msg"
totdat er een 0 gelezen wordt; alles voorafgaand aan die 0
wordt naar je scherm gestuurd.

Overigens vind ik het prima als je assembler en C wilt
leren, maar je bent af en toe wel erg naar de "bekende"
(RTFM) weg aan het vragen. Dat je Nederlands niet perfect is
maakt me weinig uit (zolang ik je kan volgen) maar
slordigheden in sourcecode waar je vervolgens uitleg over
vraagt vind ik nogal klungelig:
Wat "mov mov" is weet ik niet en ik gok dat in de tweede
regel "eax" hoort in plaats van ax. Probeer voortaan zoveel
mogelijk te knippen en plakken vanaf je scherm.

P.S. als je hier een account aanmaakt verschijnen je
bijdragen meteen (je kunt ze dan ook corrigeren - maar doe
dat zo min mogelijk); bovendien halen wij dan niet meerdere
anonieme gebruikers door elkaar.

Je kunt echt
geen zinnig antwoord verwachten als je dergelijke vragen stelt op een
programmeurs forum.

excuse me? Ik denk dat de gemiddelde c programmeur meer over buffer
overflows weet dan de gemiddelde shellcode schrijver die toch een stukje
beperkter werkt. het schrijven van goede strakke code heeft alleszins te
maken met kennis hiervan.

en wat de OT betreft, het heeft mischien op een 6 degrees achtige manier
iets te maken met security (omdat jij graag wilt weten hoe shellcode werkt)
maar verder absoluut niets. Je vragen, zijn met alle respect,
beginnersvragen. Niets mis mee, maar wel relevant voor de discussie of het
wel op zijn plaats is hier. Ik denk dat security en coden 2 heel verschillende
werkvelden zijn, waar ook verschillende denkwijzes voor nodig zijn. Mocht
je alsnog je security kennis willen verbreden door te leren programmeren
[go for it], alle lof voor je, het zal je alleen maar beter maken in je kennis.

Als ik jou was zou ik alleen een goed forum zoeken of ga gewoon naar
usenet (c.l.c.?) en stel daar je vraag. Dit is met alle respect niet meer dan
een prikbord.

Dit is een speculatie die totaal nergens op slaat gezien deze tijd bijna
niemand meer c programeerd.Dit zou je toch moeten weten als "expert"
en wat je reactie van "OT" zou ik nog maar even de topic door lezen voor
dat je weer een oordeel hebt.Wat betreft je conclusie 6 degrees achtige
manier oordeel hier ga ik niet eens op in alleen domme mensen
leggen een link tussen kennis en status. Met alle respect de topic is niet
eens weten hoe shellcode werkt het was "null-bite probleem".

Pardon? Bijna niemand programmeert meer in C? Drie keer raden waar de BSD's en Linux in geschreven zijn.

Jah ok misschien was die een beetje misplaatst.Maar misschien ook
wel intresant als je gaat kijken hoeveel procent er c# of c++ programeerd
en hoeveel c zelfs op bsd of linux operating systemen.

Je was al van repliek gedient, maar ik wil daar nog aan toevoegen dat het
niet over C gaat en ook niet over buffer overflows. Het gaat over shellcode
en specifiek hoe je daarin NULL bytes kan vermijden. Daar ligt de
interesse van gewone programmeurs helemaal niet (code in strings
stoppen is bepaald geen gangbare manier van programmeren) , van hen
moet je geen zinnige antwoorden verwachten. De "experts" zijn de
mensen die het wel gebruiken of kennen, hackers of security
specialisten.

Correctie.. Het gaat hier gewoon om een stukje code.
Shellcode opent een shell (op wat voor manier dan ook).

Wel intresant trouwens waarom software bedrijven hier geen aandacht
aan besteden ik denk persoonlijk wanneer een applicatie
geprogrameerd wordt met c of c++ met een combinatie als inline
assemlby enorm handig kan zijn en de kwaliteit van software omhoog
kan gaan.

Zowel 'Hacking The Art of Exploitation' als de 'Shellcoders
Handbook' zijn boeken die het topic heel goed dekken. Weinig
tot geen andere boeken dekken deze stof van begin tot eind.

Daarnaast staan in 'Exploiting Software: How to Break Code'
ook prima voorbeelden voor het schrijven van veilige code en
wanneer het kan breken.

- Unomi -

Dat zou je geneigd zijn te denken, maar Shellcode heeft tegenwoordig de
betekenis van code die kan worden uitgevoerd terwijl een ander
programma draait. Er wordt niet noodzakelijk een shell geopend. De
payload kan ook iets anders zijn.

http://www.acm.uiuc.edu/sigmil/talks/shellcode/shellcode.html

Bij deze wilde ik nog iedereen bedanken voor de reacties en de
beantwoorde vragen. Ik heb er enorm veel van geleerd en hopelijk nog
andere mensen ook. Thx!!!

Zo zijn er ook mensen die een proxy/content-scanner een
firewall noemen.. Ik doe daar niet aan mee.. Een payload kan
van alles zijn.. Shellcode is iets wat echt een shell
opent.. Shellcode is een payload maar een payload hoeft niet
perse shellcode te zijn.

Dat dit een onderwerp was dat de gemoederen bezig hield,
volgde ik op de voet.
Maar weer ik (hoe kan het anders) kon de Anoniemen niet
meer uit elkaar halen,zeker bij zoveel in getal.
Ik weet de mening nu van SirDice,Erik van Straten,NielsT, Twan Blum.
Ook als je andere onderwerpen erbij haalt,krijg je een beeldvorming
van personen die een nickname gebruiken.
Naar Anoniemen moet je maar raden,zo van is het nu die Anoniem of
zal het die zijn, want dat moet je zoals ik als (aandachtig lezer) maar
raden.
Daarom leest het heel wat prettiger,al is het een nickname, want dan
valt gelijk het kwartje als bijv,SirDice met een stelling komt waar eigenlijk
niemand omheen kan.
Alhoewel ik dit al eens eerder ventileerde,verwacht ik niet dat
er wat verandert,maar niet geschoten is altijd mis.

Dat begrijp ik even niet shelcode kan toch alleen bestaan uit een string
waar van waaruit x moet beginnen?

Dan is de string dus de payload. Ik gok maar wat... ;-)

- Unomi -

Ik was de pooster van de topic en heb net even acount aangemaakt
misschien hopelijk is het zo beetje minder verwarrend.

AV en vulnerability/exploit researchers die ik ken gebruiken het in de
betekenis zoals ik die beschreef in mijn bericht "Anoniem op woensdag
18 oktober 2006 19:51".

Dat is ook logisch. De betekenis van het woord shellcode is gericht op de
bijzondere aard van de code, niet op de actie (de payload van shellcode,
zoals het openen van een shell).

Links:
http://en.hakin9.org/products/articleInfo/78
http://www.sans.org/resources/idfaq/polymorphic_shell.php
http://www.infosecwriters.com/hhworld/shellcode.txt

Bedankt, Koekie.
Schept weer wat helderheid,althans voor mij.

Een payload hoeft niet perse een string te zijn.. Denk aan buffer overflows in bijv. WMF's of ZIP's. Het hoeft ook niet altijd noodzakelijk te zijn om de NULL bytes er uit te vissen wat wel het geval is als de buffer een string als input gebruikt.

Een payload zou bijv. ook een IRC bot of een downloader kunnen zijn, helemaal afhankelijk dus van wat je wilt bereiken. Wel wordt er vaak een (root) shell gecreeerd omdat je dan daarmee volledige controle krijgt om te doen wat je wil (en je kan dat met een paar bytes voor elkaar krijgen).

Zijn deze dan nog wel in assembly syntax geschreven of liggen deze al
op hogere programeer talen als c en java etc.

Bedenk dat C/C++ gecompileerd machinecode oplevert. Assembly is machinecode. Een downloader is nog wel direct in assembly te schijven een IRC Bot vast ook nog wel maar wordt al lastiger. Die schijf je makkelijker in C en compileer je vervolgens.

Java is een verhaal apart.. Dat gebruikt niet echt machinecode maar bytecode. Bytecode is een (kort door de bocht) soort universele machinecode die door de JVM begrepen wordt. Die maakt er vervolgens weer platform afhankelijke machinecode van die uitgevoerd kan worden.

Zo heb ik het niet eens bekeken trouwens maar dan heb je toch als nog
assembly nodig om de machine code te injecteren.Met bv ebp en eip om
de instruction pointer te overschrijven zodat de machine code uitgevoerd
kan worden om eerst een root shel te krijgen?

Je zult een stukje specifieke assembly moeten maken die vervolgens (in)direct naar de code van je payload springt. Wat die payload vervolgens doet is afhankelijk van wat je wil bereiken. De payload zou dan een shell kunnen starten, of een bot, een downloader, etc...

Thx , Het wordt nu een stuk duidelijker hoe het een beetje in elkaar zit.

Je hoeft shellcode niet per se in assembler te schrijven, je mag het ook
direct in machinecode schrijven. Assembler schrijver is meestal wel een
stuk eenvoudiger.

Ik had toch nog een klein vraagje als je dat zou mogen ik ben nu een
beetje shellcode aan het spelen maar geeft die steeds Segmentation
fault aan en weet nu niet of het in de c syntax of machine code ligt.

De code is :

#include <stdio.h>

char shellcode[]=
"xb0xb04xb3x01xb9x94x90x04x08"
"xb2x05xcdx80xb0x01xb3x00xcdx80";

int main(int argc, char **argv[]){
int (*shell)();
(int)shell=shellcode;
shell();
}

Hier geeft die dus een segmentation fault.Nu heb ik al geprobeerd de
laatste xb3x00 te ver vangen na xb3x01 en gaf die het nog steeds.Ook
als ik de exit functie weg laat wat xb0x01xb3x00xcdx80 is blijft die fout
melding weer geven.

Ojah vergeten de xor eax,eax ,xor edx,edx,xor ecx,ecx en xor ebx ebx


Hier staat :
0x8048214 <main > ebp
0x8048215 <main +3> esp ,ebp
0x804821a <main +6> sub 0x8,esp
0x804821d <main +9> and 0xfffffff0,esp
0x8048222 <main +14> eax esp
0x8048224 <main +16> mov 0x8049410,0xffffffc(ebp)
0x804832b <main+23>mov 0xfffffffc(ebp),ecx
0x804832e <main+26>call *eax
0x8048322 <main+28> leave
0x8048330 <main+29>ret

Aan de eerste drie regels te zien is dat toch goed?


Jah vanwege objdump b9 9c 90 04 08 mov 0x804909c,ecx weer gaf.
En heb nog gekeken met (gdb) x 0x804909c <msg> : "hello" <Address
0x804901 out of bounds>.

Thx voor de tip trouwens van boek kijk van de week ff bij de boek handel.

Even iets testen:

Ok.. De code tags doen het :) Gebruik ze a.u.b. dat maakt het allemaal wat leesbaarder... Hmm.. Jammer, ik had verwacht dat kleiner dan, groter dan tekens beter door zouden komen tussen code tags :(

Redactie: kan daar misschien een keer naar gekeken worden? De conversie van (bepaalde?) leestekens loopt af en toe in de soep.. Dat maakt dit soort dingen behoorlijk lastig te lezen..

Dat was me ook al opgevallen wat enorm iritant is met "&" doet die het
ook.