Underground [Eagle]

***************************************************
*VOCE NAO EH HACKER, EH APENAS UM FA DA Marisa Monte :)*
***************************************************************

Este documento estah sendo dedicado ao amigo do Onibus
que nunca mais verei que me proporcionou um momento
maneiro com a mina do banco da frente, eh, eh ela mesmo, cabelo
cacheado, bem preto, nariguda, branquinha e completamente,
doida.

Atencao: Texto incompleto, cansei de escrever-lo... duh!

Skinheads inescrupulosos/racistas (a banda podre do movimento
Oi! nacional que nao sabem nem saborear uma boa cerveja,
classe operaria (to brincando ,), white hats, fans da
macarena, can-can e derivados, da florentinha de jesus,
sandy e juni0 e essas musicas de boiolinha nao sao
bem vindos, delete este texto ou viva sabendo que ele nao foi
escrito pra voce, seu podre...

O Toim lah da rua pode le, O Dark_Side e o F3rGO nao pode.

Eh bem vindo a ler esse batido incompleto texto que compilei
pra me distrair:

Fans da Marisa Monte e de todo esse negocio de Jujuba,
chiclete, algu daum doce e manja, meus irmaos black hats que
nao tem nada pra fazer em casa, mulheres gravidas em geral,
deficientes fisicos (como aquele guri bonitim que vi perto do
shoping um dia desses
- O texto eh seu!),
o povo que anda de skate comigo lah no polo e vendedores de
coco no be4ch p4rk... que soh exploitam os linuxes fodoes e
choram quando o server roda w32 (e ainda quer ser chamado de
hacker_)...

Seu zeh buceta, levou uma rolada no cuh pq eh um fanfarrao,
white hat vagabundo...

---=[ Introducao

Nessa segunda parte do tutorial veremos mais sobre exploracao
remota de programas vulneraveis a Stack Overflow sobre Windows
32 bits (0x00000000 jah que dois digitos em hexadecimal
equivalem a 1 byte, e aih temos 8 deles! 4 bytes, 32 bits }:)
nao importando service packs. O conhecimento aqui descrito eh
global, ou seja, o que voce aprenderah neste paper funcionarah
sobre Windows 7, Vista, XP e mais uma infinidade de
plataformas. Para quem nao sabe (Oi! Nice to meet you sou
6_Bl4ck9_f0x6) gostaria de lhes dizer que com o conhecimento
que aqui
serah descrito voce entao estarah mais do que capacitado a
invadir computadores geograficamente distantes, para quem
eh lento: "Em qualquer lugar do mundo", que disponibilizem
falhas em seus programas servidores, como ftp por exemplo,
bastando utilizar em seus exploits, bons shellcodes.
Anteriormente aprendemos um pouco sobre o stack frame, e
tambem vimos alguns exemplos de programas vulneraveis,
nessa continuacao veremos um pouco sobre shellcodes e
entenderemos um pouco mais sobre o famoso b0f Buffer
0verflow (como citei anteriormente) e tambem veremos
alguns "supostos" metodos de protecao contra stack
overflow no windows *por hora*. O texto serah escrito
em uma facil linguagem em ordem a combater a
ignorancia por parte de muitos usuarios leigos que nao
sabem se defender de nos, os maleficos, hackers du
mau e admiradores da Marisa Monte... Linda! :) E...
porque nao tenho nada pra fazer =P To sem TV a cabo
e jah terminei quase todos os meus jogos ;P Se voce nao
quiser continuar a ler porque acha que o tema do texto
estah um tanto quanto "batido", e voce acha que sabe
do que se trata, entao "para de ler" ou
deleta este arquivo... eu, d.u.v.i.d.o =7

---=[ Shellcodes I - Nocoes basicas

Bem, vamos fazer um breve overview da edicao anterior; Na
edicao anterior voce pode ver que fizemos o programa vulneravel
(ou o stack frame montado na memoria do PC remoto) retornar
para uma funcao oculta no proprio programa, o que veremos
nessa segunda parte da serie eh como fazer para o programa
vulneravel rodando no servidor a ser invadido 1) -> baixar
coisas de servidores remotos 2) -> Executar programas
"locais" 3) -> Estabelecer conexoes em computadores remotos e
outras boas funcoes que apenas serao possiveis com o uso de
shellcodes duh!. Bem, voce deve estar se perguntando o que
diabos eh shellcode (que por sinal vc ve algo sobre em 11 de
10 pages hacka). Entao manoh, como sabemos o processador
trabalha em uma linguagem chamada de hexadecimal, todos os
programas executam acoes no sistema depois de compilados...
duh! Claro, mas eles fazem isso atraves dos tais
"opcodes", esse opcodes nada mais sao do que as
instrucoes em hexa. Ta meio dificil eim? Ta achando que to
te sacaneando neh? Relaxa, vamos com calma. Como todos
sabem, quando escrevemos um programa usando a linguagem de
programacao assembly ("nao eh assembler!" putz! O Marcos
tava bebado!) os codigos quando "disassemblados" sao
vistos em assembly puro (a linguagem que voce escreveu o
programa), por que? Isso por que assembly eh a linguagem que
mais se aproxima de linguagem de maquina, ou seja, quando
escreve-mos programas usando 'C' por exemplo, o programa
passa por varias etapas, na hora da execucao as suas
intrucoes sempre sao convertidas em assembly e consequente-
mente em opcodes. O exemplo mais manjado de todos: \x90 <->
NOP NoOperation, essa instrucao eh convertida no OpCode
\x90. Se voce leu um de meus papers sabe pra que serve essa
instrucao. Blz, mas porque falei isso? Simples, quando
ultrapassamos os limites do stack frame que foi montado
na memoria, TUDO EH TRATADO EM HEXA, E INCLUSIVE O
ENDERECO DE RETORNO DEVE ESTAR EM HEXA. Vamos supor que
passamos do endereco de retorno (Voce que leu o paper
anterior sabe do que se trata) com um monte de C's, voce
verah o seu correspondente em hexa (43) no debugger
(pro-grama usado para se procurar falhas em
programas). Usamos a notacao '\x' para especificar
que a constante estah em hexa quando desenvolvemos exploits
em C e outras linguagens de programacao. Entao, tudo que o
processador sabe executar sao opcodes, ou seja,
instrucoes em hexadecimal, quando voce coda um programa
capaz de imprimir uma string usando o printf(), como
"GABBA GABBA HEY!", cada letra dessa string serah
convertida e devidamente alocada na memoria usando a
base numerica hexadecimal. Entao, voce pode pensar:

- "Bem, se todas as intrucoes dos programas que escrevos
sao convertidas em opcodes e esses tais opcodes que
sao realmente executados, entao posso apenas pegar os
opcodes e executa-los separadamente..."

Sim amigo, voce pode!! Entendeu? Nao?! Blz, vamos a outro
exemplo agora. Vou codar uma aplicacaozinha em assembly capaz
de nos mostrar uma caixa de texto contendo uma mensagem.

-- messagebox.asm --

; GABBA GABBA HEY!

include '\fasmw16727 (windows)\INCLUDE\WIN32AX.INC' ; Inclui no processo de compilacao o
; arquivo que contem os parametros
; necessarios para a obtencao do .exe

.code ; Marca o inicio da secao 'codigo' do programa.

start: ; Entry-Point (O programa comeca a ser executado daqui)

invoke MessageBox, HWND_DESKTOP, "6_Bl4ck9_f0x6 says: GABBA GABBA HEY!","Titulo",MB_OK
invoke ExitProcess,0

.end start ; Marca o fim do codigo do programa

-- cut here --

Bem, como voce pode notar inserimos comentario em assembly
usando o ponto e virgula (;). Nao comentei as duas funcoes pro
code nao ficar feio, mas o que acontece eh que quando o prog
chega nessa linha de codigo ele invoca (chama) a funcao
MessageBox(), que no caso recebe os parametros necessarios para
a exibicao da mensagem, que sao, a mensagem em si, o titulo
da messagebox (caixa mensagem) e o botaozinho, que no ca-so
vai ser soh um OK, MB_OK (MessageButton_OK). Mas voce poderia
colocar um MB_YESNO ou alguma outra coisa nesse parametro
soh pra ficar zuando, e dizer pras minas que voce
desenvolve programas pra computador e vende eles para
empresas como a Ivia que criou o internet banking de um monte
de banco como Barclays Bank, BNB, BASA, Bradesco ou a
Lanlink, lah de Fortaleza, seu black hat ;)

Depois ele chama a funcao exit() e sai com o status '0'... :)
Entao, lah no editor tu vai lah em 'Run' e depois vai em
Compile, ou Digita Ctrl+F9. Depois da compilacao do codigo
fonte tu vai ter uma .executavelzinho nomeado como
messagebox.exe, rode ele pra ver a mensagem:

Ta bom, pra que eu quero essa merda? Voce diz. Entao eu
digo, vamo carregar esse exe pra dentro do Immunity.

Bem, na segunda coluna da esquerda para->a->direita voce pode
ver os opcodes, eh isso daih que eh o shellcode :) Tan dam!
Lembra que te dei os toques de que uma ins-trucao em assembly
(terceira coluna) eh convertida em opcode (segunda coluna)
pelo processador? Pois eh, na verdade o processador soh
executa instrucoes em hexa, ou seja, o que estah na segunda
coluna. Se voce nao reparou o endereco de retorno nao
passa de opcodes (e.g. "\xb0\xd9\xed\xb7" 4 bytes em hardware
de 32 bits :). Se voce agrupar alguns desses opcodes
(Correspondendo a alguma funcao) e executa-los, voce
executarah a funcao... Sacow? Ao inves de jogar o executavel
pra maquina remota, o que voce faz e jogar apenas os
opcodes (que executam uma determinada funcao) para
dentro da memoria do PC remoto usando o stack frame montado
na memoria da vitima que nao controla dados que serao
enviados para faze-los serem executados, ou seja, os
opcodes enviados executam as tais determinadas funcoes que
citei. Como voce pode ver acima esses opcodes estao
muito confusos, a compilador organizou as instrucoes em
ordem a facilitar a execucao do software e
consequentemente tornando dificil a extracao dos opcodes
por conta de instrucao que fazem chamadas a
determinados enderecos e que ainda saltam para
determinados locais e que jogam parametros para
a pilha e blah, blah, blah. Soh eh foda que o fasm nao
exporta symbols pra nois ktar
os opcodes usando o gdb.

C:\Documents and Settings\Administrador>gdb
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) symbol messagebox.exe
Reading symbols from messagebox.exe...(no debugging symbols found)...done.
(gdb) q

Gostaria de fazer uma ressalva para nao passar despercebido,
porque sei que a maioria dos kras ignoram completamente esse
banner do gdb, soh observe
que ele foi configurado conforme "i686-pc-mingw32" onde *
http://www.mingw.org
Com o comando symbol ou file seguido do caminho do
executavel, o gdb vai ktar os symbols dessa APP, eh a
mesma coisa que importar ele pra dentro do
debugger.

(gdb) help symbol
Load symbol table from executable file FILE.
The `file' command can also load symbol tables, as well as setting the file
to execute.

(gdb) help file
Use FILE as program to be debugged.
It is read for its symbols, for getting the contents of pure
memory, and it is the program executed when you use the `run'
command. If FILE cannot be found as specified, your
execution directory path ($PATH) is searched for a command of
that name. No arg means to have no executable file and no
symbols. (gdb) q

A opcao -t do objdump mostra-nos o conteudo da tabela symbol,
veja a linha extraida do help (-H):

-t, --syms Display the contents of the symbol table(s)

C:\Documents and Settings\Administrador\Desktop>objdump -t messagebox.exe

messagebox.exe: file format pei-i386

SYMBOL TABLE:
no symbols

Voce pode filtrar a busca, pode procurar por uma funcao oculta
em um programa que voce codou e exportou symbols na compilacao
com a opcao -ggdb do gcc, pra usar como exemplo de retorno
pra aplicacao bugada, bastanto usar o pipe (|) seguido do
find.exe ou grep nos linuxes, algo como:

objdump.exe -t vulnerable.exe | find.exe "hidden_function"

Escrevo essas coisas ae pra vc nao ficar dependendo de uma
unica ferramenta... Escrevi um paper[x] introdutorio sobre
desenvolvimento de shellcode no linux onde voce poderah ver
melhor como ktar opcodes (que serao jogados p/ maquina da
vitima :) no sistema do tio Linus usando o objdump e o gdb
e talz pra katar os opcodes. Os manohs tambem codaram o
objdump, strings e esses outros progs do capeta pra W32,
como voce pode perceber ;p for testing my win-objdump.exe... };P

---=[ Seu primeiro shellcode - Your first shellcode

Blz, vamo mecher com shellcode agora; Bem, nao eh um "oh, que
shellcode hacku", mas eh um shellcode ;P Como voce viu no
paper passado para uma funcao ser exe-cutada o processador joga
os parametros da mesma para uma regiao de memoria
chamada de pilha, ou stack, ou seja, na funcao exit() por
exemplo, voce fornece a ela um argumento (status de saida) que
pode ser '0' (para representar suces-so na execucao do programa)
ou 1 (erro), em 'C' voce escreve lah 'exit(0);' e pronto, o
proprio compilador jah arruma tudo pra ti, mas em assembly
devemos escrever os passos para a execucao do programa, ou seja
"estruturamos" o execu-tavel e mandamos o sistema executar a
funcao que ta dentro do binario. Armamos o trabuco e o
sistema senta o dedo pra nois. "Por que assembly?" pergunta
o orangutango alih no kanto hahah Struck sem vergonha hahah.
Se voce usar a linguagem 'C' quando voce for pegar
os opcodes voce vai ter um pouco de dor de cabeca porque o
compilador embaralha demais as intrucoes e assim
"consequentemente" tornando os opcodes confusos, por essa
rasao devemos usar assembly e pegar os opcodes diretamente do
que nos escrevemos. Entao, devemos usar as instrucoes "push"
seguida do parametro para jogar o argumento de uma funcao
qualquer (por exemplo: exit) sobre a stack, depois que o
argumento dela ta na pilha nos chamamos o endereco que
ela ta armazenada na dll usando a instrucal call (chamar) e
ela "como toda boa funcao" vai obter seus parametros da
pilha em ordem inversa, se essa funcao for exit(),
na sua execucao o programa vai encerrar com o status que tu
jogou na pilha.

Exemplo pratico..:

Como todos sabemos a funca Sleep() dorme, como o proprio nome
jah entrega. Essa funcao recebe como parametro um numero
inteiro que vai dizer o tempo que ela vai deixar o programa
"dormindo" em "run-time", 1000 ms de segundo equivalem a 1
segundo. Veja um exemplo em C.

1) 1rst example coded in C language

-- Sleep.c --

#include
#include // <-- Header que guarda a nossa funcao Sleep();

int main (){

printf ("Dormindo..."); // <-- Mostra essa msg antes do programa dormir.
Sleep (6000); // <-- A funcao Sleep faz o programa dormir aqui.

}

-- cut here --

2) 2nd example coded in assembly language

-- Sleep.asm --

[SECTION .text]

global _start

_start:
mov ebx, 0x7c802442
mov eax, 6000 ; Pausa o programa por 6 segundos
push eax ; Joga o valor de eax p/ a pilha.
call ebx ; Chama/executa Sleep(6000);

-- cut here --

Bem, voce nao precisa ser um mago do codigo para entender esse
code. Na primeira linha voce pode ver que definir o inicio da
secao "text" do programa, essa secao guarda o codigo
executavel do programa, al-guns kras costumam chama-la de
'secao code', mas eh .text mesmo. Eh abaixo dessa declaracao
que voce comeca a escrever o code do prog. Entao, mais
abaixo voce pode ver que setei o '_start:' pra marcar o
inicio desses codigos e talz. Na primeira linha "efetiva" de
codigo voce pode observar que estou "MOVendo/copiando" p/ o
registrador ebx o endereco de memoria que a funcao 'Sleep()'
estah localizada na dll kernel32.dll, que como todos nos
sabemos "sempre eh carregada duran-te a execucao de um
programa normal codado para W32". Mais abaixo vc pode
observar que movo o numero inteiro 6000 para o registrador
eax
e abaixo empurro (push) o valor armazenado nele (6000 :P)
sobre a pilha (local onde os parametros das funcoes sao
jogados para serem pegos na execucao das mesmas) e logo em
seguida chamo (call) o ende-reco de memoria que ta
armazenado no registrador ebx (endereco da Sleep), o
programa entao obtem o parametro da Sleep que determina o
periodo de tempo de pausa "do topo da stack" e temos
uma crianca feliz depois :) Tres ressalvas devem ser
feitas...

1) Sempre insira a notacao '0x' (especificador de constantes em
hexa) antes do endereco de memoria da funcao a ser usada, Sleep
aqui...

2) Sempre que sair com uma mina virgem "nao tente comer ela na
rua".

3) Os enderecos de memoria de funcoes contidas em dlls (obvio)
va-riam para cada novo "upgrade" do winsux e talz, ou seja,
voce pode ter problemas para executar esse prog e ateh
mesmo o shellcode se nao estiver usando o mesmo pacote de
servico que o autor (euzim :) por que o endereco da Sleep pode
nao ser o que eu to usando aqui . (vide proximos capitulos).

Como voce pode observar essa estrutura de assembly nao eh
entendida pelo fasm, mas sim por outro compilador chamado
nasm. Vamos usar ele no Windows pra compilar esse code e
pegarmos os opcodes pra eu poder mostrar pra voces e talz. O
nasm eh um bom compilador assembly, ele
pode apenas pre-processar o codigo fonte e possui algumas
outras bo-as utilidades que veremos (recomendo a leitura
desse texto: [s] <-- antes de proseguir - opcional).

A opcao -h do nasm te mostra um help completo, aqui
filtraremos ape-nas algumas opcoes, que sao:

C:\Documents and Settings\Administrador>objdump -d messagebox.exe

messagebox.exe: file format pei-i386

Disassembly of section .text:

00401000 <.text>:
401000: 6a 00 push $0x0
401002: e8 07 00 00 00 call 0x40100e
401007: 54 push %esp
401008: 69 74 75 6c 6f 00 e8 imul $0x25e8006f,0x6c(%ebp,%esi,2),%esi
40100f: 25
401010: 00 00 add %al,(%eax)
401012: 00 36 add %dh,(%esi)
401014: 5f pop %edi
401015: 42 inc %edx
401016: 6c insb (%dx),%es:(%edi)
401017: 34 63 xor $0x63,%al
401019: 6b 39 5f imul $0x5f,(%ecx),%edi
40101c: 66 data16
40101d: 30 78 36 xor %bh,0x36(%eax)
401020: 20 73 61 and %dh,0x61(%ebx)
401023: 79 73 jns 0x401098
401025: 3a 20 cmp (%eax),%ah
401027: 47 inc %edi
401028: 41 inc %ecx
401029: 42 inc %edx
40102a: 42 inc %edx
40102b: 41 inc %ecx
40102c: 20 47 41 and %al,0x41(%edi)
40102f: 42 inc %edx
401030: 42 inc %edx
401031: 41 inc %ecx
401032: 20 48 45 and %cl,0x45(%eax)
401035: 59 pop %ecx
401036: 21 00 and %eax,(%eax)
401038: 6a 00 push $0x0
40103a: ff 15 7c 20 40 00 call *0x40207c
401040: 6a 00 push $0x0
401042: ff 15 5e 20 40 00 call *0x40205e

C:\Documents and Settings\Administrador>

Bem, como voce leu no meu outro paper
a opcao -d do objdump faz um "dumping" de um executavel e te
mostra as intrucoes nele e talz, nesse caso tu pode ver a secao
'.text' do executavel. Eh que nem no Immunity, tu tem o
endereco da instrucao na primeira coluna, os opcodes na
segunda e as instrucoes em assembly (na verdade o que serah
executado sao os opcodes correspondentes a essas instrucoes) na
terceira.

"\x6a\x00\xe8\x07\x00\x00\x00" 1) 7 bytes
"\x54\x69\x74\x75\x6c\x6f\x00" 2) 7 bytes
"\xe8\x25\x00\x00\x00\x36\x5f" 3) 7 bytes < ----
"\x42\x6c\x34\x63\x6b\x39\x5f" 4) 7 bytes \ __ 7 x 10 = 70 + 2 = 72
"\x66\x30\x78\x36\x20\x73\x61" 5) 7 bytes /
"\x79\x73\x3a\x20\x47\x41\x42" 6) 7 bytes < ----
"\x42\x41\x20\x47\x41\x42\x42" 7) 7 bytes
"\x41\x20\x48\x45\x59\x21\x00" 8) 7 bytes ps: Dois digitos em hex = 1 byte
"\x6a\x00\xff\x15\x7c\x20\x40" 9) 7 bytes
"\x00\x6a\x00\xff\x15\x5e\x20" a) 7 bytes
"\x40\x00"; b) 2 bytes

Esse shelcode nao funcionarah por razoes jah citadas. Soh
agrupei os mesmo para de-monstrar que podem ser usados como
"string" para serem enviados atraves do socket, e que sao
definidos usando a notacao '\x' que especifica que esses sao
caracteres em hexadecimal (como falei). Ah! Vale lembrar que
todos esses programas citados (strings.exe <-- bom pra achar
senhas internas em .exes, objdump.exe) e mais alguns, podem
ser encontrados no diretorio \Dev-Cpp\bin\, porque eles vem
junto com o DEV-C++, inclusive o gdb! Pacotao fudido
que os kras da bloodshed disponibilizam pra nois na page
deles. Em um dos capitulos que se seguem vo ta ensinando ae
pra voces com ktar opcodes correspondentes a uma
determinada funcao (como baixar trojan-servers de servidores
http remotos - gosto de usar o tal do Beast ;) p/ depois
mandarmos eles pelo socket(), e sem null bytes!
Porque como citei no outro texto, quando a memoria acha o
\x00 a mesma encerra o programa e talz, ateh pra usar
strlen() pra ver o tamanho do shellcode nao rola pq
a funcao termina assim que ela acha o null byte (Use
'sizeof(shellcode)', onde "shellcode" eh a matriz ou como
os kras (Vanessa Balbo :) aprendem na faculdade "vetor",
que voce setou no prog.c).

Exemplo?

Se quiser inserir comentarios no deadlisting dos
programas debugados quando vcs forem escrever papers
pra galera ou algum outro tipo de material audio-visual
basta ir com o botao direito sobre a linha q tu quer
comentar e ir ateh 'Comment ;', usando o Immunity e
mais uma leva de debuggers.

---------------------------------

O metodo de exploracao mostrado aqui serah o mais facil de
ser entendido, o que faremos eh, fazer a area 'RET' do stack
frame retornar para a stack (nao fazer nada) e fazer o
retorno desse estado ser executado, nesse caso alguns
NOP's que serao executados (esses que estao na area RET da
chamada a stack) e que consequentemente "andarao" alguns
bytes na memoria ateh alcancar o shellcode que foi enviado
depois. Os dados de variaveis locais sao alocados (onde os
dados que serao usados como "junk", estao) na stack, e
isso significa que fazemos a area 'RET' do stack frame
cair no shellcode com o metodo citado, onde os opcodes
estao, entendeu? eh incrivel! =P Tudo que for mandado
depois do junk vai pra stack (alguns programas nao
precisam de muito para serem quebrados =) Se voce ainda
nao reparou o nome que damos a um monte de opcodes
reunidos eh "shellcode" =P Vale lhes lembrar senhores
que, 'A' eh diferente de 'a' em hexadecimal, portanto
essa"s" letra"s" serao convertidas em seus respectivos
hexas quando em nivel de processador. O macete da
exploracao remota eh esse abaixo.

buffer[256]; <-- Vamos supor que esse seja o buffer na app remota que nos da acesso
ao stack frame montado na memoria por lah...

[*] - Buffer vulneravel que nos da acesso ao stack frame remoto

CMD + Junk + RET + NOP + shellcode/opcodes

Esse esquema eh o mais simples de todos, o CMD faz o servidor
ir para o stack frame que filtra um determinado comando e manda
a resposta (no caso o stack frame que nao faz controle dos
dados que sao passado para a memoria montada) normalmente
"de lah" ,), depois vem o junk, depois o RET que chama a
stack usando call, como todos sabemos a proxima instrucao
apos a instrucao 'call' vai pro topo da stack p/ ser retornada,
no caso o endereco onde os NOPs (NoOperation - Eh executado
um NOP por vez ateh fazer a memoria chegar no nosso shellcode,
nesse caso serao executados 4 nops, 4 bytes) estao
armazenados, esses mesmos NOPs que serao executados e levarao
o sistema a executar nossos bendi-tos opcodes (instrucoes em
hexa as you know :), ou "shellcode". Essa daih ateh uma
porquinha demente entende. Se voce quiser obter o codigo
fonte do servidor vulneravel a overflow, veja a edicao
anterior. Vamos apenas ver a acao aqui. Agora vamos nos
preocupar em obter o endereco de retorno (essa eu nao mostrei
no video[x]).

---=[ Obtendo o endereco de retorno remoto

Bem, algum fresco decidiu ao inves de fazer varias versoes do
windows, ele pensou, porque eu nao faco o mesmo Windows XP soh
que com versoes diferentes? Entao esse mesmo fresco inventou
o que nos costumamos chamar de SP - Pacote de Servico, ou
em ingles -> Service Pack. Porque isso? Simples, um desses SP
(o primeiro), deixa-va o pessoal do hacking muito feliz (eu
por exemplo), entao o que eles fizeram? Tiraram os
principais recursos do 'Windows XP' SP1, tal como utilizacao
do nosso tao amado 'Raw sockets' que nos permite criar pacotes
na unha *incrivel* e talz, como deixar ferramentas como
nmap, ettercap, e snort trabalharem muito bem, os filhos
da puta retiraram os principais atrativos do XP-SP1, entao
criraram o XPSP2 imundo cheio de DEP - Data Execution
Prevention, que nao serve p/ porra nenhuma e que ferra com
alguns games nao patched que tenho aqui em casa, como
Max Payne I e talz. Curto a uffa o XP/SP1, talvez porque
tenha sido meu primeiro OS. Se voce quiser saber qual o teu
service pack digite 'winver.exe' no 'executar'. Para maio-
res informacoes sobre seu sistema manda um systeminfo na
shell, exemplo:

C:\Documents and Settings\Administrador>systeminfo

Nome do host: BLACKMACHINE
Nome do sistema operacional: Microsoft Windows XP Professional
Versão do sistema operacional: 5.1.2600 Service Pack 2 compilação 26
00
Fabricante do sistema operacional: Microsoft Corporation
Configuração do SO: Estação de trabalho autônoma
Tipo de compilação do sistema operacional: Multiprocessor Free
Proprietário registrado: David
Organização registrada: Viper Corp
Identificação do produto: 55274-640-1286551-23267
Data da instalação original: 21/3/2010, 16:15:31
Tempo de ativação do sistema: 0 dia(s), 1 hora(s0, 2 minuto(s), 52
segundo(s)
Fabricante do sistema: CCE
Modelo do sistema: 1AAAA000
Tipo de sistema: X86-based PC
Processador(es): 4 processador(es) instalado(s).
[01]: x86 Family 6 Model 28 Stepping
2 GenuineIntel ~1596 Mhz
[02]: x86 Family 6 Model 28 Stepping
2 GenuineIntel ~1596 Mhz
[03]: x86 Family 6 Model 28 Stepping
2 GenuineIntel ~1596 Mhz
[04]: x86 Family 6 Model 28 Stepping
2 GenuineIntel ~1596 Mhz
Versão do BIOS: 040609 - 20090406
Pasta do Windows: C:\WINDOWS
Pasta do sistema: C:\WINDOWS\system32
Inicializar dispositivo: \Device\HarddiskVolume3
Localidade do sistema: pt-br;Português (Brasil)
Localidade de entrada: pt-br;Português (Brasil)
Fuso horário: N/A
Memória física total: 1.015 MB
Memória física disponível: 613 MB
Memória virtual: tamanho máximo: 2.048 MB
Memória virtual: disponível: 2.003 MB
Memória virtual: em uso: 45 MB
Local(is) de arquivo de paginação: C:\pagefile.sys
Domínio: ARMAGEDOM
Servidor de logon: \\BLACKMACHINE
Hotfix(es): 61 hotfix(es) instalado(s).
[01]: File 1
[02]: File 1
[03]: File 1
[04]: File 1
[05]: File 1
[06]: File 1
[07]: File 1
[08]: File 1
[09]: File 1
[10]: File 1
[11]: File 1
[12]: File 1
[13]: File 1
[14]: File 1
[15]: File 1
[16]: File 1
[17]: File 1
[18]: File 1
[19]: File 1
[20]: File 1
[21]: File 1
[22]: File 1
[23]: File 1
[24]: File 1
[25]: File 1
[26]: File 1
[27]: File 1
[28]: File 1
[29]: File 1
[30]: File 1
[31]: File 1
[32]: File 1
[33]: File 1
[34]: File 1
[35]: File 1
[36]: File 1
[37]: File 1
[38]: File 1
[39]: File 1
[40]: Q147222
[41]: MSCompPackV1 - Update
[42]: KB890046
[43]: KB890859
[44]: KB893066
[45]: KB893086
[46]: KB893756
[47]: KB893803v2
[48]: KB894391
[49]: KB896358
[50]: KB896422
[51]: KB896423
[52]: KB896428
[53]: KB896727
[54]: KB897663
[55]: KB898461
[56]: KB899587
[57]: KB899588
[58]: KB899591
[59]: KB900930
[60]: KB901214
[61]: KB926239 - Update
placa(s) de rede: 3 NIC(s) instalado(s).
[01]: VMware Virtual Ethernet Adapter
for VMnet1
Nome da conexão: VMware Network
Adapter VMnet1
DHCP ativado: Não
Endereço(es) IP
[01]: 192.168.1.1
[02]: VMware Virtual Ethernet Adapter
for VMnet8
Nome da conexão: VMware Network
Adapter VMnet8
DHCP ativado: Não
Endereço(es) IP
[01]: 192.168.1.3
[03]: Atheros L2 Fast Ethernet 10/100
Base-T Controller
Nome da conexão: Conexão local
Status: Mídia desconec
tada

C:\Documents and Settings\Administrador>

Como voce pode ver meu processor tem 4 nucleos, apesar de ser
uma bosta de 1.60 GHz que nao roda nada, nem o Sam Andreas eu
rodo aqui sem adaptador de video... nem slot AGP eu tenho :)
Overclocking rlz - I'm ninja, sabe comeh neh ;)

Lembra que disse no comeco do paper que o conhecimento aqui
eh global? Ou seja, o metodo de exploracao eh o mesmo
pra Windows 7, XP, Windows Vista e talz, porque? Bem,
porque o criterio para sabermos como a stack frame eh
montada na memoria eh a arquitetura de hardware do
sistema, ou seja, fazemos exploits nos baseando pela
arquitetura da maquina, nesse caso minha arquitetura
(e de mais 99 servidores de um total de 100 no mundo,
tambem eheh...}:) eh X86, como voce pode ver lah em acima
(na linha 'Tipo de Sistema'). Minha arch eh "X86-based PC"
ou seja, Personal Computer baseado no X86, mas que merda eh
essa (Voce diz)? Bem isso quer dizer, que quando executo
qualquer programa no meu computador ele eh montado na
memoria de forma similar a todos os outros x86 do mundo
=P Ou seja, possui o mesmo formato de stack frame. Saber
isso eh interessante, voce pode procurar na internet
instrucoes para os processadores X86 (onde o 'X' ao
lado do 86, pode ser um '3' *386* ou '6' *686*) e que soh
funcionam para esse tipo de arquitetura de hardware.
Entao, em maquinas Linux/i186 por exemplo, o stack
frame dos programas *inclusive os vulneraveis a
exploracao remota :)* sao monta-dos de maneira
diferente, ou seja, o stack frame nao eh o mesmo
dos Win/X86 por exemplo (nada que interfira em
insercao de dados em buffers/buracos ;). Esse soh
foi uma pequena nota que achei importante voce
saber, amigo. Principalmente se voce quiser saber como
se explorar stack frames sobre maquinas ro-dando
sobre arquiteturas estranhas, mas sem duvida a
maioria dos processadores (aquela pecinha bonitinha
que voce encaixa na placa mae) eh 386 :) ou seja, o
diagrama que mandei pra voce no ultimo paper
mostrando como um programa eh montado n a memoria
( stack frame) na edicao anterior, vai valer por
"muito", muito tempo, principalmente quando a base
da exploracao eh soh AAAAAAAAAAAAAA...
AAAAAAAA+RETORNO por esse detalhe:

*NAO SE PREOCUPE COM ISSO*.

Justamente porque a base de exploracao eh inserir dados onde o
programa aceitar, ateh ele "crashear". O nome dessa arte eh
"fuzzing", no qual meu amigo Jeremy Brown eh especialista -
Isso nao eh muito facil nao, bem, depende de que tipo de
falha voce quer achar e que tipo de programa que tu ta
"fuzzando", voce pra ser bom nisso necessita antes de mais nada
manjar de C e socket... bah! Outra historia... Entao, repito,
nao encana com esse negocio de saber como eh montado o stack
frame em todas as arquitetura do mundo, nao manoh! ahaha!
Porque sao pe-quenas coisas que diferem de processador para
processador, existem apenas algu-mas mudancas, como por
exemplo, antes dos processadores 80386 os registradores
serem de 16 bits (0x0000 2 bytes, jah que 8 bits equivalem a 1
byte e dois digi-tos em hexa tambem) ou o windows possuir
stack localizada na memoria (di-ferente do linux) em
enderecos baixos e talz, o negocio aqui nao eh complicar,
o negocio eh fazer voce entender pra se proteger ou
invadir, entao let's continue... Esses engenheiros passam
tampo tempo para criar e nois vai lah e explora rapidim
}:) "Pra hacking" o XP SPI eh muito mais fodao. Soh
mete um 'Zone Alarm Pro' nele que ele fica blindado,
esquece essa merda de DEP, isso nao te proteje, falsa
seguranca (Bem, soh eh bom pra avisar =), veja a prova
abaixo:

Primeiramente o firewall do windows pede autorizacao pra abrir
a porta do servico, ateh aih tudo bem, da ateh pra parecer
que o SP II eh seguro, eh soh nao usar um killer.bat (como o
que o royal codou por exemplo) ou emitir um net stop hahaha.

Essa porra eh um protetor ou eh um IDS? duh! ahahah! Isso daih
eh pra vender mais!! Que tipo de protecao deixa o exploit ser
executado pra "depois de explorado" emitir um aviso de alerta?
pff, um usuario comum (as pessoas pra quem escrevo esse texto)
passaria batido por nisso daih, ele nem deve saber o que eh
DEP! Ele fecha a janela sem nem desconfiar que o kra jah ta na
maquina. Eu vou explicar em um dos capitulos esse treco ai e
vou mostrar maneiras mais faceis de se passar por isso
(assim voce saberah se proteger), pra quem eh detalhista (os
hackus profissionais). Entao, use o SP1, ele eh fantastico
"alem de tudo" para estudos de engenharia, se voce estah
cursando algum curso de engenharia, gostaria de recomendar
o ethereal e o XP/SP1, principalmente pra escrever pacotes
usando raw. Benditos sejam os kernel debuggers. Continuo com
o SP1 (da menos trabalho). Entao manoh, cada um desses
pacotes de servicos possuem enderecos de memoria referentes
a APIs estaticos, ou seja nao sao mutaveis, bem vamos com
calma aqui. O que eh uma API, bem, todas as vezes que um
programa eh executado ele carrega junto para a memoria o
que costumamos chamar de dll, que na memoria passa a
ser chamado de modulo, entao, depois que essa tal
de dll eh carregada na memoria o programa entao faz
constantes chamadas a essa regiao da memoria pra
pegar funcoes contidas na mesma, na verdade eh a
parte objeto (obj) do executavel que faz essas chamadas a
dlls (ou modulos), isso nao vem ao caso agora. Entao
funciona assim, os programas possuem intrucoes que
fazem chamadas as dlls que contem tais funcoes (soh pra
ficar mais facil entender), as dlls mandam o kernel
executar determinadas acoes (agora voce entendeu). Entao,
todos os programas "tradicionais" do windows quando sao
executados (carregados para a memoria), carregam junto
com eles tres dlls, sao elas: user32.dll, kernel32.dll e
finalmente a ntdll.dll, mas nao eh regra, tenho varios
.exes que apenas carregam a user32 em run-time, citei o
"mas isso nao eh regra" para voce nao achar estranho
a user32.dll nao ser mostrada em alguns debuggers.
Existe "uma em especial" que SEMPRE SERAh CARREGADA EM
TODOS OS PROGRAMAS, eh a kernel32.dll (portando todo
o procedimento serah apenas baseado nela, OK?). Blz
entao vei, dentro dessas APIs (entendeu? Por que
serah que quando alguem fala "API de socket" se
refere a wsock32.dll? ;) estao contidas muitas
funcoes comuns a muitos programadores e possuem
recursos para a execucao normal do programa (coisa
de Microsoft, nao vem ao caso agora). Bem, como
voce pode observar essas dlls nao fazem parte do
kernel (nucleo) sistema, ou seja, elas precisam ser
carregadas e a partir daih mandam o kernel executar
determinadas acoes (executar as funcoes), como a
execucao da funcao MessageBox() localizada na dll
user32, ou a famosa funcao exit() que estah
"armazenada" na dll kernel32, bem, voce agora deve
estar desconfiando o porque de
sempre serem carregadas na memoria, simplesmente
porque possuem funcoes comuns a programas. Usando
alguns compiladores de assembly como o fasm voce
precisa escrever a linha de codigo que carrega a dll
e alem disso especificar qual a funcao contida nesta
biblioteca/API (eh a mesma merda) que serah carregada.
Veja a citacao da primeira parte do texto.

***** This quote has been cutted of the my latest paper *****
An american version is comming soon

-- quote --

; Importa as API's que contem as funcoes utilizadas no programa

data import

library kernel32, 'KERNEL32.DLL', user32, 'user32.dll'

; Importa as funcoes contidas nessas API's

import kernel32, exit, 'ExitProcess'
import user32, MessageBox, 'MessageBoxA'

end data

-- quote --

Veja que se faz necessaria a especificacao de aliases para
representar as funcoes dentro do programa (section .code
dependendo do compilador =). Entao, um dos mem-bros da Viper
Corp, nosso amigo Dark_Side fodao das trevas e totalmente
l3370... codou um prog capaz de mostrar quais as funcoes estao
contidas em uma determinada dll e ainda eh capaz de mostrar
seus respectivos enderecos de memoria. Essa informacao eh
necessaria para o desenvolvimento de shellcodes como
veremos adiante no capitulo 'Shellcode part II - hostile
security' . Veja abaixo alguns screenshots dessa importante
ferramenta e a baixe no link disponibilizado.

Digite Ctrl+A para importar para o programa uma determinada
DLL, no meu exemplo importei '\WINDOWS\system32\wsock32.dll'
soh pra ver as funcoes que tem nela >:) Nessa API estao
contidas as principais funcoes de socket, tais como:

Funcao Endereco de memoria

connect = 71A92C14
bind = 71A92BF5
closesocket = 71A92C01
recv = 71A92E70
recvfrom = 71A93005
send = 71A92DDD
sendto = 71A92DE9
shutdown = 71A92E0B
socket = 71A92E1B
htonl = 71A92D05
htons = 71A92D12
getsockopt = 71A92EDA
htonl = 71A92D05
htons = 71A92D12
inet_addr = 71A92D1F
inet_ntoa = 71A92D45
listen = 71A92D69
getsockopt = 71A92EDA
getpeername = 71A92C87
getprotobyname = 71A92C9A
getprotobynumber = 71A92CB0
getservbyname = 71A92CC8
closesocket = 71A92C01
accept = 71A92BE7

Agora voce sabe o porque de precisarmos inserir no linker *-l*
essa library *wsock32* usando um de meus programas
preferidos (que nao linka/mescla a parte objeto dos executaveis
com essa API por padrao (obvio)), o IDE mais fodao do mundo,
o DEV-C++, quando vamos codar exploits e essas coisas todas
que mechem com redes remotas e talz :) As funcoes
'getprotobyname()' e 'getservbyname()' e algumas outras
funcoes que voce poderah ver dentro dessa API sao boas
se voce quiser codar um scanner de portas ou
vulnerabilidades "fresco()", quero dizer, se voce quiser que
ele lhe mostre os protocolos e talz, isso eh bom pra quem
ta mechendo com hacking a pouco e que nao sabe que
o http trabalha "normalmente" na porta '80' e talz. O povo
undiground eh meio bruto, jah sabem em que porta roda de-
terminado protocolo, por isso nao codo essas funcoes ae ;)

- "Oooh, ele eh so l337".

Nao se preocupe, voce ainda vai ficar feliz porque ele codou
esse programa, quem sabe nao eh no proximo capitulo..}:)
Observe que alem de mostrar a funcao e o endereco no qual ela
estah armazenada na API/DLL, o prog ainda permite que voce
copie a linha! Eh incrivel Wallace! hahah! Bicha! hahaha!!
Chamo isso de "Programacao Ninja". Mas claro que existem
programas que fa-zem isso pra voce de forma mais rapida,
como o 'arwin', codado por um kra chamado --> Steve Hanna <--> steve.c.hanna@gmail.com - Que tambem eh o de-senvolvedor do
programa odfhex.c (que usaremos para extrair opcodes):

C:\Documents and Settings\David\Desktop>arwin.exe kernel32.dll Sleep
arwin - win32 address resolution program - by steve hanna - v.01
Sleep is located at 0x7c802442 in kernel32.dll

Observe que voce fornece a ele o nome da dll e a funcao que
voce quer saber o endereco (que estah dentro desta dll) e ele
vai lah e te mostra =7 Nesse caso aih eu to querendo saber
qual o endereco de memoria da funcao Sleep e nao sleep ou
sleeP, que estah localizada dentro da kernel32; observe que
nem precisei escrever o PATH da dll porque o local onde a
mesma estah loca-lizada jah se encontra setado na variavel
PATH, portanto soh basta escrever kernel32.dll :) Soh to
mandando esse source pro Wallace nao ficar metido...:)

---------------------------------

Se voce nao quiser depender de nos ( Corporação Víbora ), ou
melhor, dos nossos programas (eh a mesma coisa =) e do Mister
Hanna e quiser usar o [Immunity] ou ateh mesmo o [Olly] voce
apenas precisa importar um executavel qualquer, clicar
sobre o 'E', de 'E'xecutable module ou "modulo executavel" na
interface do pro-grama, ou digitar Alt+E, serah apresentada
uma lista com todas as bibliotecas que contem as funcoes
que voce escreveu no source code ("codigo fonte") que
foram devidamente carregadas pelo "linker" no processo de
compilacao.

Clika no 'E' alih em cima. Depois tu vai ver
esssa lista de APIs que esse prog
que eu importei ta usando as funcoes delas:

Olha soh que coisa, esse prog importou tres de nossas
conhecidas APIs, user32, kernel32 e ntdll.dll, que coisa nao?
Abaixo de 'Name' voce pode ver o nome do modulo (programa
ou dll carregada na memoria), nesse caso o programa que
importei foi o findjmp (que serah usado logo mais).
Existem varias e "boas" informacoes sobre as tais, como o
PATH (caminho indicando onde a .dll estah localizada no
sistema), o nome do modulo executavel (claro) que foi
copiado p/ a memoria na execucao do programa, base,
tamanho, entry e o sal: "VERSION"... Se soh por curiosidade
voce tiver afim de saber quais as funcoes contidas em uma
delas, clica sobre a mesma com o botao direito e segue ateh
'view names', tu vai ter uma lista mostrando o endereco
de memoria da funcao (Dark_Side out!), a secao, o type e
obviamente seu respectivo nome.

Bem, porque dei enfase a "Version"? Simples, eh muito
importante saber a versao de determinada biblioteca, pois como
citei, cada versao possue enderecos estati-cos para as funcoes
contidas dentro desta, no meu caso a versao que utilizo eh a
5.1.2600.2180, mas isso nao eh importante, o que eh relevante
eh esse xpsp_sp2* ao lado da versao. Isso lhe auxiliarah no
desenvolvimento de shellcodes. Copiei a linha, veja:

Executable modules, item 12
Base=7C800000
Size=000FE000 (1040384.)
Entry=7C80B436 kernel32.
Name=kernel32 (system)
File version=5.1.2600.2180 (xpsp_sp2_rtm.040 <-- Observe o Service Pack
Path=C:\WINDOWS\system32\kernel32.dll

Pronto, voce poderah ver quais as funcoes estao contidas
nessa dll e ainda poderah ver seus respectivos enderecos de
memoria. Esses mesmos endereco de memoria na maquina no qual
estou escrevendo este texto serah os mesmos endere-cos de
funcoes que voce tem no seu sistema (se for o Service Pack
II, claro). No metasploit existem modulos de exploracao que
foram codados exclusivamente para determinados sistemas por
conta de vulnerabilidades contidas apenas em servicos
disponibilizados por esses e (claro) enderecos de memoria
estaticos apenas encontrados neste (estamos falando de
stack overflow, por isso se faz necessaria a utilizacao de
um endereco de retorno para o stack frame remoto), como em
versoes do windows 'XP/SP3' em Ingles por exemplo, ou
algum outro idioma especifico. Alguns exploits ainda lhe
permitem a selecao de enderecos de retorno de acordo com
o sistema a ser exploradao, como eh o caso desse
exploit para o dcom abaixo, esse eh um bom exemplo de um
desses exploits:

C:\Documents and Settings\Administrador\Desktop\Wolves' rain\Julia>dcom.exe
RPC DCOM exploit coded by .:[oc192.us]:. Security
Usage:

dcom.exe -d [options]
Options:
-d: Hostname to attack [Required]
-t: Type [Default: 0]
-r: Return address [Default: Selected from target]
-p: Attack port [Default: 135]
-l: Bindshell port [Default: 666]

Types:
0 [0x0018759f]: [Win2k-Universal]
1 [0x0100139d]: [WinXP-Universal]

Como voce pode observar acima, esse exploit permite a
exploracao em dois tipos de sistemas por conta dos enderecos
de retorno que sao encontrados "apenas" :)
nestes, ou seja, os enderecos por ele usados na exploracao
remota, ou seja, esses enderecos de retorno (especificados
pela opcao -r) sao encontrados em todos os sistemas
Windows 2000 ([Win2k-Universal]) e Windows XP Universal, como
voce pode observar em [WinXP-Universal]. O que seria esse tal
de "XP Universal"? Bem, todos os sistemas, nao importanto o
seu Service Pack (mas obrigatoriamente devem ser XP, que
eh derivado do Windows NT) ou seu idioma, podem ser
explorados com esse endereco de memoria: 0x0100139d. Esse
eh um endereco estatico no sistema remoto que serah usado
para retorno

*NO METODO DE EXPLORACAO USADO POR ESSE EXPLOIT* ,

isso eh o chamado *exploit universal* para uma
*falha universal*. Se voce quiser saber como ele trabalha
recomendo que sniffing sobre uma determinada interface de
rede e, quem sabe nao pode entender como a falha ocorre
"soh por isso" ;) Melhor do que ficar fazendo engenharia
reversa nos binarios eh farejar o payload que ele
manda pro servidor remoto. A opcao -p define a porta
remota (a padrao eh a 135), -d o pc remoto, o -t como
jah falei seta o endereco de retorno de acordo com o
sistema a ser invadido e o -l define a porta que sera
aberta no PC remoto e talz, a padrao eh a -l 666, mas
voce pode setar qualquer outra e talz. Se quiser ver
esse exploit em acao veja o video que gravei[6] e
pegue alguns shots no proximo capitulo. Bem,
normalmente quando um exploit nao funciona voce fica
frustrado e fica querendo sua namorada pra chorar no
peito dela ( ah se eu te pego Marisa), isso eh coisa
de bicha! E, uma bem kiddie! Se voce nao sabe como a
falha ocorre como voce quer que o exploit funcione?
Entao, pra evitar isso os manohs que codaram esse
exploit[7] escreveram as possiveis razoes, veja esse
brinquedinho perigoso me frustrando:

C:\Documents and Settings\David\Desktop>dcom.exe -d 127.0.0.1 -r 666 -p 135 -l6

RPC DCOM remote exploit - .:[oc192.us]:. Security
[+] Resolving host..
[+] Done.
-- Target: [Win2k-Universal]:127.0.0.1:135, Bindshell:6, RET=[0x00000666]
[-] Couldnt connect to bindshell, possible reasons:
1: Host is firewalled
2: Exploit failed

C:\Documents and Settings\David\Desktop>

Bem, nao sei o porque de terem escrito a segunda, afinal de
contas se voce passou o scanner em cima da vitima e ele achou a
falha pra voce, obviamente que o server eh vulneravel (deve se
pra deixar o exploit mais organizado/bonitinho). Entao, porque
to explicando essa merda? Quer saber porque os kras escreveram
a primeira (1:) possivel razao de insucesso? Porque ninguem
nessa dro-ga de vida nasce sabendo de porra nenhuma (alguns
kras sao mais inteligentes que os outros, confesso :), voce
nem se quer sabia falar quando era bebe. Entao,
normalmente quando voce escreve um servidor para emular um
servico, como eh o ca-so do fox_server.exe, voce "todo kiddao"
vai lah e ve que o server ta rodando, manda o teu xploit
l337ao e... beh! Fail, entao tu fica puto, xinga todo mundo,
chuta teu PC e fala: "Nao quero mais ser hacker!"
haushaushsu! Entao, voce lembra que tem um firewall
filtrando as portas no sistema remoto, por isso que voce
nao consegue se conectar, o que voce faz? Voce queima o
firewall com packet fragmentation e tenta outra
vez no teu laboratorio antes de fuder com os kras na outra
ponta do mundo :)

Vi um texto a algum tempo no security focus mostrando como:

********************
ACHAR ENDERECOS STATICOS E GLOBAIS
********************

Assim tu sempre vai saber os enderecos que tu vai chamar, esses americanos })

Nem vo procurar o link pq nao to mais ativo, mas vai lah e pesquisa algo
sobre shellcoding, se nao me engano.

---------------------------------

Entao vei, voltando ao lance da API, importe uns dois ou tres
programinhas usando o [Immunity] para observar que essas
dlls sao mesmo carregadas em todos os programas
"normais" }:) do windows, mas uma que sempre serah
carregada eh a kernel32 como eu jah te falei. Aham! Voce agora
vai entender... Bem, se todos os programas pra windows XP/SP1
(por exemplo) carregam essa dll, entao algum servi-dor POP,
SMTP ou ateh mesmo FTP carrega a dita cuja tambem, por eles
sao progra-mas tambem! E daih? Nao sacow? Lembra que te falei
que quando o stack frame remo-to executa o retorno o programa
chama (call) a pilha e nao executa nada? Blz, es-se retorno
serah um endereco que armazena/"executa uma instrucao"
localizada na kernel32, ou seja, o retorno chama a stack e
o endereco onde os NOPs - OpCode \x90, estao vai para o
retorno desse retorno duh!, porque o proximo endereco de-
pois de todas as instrucoes call do mundo =P vai para topo
da pilha/stack pra ser retornado, nesse caso depois que o
prog salta para a stack e nao faz nada =) Vide referencia[x]

Diagrama..:
***********************************************************
+================+
| ABOR | -> CMD
| AAAAAAAAAAAAAA + -> Junk + EBP incluso
| call esp | -> RETURN ADDRESS (O endereco onde os NOPs estao armazenados)
|\x90\x90\x90\x90| serah retornado depois que o prog for para a stack e nao
| shellcode | executar nada, mas farah a memoria executar os NOPs que por
+================+ sinal tambem nao fazem porra nenhuma ateh chegar no addr
do shellcode (endereco vizinho aos NOPs) que nada mais eh
que opcodes que executaram algo do mau, como baixar progra-
mas pra maquina remota, abrir portas para posterior acesso,
adicionar usuario ao sistema, etc, etc, etc... =7

***********************************************************

............................ Yeah!

Tan dam! Se voce nao entendeu, desculpe -> Morra. Se taque pela
janela de um pre-dio de 12 andares com uma plate nas costas
escrito "Sou retardado" talhado a cinzel e a malho. Agora a
pergunta que pode surgir eh: Como pegar o endereco de
retorno? Bem, no meu bom e velho Windows XP/SP 1 (sim amigo,
eh ele mesmo) voce vai lah lista de APIs, da um click com o
botao direito sobre a kernel32 e depois vai ateh a opcao
'Follow entry' (voce jah cai no entry point desse modulo), lah
procura no dead listing referente a esse modulo a instrucao
"call esp" usando a tecla de atalho 'Ctrl+F' (Find
Command - Ache comando), ou mesmo carrega "diretamente"
essa API do diretorio que ela estah localizada no
Windows (\WINDOWS\system32\kernel32.dll). No WinXP II ta
mais facil ainda hahahaha! Lixo inseguro! ahah! F3rGO out!
Voce soh precisa de um programinha chamado 'findjmp'
(que coisa nao?).

*****************************************************
*AGORA VOCE ENTENDEU PRA QUE SER ENDERECOS STATICOS?*
*****************************************************

Todos os programas apresentados descritos neste paper podem ser adquiridos no
hunterhacker...

nasm tut

Falar que alguns shellcodes sao feitos para determinados pacotes de sistemas
justamente por isso. Say that in the next chapter you can obtain some more
examples of the metasploit framework in action

QUE DESENVOLVEM INTERNET BANKING PARA BANCOS, COMO * * E *
eU QUERIA SABER COMO UM DESSES FUNCIONA :)

http://www.hunterhacker.xpg.com.br/mirrorz/ivia/pra-quem.htm

Criar um servidor novo e mandar todos os meus files pra lah...

Desabilitar DEP (vi um tutorialzim bom), da maneira mais facil e da mais dificil
tambem. Ensinar como ela funciona, ensinar sobre o tal do canary, mostrar como
funciona os protetores como stack guard e fazer um bonzim (tambem ensinar como)
passar pelo stack guard e talz. Pro proximo capitulo da zine: GNU PGP e talz, W32
tambem. + little endian big endian. ah, nao esquecer de falar sobre o tal do CEH
(or something like that) e como passar pelo tal do cookie protector de stack ou
algo assim que eh inserido nao sei onde.

Gerenciamento de pacotes e talz (one more chapter).
Bem, pra achar os bugs voce precisa manjar em fuzzing, pra mecher com fuzzing
Jeremy Escreveu uns textos ateh bons sobre fuzzing[x], va da uma olhada.
No krakowlabs tem uns fuzzers maneiros, ele tem uns fuzzers restritos bons
tambem (priv8 ;)

md5sum (muitas vezes voce ver + packetstorm e talz) + pgp + uuencode

batch script + Explicar o que eh base e essas coisas todas de type, export,
sections, import e talz. + \r\n\r\n no exploit

XP, que eh derivado do Windows NT + mais sobre o dcom.exe

Detectando invasoes (na e-zine tambem).

veja o video no qual to mostrando o utilizacao desse exploit + dicionario +
links que soh o cao...

Socket em asm + shellcoding no tuto e talz =)

Explorando com o metasploit + tuto + vai pro pdf e talz - Viper Corp collection 0x03

Criar um prog que criptografa a saida de minha placa de rede ehehe VIXI!!!!...
Engenharia fudida!

SMTP header for fun and shot.
shelcode-tester
Usando o GDB

(gdb) help symbol + (gdb) help file

vi um texto sobre analise de pacotes ICMP
no I-sec que ta rulez,

Com direito a pgo public key bloc and file uuencoded.

O servidor verifica os primeiros bytes vindos atraves do
socket e pula para uma funcao interna according to, ou
melhor, para o stack frame interno que possuem funcoes
de filtragem daqueles tipos de comandos e passar os dados
grandes pra dentro de sistema, hhuhuhu ,)

[]'s

by

6_Bl4ck9_f0x6 - Viper Corp Group