Stack buffer overflow

[blackwinner]

Bem lembrado cara! =]
Esqueci de avisar pra salvar o código.

O segundo erro ele não encontrou o arquivo por alguma razão, depois tu pode me mandar uma mp com a msg que aparece no assembler quando você consegue assemblar o programa?
Só pra matar uma curiosidade do porquê desse erro.

E thks, mais tarde eu arrumo o tuto e aviso para salvar o código, me esqueci mesmo disso. \=
Vlw, fuiz.

[blackwinner]

Boa sorte com seus tutos cara :)

Quero ver teu próximo tuto, quanto mais material em portugues sobre o assunto, melhor e eu já vi que tu escreve muito bem.(li o OSI =P)

Só que eu também vou fazer um tuto pra iniciantes em C, sempre foi meu sonho ter um. *-*

Fuiz, até a madruga e um novo capitulo.

[Alucard]

Boa sorte com seus tutos cara :)

Quero ver teu próximo tuto, quanto mais material em portugues sobre o assunto, melhor e eu já vi que tu escreve muito bem.(li o OSI =P)

Só que eu também vou fazer um tuto pra iniciantes em C, sempre foi meu sonho ter um. *-*

Fuiz, até a madruga e um novo capitulo.

ÔÔÔÔÔ tamo aguardando ai..

[blackwinner]

Como eu digo, fuma um e relaxa =P

Symbols são informações de debugging.
Quando um código é "assemblado" ele perde todas as informações do seu código nativo como funções e procedimentos.
É como se nunca tivessem existido, nem suas variaveis nem nada.
As variaveis locais por exemplo ficam guardadas na stack e no processo de assembling elas viram simples endereços e offsets(deslocamento)


Os symbols ajudam por exemplo a saber para onde um programa está indo.
Quando você tem a instrução *call* que "chama" uma função e coloca o endereço da próxima instrução na stack(pro programa saber pra onde voltar depois de executar a tal da função).
call vai chamar um offset qualquer, você veria no debugger assim:

Code Select Expand

call 0x401500 ou call [0x40000 + 1500]
Mas se fosse uma função documentada isso mudaria e o debugger te informaria o nome da função.

Code Select Expand

call [Func]
Não tem nada de mal nisso e os symbols resolvem muitos problemas e poupam boas horas de dor de cabeça.
Essa complicação toda é porque o windbg opera um nível abaixo da maioria dos outros debuggers.

Mas se quiser ter mais informações sobre os symbols, o digo escreveu no blog dele uma capítulo só para isso:
http://www.1bit.com.br/content.1bit/windbg3

é que não da pra explicar só nesse tuto o quanto o windbg é melhor se não você ia ver como ele é muito superior ao olly e aos outros.

Mas para debuggar os novos navegadores que criam processos o windbg é essencial, o olly não consegue se "attachar" a processos que já estão rodando muito bem o que faz ele quebrar o processo do navegador quando tentar fazer isso.(isso não é trap apesar do que muitos/bebados dizem) =P
O windbg faz isso mole.
Isso é só um exemplo, existem muitos outros.
==========================================

O bp é usado pra apontar pra base de um stack frame, mais tarde no tuto vai ter mais informações mas um stack frame tem a ver com o que o compilador faz "por baixo dos panos" que é sempre criar um espaço na stack o suficientemente grande para alocar as variaveis locais.//aka parâmetros
Ele acaba gerando um código assim:

Code Select Expand

push ebp
mov ebp, esp
sub esp, 0x0F
Isso é nomeado de epílogo e acontece sempre antes de uma determinada função ser executada e pode ser maior mas sempre vai ter essa parte.
Depois da função ser executada vem o prólogo dela que é uma correção da stack.
Essas duas coisas tem muito a ver com o tipo de sintaxe de chamada de uma função usada(normalmente stdcall aonde a correção acontece dentro da própria função), ou seja, é "assunto pra mais tarde" =P