Jump to content

Fernando Mercês

Administradores
  • Content Count

    628
  • Joined

  • Last visited

  • Country

    Brazil

Community Reputation

0 Neutral

Personal Information

Recent Profile Visitors

7,699 profile views
  1. Fernando Mercês

    MBLive v1

    Depois do sucesso da MBConf, teremos nossa primeira MBLive! hehe O objetivo é trocar uma ideia informal com nossa comunidade. Colá lá: https://www.instagram.com/mentebinaria_/ 🙂
  2. Fernando Mercês

    8.8 Solidaria

    until
    8.8 Solidaria, forma parte del programa de actividades organizadas por 8.8 Computer Security Conference, un evento 100% técnico y académico, que tiene como principal objetivo compartir información, democratizar el conocimiento y crear comunidad. https://welcu.com/chile-green-events/8dot8-solidaria
  3. Tem vários caminhos. O primeiro que me vem à mente é criar um buffer e usar a fread() para ler. Usando fopen, fread, fwrite, etc deixará seu programa portável, mas se a intensão é trabalhar em Linux e seus amigos somente, pode usar open(), read(), write() etc. Na aula 18 do curso Programação Moderna em C eu falo sobre como ler os bytes de um arquivo PE (mas pode ser qualquer outro, claro): Mas I/O é custoso. Talvez seja interessante você usar funções que leiam o arquivo inteiro para a memória e depois ler de lá. Neste caso eu não sei se tem algo portável, mas na libpe por exemplo, o @jweyrich optou por usar mmap() e a gente compila pra Windows usando o Cygwin. Mas se estiver falando de C++, aí eu não sei. Talvez o @fredericopissarra? Abraço!
  4. Nem imaginava que estas instruções funcionariam @Lucas Campelo! Sério mesmo? Não precisou adaptar nada? Abraço!
  5. Salve! Obrigado pela sugestão! A gente tá com bastante dificuldade em sacar a grana que arrecadamos no YouTube para as doações que rolaram na MBConf, mas assim que a gente conseguir, vamos considerar isso sim. @Paulo Arruzzo o que acha? Conseguimos replicar as categorias de apoio que já temos lá? Abraços!
  6. Boa tarde! Seria legal reportar o problema no Github dos caras. É difícil a gente conseguir confirmar isso... teria que analisar. De qualquer forma, no nosso curso é recomendado o PE Tools? Eu acho que não conhecia esse toolkit, não lembro de ter recomendado... rs Abraço!
  7. Show! Tudo é possível. rs Mas pelo que entendi você quer parar em todas as chamadas à funções externas, certo? Bem, nunca tentei para em todas. Daria pra fazeer pela aba "Symbols", mas como é payload, pode ser que esteja vazia. Parece um pouco de exagero, mas uma ideia é no Trace -> Trace into você colocar uma condição (Break Condition) onde o registrador EIP esteja fora da faixa das seções do binário. Por exemplo, num binário assim (Memory Map): Como as seções dele estão na casa dos 0x400000, a condição eip > 0x500000 vai fazer o x64dbg parar quando uma função externa for chamada. Você tem a faixa de endereços do teu payload, então é só adaptar. Mas eu ainda acho que monitorando as chamadas, seja com trace, logando ou com API Monitor ou outro e depois breakando em cada uma delas é mais negócio. Sabendo em qual chamada você quer parar, é só ir na Command Bar do x64dbg (lá embaixo) e digitar "BP CreateFileA" por exemplo. 😉 Abraço!
  8. A partir daí, eu acho que eu deixaria o payload rodar e monitoraria as chamadas (API Monitor, drltrace, etc) pra ver que funções do Windows o payload chama. Depois você pode voltar ao x64dbg e por breakpoint nelas para analisá-las. Acho mais importante/fácil que debugar todo o código. Outra opção é usar o trace do x64dbg pra você ver o caminho de códigos (saltos) que o payload executa e não perder tempo analisando junk code. O @Thiago de Queiroz mostrou como usa o trace na palestra dele na primeira MBConf. 😉 Abraço!
  9. Na verdade eu quis dizer que humanos trabalham tanto com números quanto com texto. 😉
  10. Boa, @HelderPereira! Que bom que tá curtindo. Já corrigi o texto lá e aproveitei pra subir umas mudanças que estavam planejadas. 😉 Abraço!
  11. Eu nem criei um projeto, @Matheus Miguel. Criei os dois arquivos e compilei com a linha de comando. 😉
  12. Interessante... eu nunca tinha visto esse padrão de nome. Não me parece o name decoration / mangling normal de C++. E mesmo assim o extern "C" deveria impedir a decoração, claro, já que C não tem sobrecarga de funções. Será que não há uma função com o mesmo nome nessa pch.h? Achei uma discussão longa de um usuário com um problema muito parecido, inclusive ele cita o mesmo padrão de nomes aqui. Bem, eu iria com baby steps, saca? Compila a menor possível, checa os exports e, se tiver tudo certo, vai crescendo o código e checando os exports da DLL compilada, até encontrar o problema. Por exemplo, o código abaixo foi sem problemas aqui: // user_force.h int _stdcall USER_FORCE(int a, int b); BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; } // user_force.cpp extern "C" __declspec(dllexport) int _stdcall USER_FORCE(int a, int b) { return a + b; } Compilação: c:\Users\admin\Documents>cl /LD user_force.cpp Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. user_force.cpp Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. /out:user_force.dll /dll /implib:user_force.lib user_force.obj Creating library user_force.lib and object user_force.exp Checagem dos exports: c:\Users\admin\Documents>dumpbin /exports user_force.dll Microsoft (R) COFF/PE Dumper Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file user_force.dll File Type: DLL Section contains the following exports for user_force.dll 00000000 characteristics 5ECD966F time date stamp Tue May 26 23:21:35 2020 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 00001000 USER_FORCE Summary 3000 .data 1000 .pdata 2000 .rdata 1000 .reloc Daí seria ir acrescentando o código e recompilando toda hora, até achar o problema... Mas pode ser que alguém saiba exatamente o que ocorre aqui e ajude também. Abraço!
  13. Você tem algum serviço escutando na porta 80 no seu host? Porque você tá enviando o pacote, mas se não tiver ninguém pra responder, não vai ter resposta mesmo. 😉 Você não falou em que SO está, mas se for Linux/macOS, experimenta escutar com o netcat, numa porta alta pra não precisar de root, por exemplo: $ nc -vlp 3000 E depois tenta enviar seu TCP SYN pra ela usando o Scapy (dport=3000 no teu código). Enfim, basicamente você precisa falar com uma porta que esteja aberta (haja algum serviço escutando nela). Abraço!
  14. De nada 🙂 O código-fonte (à esquerda) é em C e pode ser compilado pra 16, 32 ou 64 sem problemas. Já o exemplo do código compilado à direita tá em Assembly e o fato de ter esse ".model small" acredito que só faça sentido em programas de 16-bits sim, mas aqui tem uma explicação mais completa: https://stackoverflow.com/questions/47252660/what-is-meaning-of-model-small-in-8086-programs Abraço!
  15. Isso é código de 16-bits. Nunca usei o MASM para tal, mas esse cara dá algumas dicas pra fazer funcionar: https://blog.fpmurphy.com/2017/11/16-bit-intel-assembly-on-windows-10.html - perceba que ele só rodou o binário no DOSBox (um emulador de DOS), mas compilou no MASM 6.14 e 7.10 (com a opção /omf). Enfim, dá um trabalhinho mas vai. 😉 Abraço!
×
×
  • Create New...