Thiago de Queiroz Posted April 18, 2020 at 02:16 PM Share Posted April 18, 2020 at 02:16 PM Thiago é um engenheiro reverso das antigas e programador há mais de 20 anos em diversas linguagens. Ele vai mostrar uns segredos no processo de debugging, pra encontrar variáveis locais e outros truques que não estão nos livros e só a experiência traz mesmo! Link to comment Share on other sites More sharing options...
dudsdev Posted April 18, 2020 at 03:58 PM Share Posted April 18, 2020 at 03:58 PM Boa Thiago, bem massa cara!! Tem como disponibilizar os conteúdos usados na sua palestra mano ? Link to comment Share on other sites More sharing options...
Thiago de Queiroz Posted April 18, 2020 at 04:18 PM Author Share Posted April 18, 2020 at 04:18 PM Obrigado pela participação! O debugger vc baixa no google, x64dbg. O segundo projeto optei por não disponibilizar por ser um 'ransomware porcamente' funcional rs. Abraço! Projeto00.rar Link to comment Share on other sites More sharing options...
Realizando Sonhos Posted April 18, 2020 at 04:25 PM Share Posted April 18, 2020 at 04:25 PM Boa tarde! Primeiramente Parabéns! Conteúdo top, eu gostaria de saber quando acontece de no caso esta analisando um software e acontece de EXCEPTION_ACCESS_VIOLATION e possivel que tenha sido usado algum patch ou pode ser questão de erros no código? Link to comment Share on other sites More sharing options...
Thiago de Queiroz Posted April 18, 2020 at 04:28 PM Author Share Posted April 18, 2020 at 04:28 PM Obrigado! A violação de acesso pode ser por uma exceção não tratada no software, algum bloco try catch que não foi devidamente capturada. Geralmente você pode ignorar as exceções com shift+f9, ou ir nas opçoes do depurador e repassar essas exceçoes para o software ao invés de tratá-las no debugger. Pode ser também algum packer utilizado. Abraço! Link to comment Share on other sites More sharing options...
Realizando Sonhos Posted April 18, 2020 at 04:29 PM Share Posted April 18, 2020 at 04:29 PM Agora, Thiago de Queiroz disse: Obrigado! A violação de acesso pode ser por uma exceção não tratada no software, algum bloco try catch que não foi devidamente capturada. Geralmente você pode ignorar as exceções com shift+f9, ou ir nas opçoes do depurador e repassar essas exceçoes para o software ao invés de tratá-las no debugger. Pode ser também algum packer utilizado. Abraço! Obrigado! Link to comment Share on other sites More sharing options...
Realizando Sonhos Posted April 18, 2020 at 04:43 PM Share Posted April 18, 2020 at 04:43 PM Eu de volta e quando acontece de um C0000139 (STATUS_ENTRYPOINT_NOT_FOUND). Link to comment Share on other sites More sharing options...
Thiago de Queiroz Posted April 18, 2020 at 04:46 PM Author Share Posted April 18, 2020 at 04:46 PM O programa está com algum tipo de packer? Sugiro esta análise primeiro. Se sim, de preferência fazer o unpacking dele. É um .exe ou dll? Qual seu S.O. ? Shift+F9 funciona? Link to comment Share on other sites More sharing options...
Realizando Sonhos Posted April 18, 2020 at 04:55 PM Share Posted April 18, 2020 at 04:55 PM 6 minutos atrás, Thiago de Queiroz disse: O programa está com algum tipo de packer? Sugiro esta análise primeiro. Se sim, de preferência fazer o unpacking dele. É um .exe ou dll? Qual seu S.O. ? Shift+F9 funciona? 1. R = Ainda não análisei 3. R = É um .exe 4. R = Win10 5. R = Sim Link to comment Share on other sites More sharing options...
Thiago de Queiroz Posted April 18, 2020 at 05:12 PM Author Share Posted April 18, 2020 at 05:12 PM Estas exceções se não forem pertinentes a sua análise não vale perder tempo com elas ? shift+F9 e código pra frente hehehe Link to comment Share on other sites More sharing options...
Fernando Mercês Posted April 19, 2020 at 04:46 PM Share Posted April 19, 2020 at 04:46 PM @Thiago de Queiroz seguem mais perguntas que surgiram no chat: 1.Qual a diferença deste debug para o WinDbg? 2. Este debug tmb converte o código para c? 3. Isso funciona mesmo se o executável for gerado sem as diretivas de debug? 4. Os endereços de memória das áreas de .txt, .data e .rsrc se encontram no cabeçalho PE? Abraço! Link to comment Share on other sites More sharing options...
Thiago de Queiroz Posted April 20, 2020 at 11:22 AM Author Share Posted April 20, 2020 at 11:22 AM 18 hours ago, Fernando Mercês said: @Thiago de Queiroz seguem mais perguntas que surgiram no chat: 1.Qual a diferença deste debug para o WinDbg? 2. Este debug tmb converte o código para c? 3. Isso funciona mesmo se o executável for gerado sem as diretivas de debug? 4. Os endereços de memória das áreas de .txt, .data e .rsrc se encontram no cabeçalho PE? Abraço! A diferença básica é que windbg consegue trabalhar a nivel do kernel, debugar drivers, etc, e trabalha-se mais com comandos, enquanto o x64dbg ou o olly é voltado para depurar programas que estão em um nivel diferente, não se tem acesso a drivers do sistema inteiro, e é mais user-friendly ? Se você usar o plugin snowman sim, consegue ver o pseudo código em C. Sim, neste caso não usei diretivas de debug. Sim, desde que não seja um programa packeado, que criaria essa área na memória em tempo de execução e protegeria o seu acesso. No geral sim, no cabeçalho PE. Não tem o número 5. ? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.