Felipe.Silva

Tenho uma ferramenta em Bash no meu GitHub chamada 'new' que pode ser útil para gerar executáveis assim, sem precisar de modificar "na mão". No repositório tu pode olhar a pasta "templates" que um deles é o bin-elf64. A sequência de comandos ficaria assim: $ nasm tst.asm -o tst.bin $ new bin-elf64 file=tst.bin out=tst $ chmod +x tst $ ./tst Um "Hello World!" fica com 171 bytes. Mas um detalhe: Menor não necessariamente significa melhor. Isso aí é só de brincadeira, o executável não vai ficar mais eficiente porque você "capou" ele. Mas como passa-tempo é válido.

A questão é que usando um registrador de 64 bits, a instrução divide o valor contido em RDX:RAX pelo valor passado como operando. Considere que RDX são os 8 bytes mais significativos do valor, e RAX seriam os 8 bytes menos significativos. Simplesmente zerar RDX traria um resultado incorreto se o número em RAX fosse negativo, o certo seria fazer um sign-extend e a instrução CQO faz isso para você: mov rax, 2345 cqo ; RDX:RAX = sign_extend(RAX) idiv rbx

Colega, pelo que pesquisei aqui isto é uma instrução intrísseca do compilador do Visual Studio (Microsoft). Tem muita coisa em C que não é padronização da linguagem mas sim de alguma implementação específica, esta é uma delas. https://docs.microsoft.com/pt-br/cpp/intrinsics/sidt?view=vs-2019 Se você usa o GCC, e suponho que sim, você pode usar Inline Assembly para isso. (outros compiladores também suportam Inline Assembly, mas com sintaxe diferente) Vou deixar um exemplo: #include <stdio.h> #include <inttypes.h> typedef struct idtr_s { void *base; uint16_t limit; } idtr_t; inline void sidt(idtr_t *idtr) { __asm__ ( "sidt %0" : "=m" (idtr) ); } int main(void) { idtr_t idt; sidt(&idt); printf("%p, %" PRIu16 "\n", idt.base, idt.limit); return 0; } Detalhe que o uso de uma inline function demanda que você ligue a otimização de código na hora de compilar. Tu pode por exemplo fazer assim: $ gcc -O2 tst.c -o tst Ah, uma pequena nota, sem querer atropelhar o autor. Mas o uso de DWORD para 'base' não está tecnicamente correto. Ele está assumindo que o tamanho do dado será necessariamente 4 bytes, mas isso só é verdade se o programa não estiver rodando em modo de 64-bit. Por isso usei um ponteiro void no lugar. EDIT: A instrução SIDT não carrega a IDT, carrega o IDTR que é um registrador que armazena estas informações sobre a IDT. "base" no caso é o endereço inicial de onde a IDT está.

Muito maneiro. o/

$ gcc jonth.c -o test.c -E Eu usei -E do GCC para ver o conteúdo expandido. Depois procurei pelo texto "main(" no arquivo de saída e encontrei. Aproveitando das diretivas de linha que o GCC insere, eu vi que o conteúdo estava expandindo no arquivo /usr/include/X11/Xlib.c na linha 3889. Nesta linha contém a seguinte declaração: extern XIM XIMOfIC( XIC /* ic */ ); O `#define` da linha 5 seta o macro de nome XIMOfIC. Perto do final desse macro nós temos um macro "O" ali. Veja em negrito: Acontece que aonde tem esse "O" é expandido o conteúdo do macro B. Pelo visto um macro que expande para o nome de outro macro dentro de um header file, é expandido mais uma vez. Parece que há uma repetição do pré-processamento. Para testar isso eu fiz o seguinte: // Arquivo tst.c #define B X Y #define X 5 #define Y , c = 3 #include <stdio.h> #include "h.h" int main(void) { printf("%d, %d\n", b, c); return 0; } // Arquivo h.h int b = B; E funcionou. No arquivo "h.h", B expandiu para o conteúdo de X e Y em sequência. Formando: int b = 5, c = 3; E se a gente voltar para o primeiro `#define`, a gente nota que a declaração do macro "O" é feita como uma sequência de letras, onde a primeira é B. Seguindo essa "corrente" os macros vão expandindo um atrás do outro. Isso é brilhante hahaha.

Não, eles não fazem a mesma coisa. O código em Assembly é para 32-bit e faz uma chamada para a syscall write do kernel Linux. Já o código em C é compilado para 64-bit e faz uma chamada para a função printf() da libc. Os código são diferentes porque são diferentes. Além disso C é uma linguagem de alto nível, então é de se esperar que haja mais código no executável do que o programador consegue enxergar. C ainda é minimalista, mas experimenta ler o código de outras linguagens de alto nível para ver a diferença absurda. Ah, e só porque o resultado é o mesmo não quer dizer que esteja fazendo a mesma coisa. Vou ilustrar com números: 4 + 5 = 9 18 / 2 = 9 Só porque as duas operações resultam em 9, não quer dizer que façam a mesma coisa. Linguagem de programação é muito mais do que você digita, e mais ainda do que você pode ver no terminal.

Concordo plenamente. De qualquer forma, foi uma excelente descoberta de sua parte.

Sim, eu quero vê-las e agradeço as críticas. Sobre o binário, é que eu vejo muitas pessoas que não são capazes de separar o conceito do sistema numérico binário do próprio código de máquina em si. Por exemplo, já vi gente vendo um número em binário de uma letra ASCII e falando que era "o código de máquina da letra A". Outros já vi afirmando que binário é uma criptografia. Por isso eu tentei deixar claro que código de máquina é uma coisa, e o sistema numérico binário é outra. Embora o código de máquina seja fisicamente em sistema binário. E o mesmo vale para hexadecimal, já vi pessoas achando que código de máquina é hexadecimal porque abriu um binário em um editor hexa e viu os bytes em hexadecimal... Sobre o resto, vou revisar. Muito obrigado.

Galera, estou escrevendo uma série de artigos no Medium explicando o básico do código de máquina da arquitetura x86. (desconsiderando o modo de 64-bits e outras tecnologias que eu não estudei) Essa informação pode ser útil para entender melhor o Assembly da arquitetura e também se alguém, por algum motivo aleatório, quiser desenvolver um assembler, disassembler, emulador ou qualquer outra ferramenta que exija esse conhecimento. No final de cada artigo tem um link para a próxima parte, mas mesmo assim irei deixar todas as partes indexadas aqui. Quando eu escrever novas partes irei comentar aqui no post. Código de máquina x86 — Parte 0 | Introdução Código de máquina x86 — Parte 1 | Conhecendo Código de máquina x86 — Parte 2 | Opcode Código de máquina x86 — Parte 3 | Prefixos

Fui o único que votou no projeto Bumerangue. ☹️

Sim, falhas do tipo continuam sendo encontradas. E sempre serão, não acredito que um dia haverá um sistema 100% seguro.

Não sou lá um especialista no assunto, mas enquanto não aparece uma pessoa mais qualificada você vai ter que se contentar com o que eu sei. rsrsrs :P Antes de mais nada esse método é para atacar redes WPA2-PSK, que é um dos métodos de autenticação que uma rede WPA2 suporta. Geralmente esse método de autenticação mais simples é usado em residências. Empresas usam o outro método porque é mais seguro. (não sei como o outro método funciona, nem pergunte.) O "método tradicional" para quebrar uma senha de uma rede WPA2 segue três passos simples: 1) Monitorar o tráfego no canal em que se encontra a rede alvo. 2) Esperar pacientemente que alguém se conecte a rede. Quando o handshake é capturado é o "sinal" que alguém tentou se conectar a rede. 3) Quebrar a senha por força bruta. (se você pegou o handshake de uma conexão falha vai perder tempo :P ) Obs.: O passo dois pode ser acelerado forçando a desautenticação de algum dispositivo forjando pacotes. Mas isso não é importante para o assunto. Como eu disse eu não entendo muita coisa, mas o ataque de força bruta acontece no pacote de comunicação do 4-Way Handshake. Basicamente ele tenta "simular" a criação desse pacote usando uma chave X como se fosse a senha de autenticação. Se o resumo do pacote bater com o resumo do handshake capturado, então quer quiser que a senha é a correta. O novo método apresentado no artigo elimina a necessidade de capturar o handshake. (essa é a parte mais problemática) Isso porque ele descobriu que esse tal de PMKID é gerado usando o algoritmo HMAC-SHA1. Onde é usado como chave o PMK* e como dado a concatenação da string "PMK Name", o MAC do AP(o roteador neste caso) e o MAC do dispositivo que está se comunicando com o roteador. Ou seja: "PMK Name" + MAC_DO_ROTEADOR + MAC_DO_DISPOSITIVO Tudo isso concatenado é "hasheado" usando algoritmo HMAC-SHA1 e usando como chave o PMK. Onde o "PMK" nada mais é que a senha configurada para a rede WiFi. O MAC do roteador e do dispositivo pode ser capturado facilmente monitorando a rede... Percebeu onde se encontra a vulnerabilidade do sistema? Dessa forma dá para descobrir facilmente o dado, só o que não temos é a chave utilizada. (a senha da rede WiFi) Ou seja, isso abre uma porta para fazer força bruta... É só usar o algoritmo HMAC-SHA1 no dado com senhas diferentes... Se conseguir o mesmo PMKID significa que usou a mesma chave... Logo, você conseguiu senha da rede. ^-^

Hehehe, comigo foi o contrário. Eu já sabia Assembly quando comecei a aprender C, aí eu compilava código em C e lia em Assembly para entender melhor o funcionamento do executável gerado. O próprio GCC oferece opção para apenas compilar o código, sem montar nem linkar ele. Dessa forma é possível ler o Assembly. Só usar: $ gcc programa.c -o programa.asm -S # Com sintaxe da Intel $ gcc programa.c -o programa.asm -S -masm=intel Fica a dica para quem quiser dar uma olhada. É interessante também usar o objdump para ver o programa depois de linkado. Opção -d do objdump faz ele disassemblar a seção de código.

@Leandro Fróes. Posso ter interpretado errado o texto dele, mas eu acho que não era ASLR. Ele disse que quando clicou "RUN" ele foi para o endereço 401000. Eu não sei o motivo e nem sei do que se trata, mas quando eu abro um executável no EDB ele também executa um código antes do entry point. Fica na região de memória do ld-2.26.so então eu imagino que seja alguma inicialização do S.O. Deve ser o mesmo caso no Windows. Mas como eu já disse eu não sei direito do que se trata. Inclusive eu queria perguntar aqui sobre isso e me esqueci.

Olha eu vou te dar a "dica", mas você não vai gostar. 1) Você tem experiência com desenvolvimento de drivers? Se não, começa estudando isso. 2) Depois que ter pelo menos alguns meses de experiência com desenvolvimento de drivers, começa a estudar engenharia reversa. O curso CERO do Papo Binário é um bom começo... Eu imagino que ele já esteja completo quando você terminar de estudar sobre drivers. 3) Após o CERO aprenda Assembly. Mas cuidado para não aprender Assembly da arquitetura errada, existem várias linguagens Assembly... 4) Sabe redes? Se não, estude. Se sim, estude mais ainda. 5) Depois de estudar engenharia reversa e Assembly por pelo menos 1 ano e ter bastante conhecimento sobre redes, você já deve estar apto a tentar fazer a engenharia reversa no driver. Eu diria que ao todo, somando estudos e "mão na massa", você vai levar em torno de 1 ano e meio a 2 anos para encontrar a falha e corrigir ela. Isso se você conseguir, não é algo 100% garantido. Você pode fazer tudo isso ou reportar a falha e esperar uma atualização de correção. Você decide, não quero mandar na sua vida. 😙