Ir para conteúdo

Leandro Fróes

Membros
  • Total de itens

    17
  • Registro em

  • Última visita

Reputação

4 Neutral

1 Seguidor

Sobre Leandro Fróes

Últimos Visitantes

117 visualizações
  1. Questione!

    Olha... não posso chamar de técnica kkkk Depois de ter essa linha de pensamento de cima comecei a achar bem chato ficar vendo sobre hacking e essas coisas, sempre faltou algo e infelizmente tem muita gente pagando de que sabe algo hoje em dia (principalmente no youtube). Coloquei na minha cabeça o que quero e escrevo constantemente o que devo estudar para chegar lá, os requisitos mínimos e me esforço para não sair daquilo até aprender legal. Tem dado certo!!
  2. Questione!

    Obrigado pelo feedback! Com certeza o foco é um grande problema. Hoje em dia tem muita informação solta e manter uma linha pra isso é bem complicado, pelo menos pra mim foi um grande problema por muito tempo kkkk
  3. Formato PE - 3

    Boa tarde pessoal!! Acharam que o PE ia abandonar vocês?? Que nada rapaz, só uma pausa do feriado msm pra galera dormir mais =D Se me permitem, gostaria de fazer uma observação que se aplica nos estudos: Estou colocando os campos da documentação aqui assumindo que sejam sempre verdadeiros, mas sabemos que não é bem assim. Este é o padrão que o Windows segue, mas quando o assunto é (in)segurança padrões são meio problemáticos(?!). Como o foco aqui é simplesmente apresentar o formato vou focar justamente nisso e deixar possíveis problemas/melhorias/macumbas para o futuro, depois que todos nós (e eu estou bem incluso nisso) entendermos tudo Bom, vamos ao que interessa? Aqui faremos o uso de mais uma ferramenta, um debugger pra ser mais preciso. Usarei o OllyDbg na versão 2.01, mas fique à vontade para usar um de sua preferência. E o que é um debugger? Resumindo é uma ferramenta com a capacidade de interpretação dos opcodes, transformando-os em linguagem assembly (disassembly) e permitindo interação com o binário compilado. Lembram da estrutura IMAGE_NT_HEADERS? typedef struct _IMAGE_NT_HEADERS { DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER OptionalHeader; } IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS; No post passado vimos o FileHeader, agora iremos para a IMAGE_OPTIONAL_HEADER que segue o seguinte formato segundo a documentação: typedef struct _IMAGE_OPTIONAL_HEADER { WORD Magic; BYTE MajorLinkerVersion; BYTE MinorLinkerVersion; DWORD SizeOfCode; DWORD SizeOfInitializedData; DWORD SizeOfUninitializedData; DWORD AddressOfEntryPoint; DWORD BaseOfCode; DWORD BaseOfData; DWORD ImageBase; DWORD SectionAlignment; DWORD FileAlignment; WORD MajorOperatingSystemVersion; WORD MinorOperatingSystemVersion; WORD MajorImageVersion; WORD MinorImageVersion; WORD MajorSubsystemVersion; WORD MinorSubsystemVersion; DWORD Win32VersionValue; DWORD SizeOfImage; DWORD SizeOfHeaders; DWORD CheckSum; WORD Subsystem; WORD DllCharacteristics; DWORD SizeOfStackReserve; DWORD SizeOfStackCommit; DWORD SizeOfHeapReserve; DWORD SizeOfHeapCommit; DWORD LoaderFlags; DWORD NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; } IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER; Grandinho, né? Bem, aqui temos o nome “opcional”, mas na verdade toda imagem possui um cabeçalho deste (entenda imagem como um programa carregado em memória). Este header possui informações importantes que ajudam no carregamento e execução do nosso executável. Magic A identificação do tipo de imagem é feito deste campo. Aqui podemos ver se ela é um PE32, PE32+ ou uma ROM image. Os bytes no caso seriam: 0x10B - PE32 0x107 – ROM Image 0x20B – PE32+ PE32, certo? O zero da esquerda é omitido ali em cima, mas ainda sim são dois bytes. MajorLinkerVersion e MinorLinkerVersion Simplesmente um byte indicando a maior versão do linker e outro byte indicando a menor. Sempre que leio algo sobre PE dizem que este campo não é lá essas coisas, eu não faço ideia da versão do meu linker, por exemplo, então se alguém souber uma utilidade interessante para este campo pf me ajude Converta ai pra decimal rapaz!!! SizeOfCode DWORD indicando o tamanho, em bytes, da seção .text (ou .code) ou a soma de todas essas seções se houver várias seções de texto Entenda que quando falamos que a seção se chama .text é simplesmente um nome, uma convenção para o loader as identificar. SizeOfInitializedData DWORD indicando o tamanho, em bytes, da seção .data ou a soma de todas essas seções se houver várias seções de dados inicializados. SizeOfUninitializedData DWORD indicando o tamanho, em bytes, da seção .bss ou a soma de todas essas seções se houver várias seções de dados não inicializadas. AddressOfEntryPoint Aqui temos uma DWORD que é o endereço do Entry Point (um RVA para ser mais exato) relativo ao Base Address que indica (pelo menos deveria) o começo do programa em memória. Para executáveis este é o começo do programa, para drivers é a função de inicialização e para DLL's é um campo opcional. Caso não haja E.P o campo será zero. Olha lá o danado no Debugger . Note que há um número somado ao nosso RVA, este se chama BaseAddress, veremos mais pra frente. BaseOfCode DWORD relativa ao Base Address indicando o endereço do começo da seção .text(.code) quando ela é carregada em memória, seu RVA. BaseOfData DWORD relativa ao Base Address indicando o endereço do começo da seção .data quando ela é carregada em memória, RVA novamente. ImageBase Quando temos uma imagem carregada em memória precisamos de um endereço para ela, certo? Um executável possui um endereço preferencial, assim como uma DLL. Este endereço é uma DWORD e é chamado de BaseAddress, pois indica o primeiro byte em memória. O valor preferencial para aplicações Windows NT, XP, 95, 98, 2000 é 0x00400000 (explicado o porque dos valores do Olly, né?=D) e para DLL's 0x00010000. 0x400000 o nosso, faz algum sentido o valor ali no debugger agora ? Some ai: 0x400000 + 0x14E0 SectionAlignment Alinhamento da seção (em bytes) quando é carregada em memória indicado por uma DWORD. O tamanho padrão é de uma página de acordo com a arquitetura. Nosso alinhamento de seção é de 4096 bytes. FileAlignment Alinhamento dos dados propriamente ditos das seções da imagem. O padrão é 512. Caso o SectionAlignment seja menor que o tamanho de uma página o FileAlignment será o mesmo do SectionAlignment. 200h = 512 dec, então estamos com o padrão mesmo. MajorOperatingSystemVersion e MinorOperatingSystemVersion 2 WORDS indicando a maior e menor versão do sistema requerido. Não sei muito bem sobre este campo =/ MajorImageVersion e MinorImageVersion 2 WORDS indicando a maior e menor versão da imagem. Também não sei muito sobre MajorSubsystemVersion e MinorSubsystemVersion 2 WORDS indicando a maior e menor versão do SubSystem. Este campo deve ser checado pois a versão vai influenciar na maneira como a aplicação rodará (questão gráfica, por exemplo) Win32VersionValue DWORD reservada e é sempre zero aparentemente. SizeOfImage DWORD que indica o tamanho total (em bytes) da imagem quando carregada em memória, aqui estão inclusos os headers, seções etc e este tamanho deve ser múltiplo da SectionAlignment(até porque este alinhamento trata da imagem carregada). Vamos ver se é múltiplo ? Lembrando que nosso resto deve ser zero. Vamos rodar a ferramenta mais potente do nosso arsenal, a calculadora do windows *-* (brincadeira, usem o shell mesmo). 0x01D000 = 118784 em decimal, dividimos entao por 4096 (alinhamento da seção) e obtemos 29 com resto zero, certinho!! SizeOfHeaders A soma de todos os cabeçalhos, data directory e cabeçalhos das seções. Esta DWORD deve ser múltipla do FileAlignment e é o offset do começo do arquivo até os dados propriamente ditos. Saque sua calculadora e faça novamente a conta, mas agora convertendo e dividindo por 512, aqui deu 1024 e na divisão deu 2, confere? CheckSum Esta DWORD , para as versões atuais do NT, só é checada se a imagem for um driver NT (o driver não carregará se o checksum não estiver correto). Para outros tipos de binários o checksum não precisa ser fornecido e pode ser 0. No nosso caso tem essa macumba ai (o algoritmo para calcular o checksum não é explicitamente aberto). Subsystem Esta WORD representa o Subsystem esperado para executar a imagem. Segue a tabelinha da doc: Constant Value Description IMAGE_SUBSYSTEM_UNKNOWN 0 An unknown subsystem IMAGE_SUBSYSTEM_NATIVE 1 Device drivers and native Windows processes IMAGE_SUBSYSTEM_WINDOWS_GUI 2 The Windows graphical user interface (GUI) subsystem IMAGE_SUBSYSTEM_WINDOWS_CUI 3 The Windows character subsystem IMAGE_SUBSYSTEM_OS2_CUI 5 The OS/2 character subsystem IMAGE_SUBSYSTEM_POSIX_CUI 7 The Posix character subsystem IMAGE_SUBSYSTEM_NATIVE_WINDOWS 8 Native Win9x driver IMAGE_SUBSYSTEM_WINDOWS_CE_GUI 9 Windows CE IMAGE_SUBSYSTEM_EFI_APPLICATION 10 An Extensible Firmware Interface (EFI) application IMAGE_SUBSYSTEM_EFI_BOOT_ SERVICE_DRIVER 11 An EFI driver with boot services IMAGE_SUBSYSTEM_EFI_RUNTIME_ DRIVER 12 An EFI driver with run-time services IMAGE_SUBSYSTEM_EFI_ROM 13 An EFI ROM image IMAGE_SUBSYSTEM_XBOX 14 XBOX IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION 16 Windows boot application. Para você que curte programar em C essa tabela é uma *enum* =D. E qual o nosso valor? DllCharacteristics Características da imagem da DLL (isso se for uma, claro). No nosso caso não é então o campo de 16 bits (WORD) estará zerado. SizeOfStackReserve e SizeOfStackCommit Aqui temos 2 DWORDS indicando o espaço que será reservado para a Stack e o espaço que de fato será entregue no momento que carregar a imagem, respectivamente. Se você não sabe muito bem o que é a estrutura de uma pilha aconselho dar uma lidinha rápida =) Aqui no caso será entregue COMMITED bytes e caso precise de mais espaço iremos de crescer uma página de cada vez (consulte o tamanho da página de acordo com a arquitetura) até chegar no valor reservado que é: RESERVED SizeOfHeapReserve e SizeOfHeapCommit Mais duas DWORDS seguidas com a mesma ideia dos campos explicados acima =) LoaderFlags DWORD aparentemente reservada e com o valor zerado NumberOfRvaAndSizes DWORD indicando o número de entradas do DataDirectory (último item da nossa estrutura e que veremos posteriormente). Cada entrada mostra uma localização e um tamanho, respectivamente. Que tal conferirmos tudo isso com o grande readpe do pev? Aparentemente tudo certo...Chegamos ao fim de mais uma estrutura!! Ficou com alguma dúvida? Pretendo pontuar alguns conceitos interessantes para melhor entendimento do PE mais pra frente, mas não deixem de estudar. Conto com vocês para melhorarem as besteiras que eu falo hein . Feedbacks etc etc só mandar bala e obrigado!!
  4. Projetos Open Source

    Acho que deletaram pra ficar só o do Eduardo pra galera
  5. Questione!

    Boa tarde galera! Este post nada mais é do que uma linha de pensamento que tenho e gostaria de compartilhar pois acho bem vantajosa. Talvez ela não se aplique à todos, mas eu de verdade acho que se aplica na maioria dos casos. Tudo que escrevi foi com base na minha vivência como estudante e ouvindo opiniões de pessoas da área de segurança sobre o mesmo assunto (que por sinal bateram e muito). Queria deixar claro que de forma alguma o post é um insulto, mas sim uma dica, minha opinião e mais importante: não sou melhor do que ninguém . Aqui estão quatro coisas que acho muito importantes para tudo e não só segurança: QUESTIONE! Não assuma nada como verdade logo de cara, computação no geral não é uma receita de bolo onde tudo vai sempre acontecer daquele jeito, as variantes são infinitas e se você souber apenas a aplicação em um contexto irá se perder em qualquer outro. Puxando a afirmação de cima: ESTUDE a base, os fundamentos. Eles não mudam muito, praticamente implementam algo novo em cima de alguma coisa já existente. O estudo destes conceitos ti permite "ignorar" a ferramenta e entender tudo que está ali atrás, possibilitando assim a aplicação em diversos contextos. NÃO fique apenas rodando ferramentas, elas são facilitadoras, mas não fazem milagres e tornam você extremamente limitado. Longe de mim criticar quem cria tools, acho o trabalho dessa galera incrível e mais incrível ainda é toda a comunidade que elas englobam, mas a questão aqui é entender. Vamos pegar quem cria uma tool por exemplo, a pessoa teve que entender TODO o contexto, toda a base, testar, errar, errar, errar mais pra só depois conseguir atingir um ponto legal, então ao invés de apenas roda-la, por que não criar um plugin? Por que não ler o fonte e contribuir? Corrigir se for preciso? Procure tirar suas próprias conclusões. Copiar algo de alguém e tentar ganhar um "título" com isso é praticamente você limitando você mesmo... Resumindo, o conhecimento adquirido no erro, no questionamento, é bem maior do que acreditar cegamente em algo. Não é porque alguém ti falou algo que aquilo é verdade. Pergunte por que, pergunte como, leia, aplique, seja curioso e nunca, NUNCA, coloque títulos na frente do conhecimento ou assuma que você é bom em algo, sempre haverá alguém melhor do que você no assunto . A visão que tenho de hacker(e de forma alguma estou falando pela comunidade ou dizendo que isso é a verdade) é alguém extremamente curioso, extremamente INSATISFEITO com a forma que as coisas são e que faz de tudo para criar, modificar e quebrar coisas. Diga-se de passagem, há um livro do Michael Jordan que fala justamente da importância dos fundamentos, dos conceitos base, pra vermos como isso é realmente primordial. Qualquer opinião sobre essa linha de pensamento será muito bem vinda! Abraços
  6. Descobrindo se um Linux é de 64-bits

    Boa!! cat /proc/version
  7. Projetos Open Source

    Acho que já tem um tópico manin https://www.mentebinaria.com.br/forum/20-programas-livres/
  8. Formato PE - 2

    Não manin, mas pretendo
  9. Formato PE - 2

    Estava faltando uns trechos pq meu editor estava bugado, mas já está certinho
  10. Formato PE - 2

    E aqui estamos para mais um trecho do que venho estudando sobre o formato PE!! Esses dias estava pensando: o editor hexa me mostra tanto os bytes quanto suas representações em ASCII (caso haja), mas e se eu mesmo visse? Ai lembrei da função fseek e fread. A primeira, tratando-se de um binário, pula para o offset em específico e a outro lê os bytes. Dei uma leve lida sobre e fiz esse programinha só pra fazer um “PoC” do que estamos vendo: #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]){ FILE *f; //ponteiro para um arquivo unsigned char buffer[4]; // espaço em memória que iremos colocar os bytes lidos f = fopen(argv[1], "rb"); // abrindo o arquivo binário que recebemos como primeiro parâmetro do nosso programa com permissão de leitura (rb); if(fopen == NULL){ // simples teste para ver se conseguimos abrir o arquivo printf("Erro\n"); exit(1); } fseek(f, 0x80, SEEK_SET); // pulamos para o offset da assinatura PE. O parâmetro SEEK_SET indica que estamos pulando a partir do começo do arquivo fread(buffer, 4, 1, f); // estamos colocando 1 elemento em buffer para leitura e este elemento possui 4 bytes do arquivo (f) puts(buffer); // imprimindo a string dentro de buffer fclose(f); // fechando o arquivo return 0; } Este tipo de teste (leitura de bytes) pode ser feito em qualquer lugar do arquivo, poderíamos ter imprimido os próprios bytes também, por que não tentar? . Caso queira saber um pouco mais [1]. Dando sequência aos nossos estudos temos a struct IMAGE_NT_HEADERS que segue o seguinte escopo segundo a documentação da Microsoft: typedef struct _IMAGE_NT_HEADERS { DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER OptionalHeader; } IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS; Vimos no post anterior a existência da assinatura PE e comprovamos vendo a própria assinatura com o programinha em C ali em cima. Podemos observar que o segundo campo tem nome de FileHeader e é do tipo IMAGE_FILE_HEADER, ou seja, uma struct. Ela que iremos analisar typedef struct _IMAGE_FILE_HEADER { WORD Machine; WORD NumberOfSections; DWORD TimeDateStamp; DWORD PointerToSymbolTable; DWORD NumberOfSymbols; WORD SizeOfOptionalHeader; WORD Characteristics; } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER; IMAGE_MACHINE Logo após a assinatura do PE temos a especificação de que tipo de máquina o executável está previsto para rodar, este campo é uma WORD(16 bits) e aqui está a especificação exata[2]: IMAGE_FILE_MACHINE_UNKNOWN 0x0 The contents of this field are assumed to be applicable to any machine type IMAGE_FILE_MACHINE_AM33 0x1d3 Matsushita AM33 IMAGE_FILE_MACHINE_AMD64 0x8664 x64 IMAGE_FILE_MACHINE_ARM 0x1c0 ARM little endian IMAGE_FILE_MACHINE_ARM64 0xaa64 ARM64 little endian IMAGE_FILE_MACHINE_ARMNT 0x1c4 ARM Thumb-2 little endian IMAGE_FILE_MACHINE_EBC 0xebc EFI byte code IMAGE_FILE_MACHINE_I386 0x14c Intel 386 or later processors and compatible processors IMAGE_FILE_MACHINE_IA64 0x200 Intel Itanium processor family IMAGE_FILE_MACHINE_M32R 0x9041 Mitsubishi M32R little endian IMAGE_FILE_MACHINE_MIPS16 0x266 MIPS16 IMAGE_FILE_MACHINE_MIPSFPU 0x366 MIPS with FPU IMAGE_FILE_MACHINE_MIPSFPU16 0x466 MIPS16 with FPU IMAGE_FILE_MACHINE_POWERPC 0x1f0 Power PC little endian IMAGE_FILE_MACHINE_POWERPCFP 0x1f1 Power PC with floating point support IMAGE_FILE_MACHINE_R4000 0x166 MIPS little endian IMAGE_FILE_MACHINE_RISCV32 0x5032 RISC-V 32-bit address space IMAGE_FILE_MACHINE_RISCV64 0x5064 RISC-V 64-bit address space IMAGE_FILE_MACHINE_RISCV128 0x5128 RISC-V 128-bit address space IMAGE_FILE_MACHINE_SH3 0x1a2 Hitachi SH3 IMAGE_FILE_MACHINE_SH3DSP 0x1a3 Hitachi SH3 DSP IMAGE_FILE_MACHINE_SH4 0x1a6 Hitachi SH4 IMAGE_FILE_MACHINE_SH5 0x1a8 Hitachi SH5 IMAGE_FILE_MACHINE_THUMB 0x1c2 Thumb IMAGE_FILE_MACHINE_WCEMIPSV2 0x169 MIPS little-endian WCE v2 Já inverteram os bytes e descobriram a nossa? Isso mesmo, 0x014c com o nome IMAGE_FILE_MACHINE_I386 NumberOfSections Nossa próxima WORD define o número de seções que nosso binário possui (e o tamanho da section table). Se você não faz ideia do que seja uma seção fique tranquilo que vamos ver tudo isso com o tempo. Lembrando que estamos lidando com base 16 (hexadecimal). Uma simples conversão para a base 10 nos diz que temos 15 sections. 000Fh = 15. TimeDataStamp No campo seguinte temos a DWORD de nome TimeDataStamp(carimbo de data e hora). Praticamente corresponde ao número de segundos decorridos a partir de 1 de Janeiro de 1970 00:00:00, em UTC - o formato utilizado pela maioria dos compiladores C para time_t. Invertendo nossos bytes temos 5997 35E9, isto em decimal fica 1.503.081.961 segundos (credo). Sabemos que um dia tem 24h, que cada hora tem 60 min, e que cada min tem 60 segundos, resumindo 24*60*60 = 86.400 segundos por dia. Fazendo 1.503.081.961/ 86.400 temos 17.396 DIAS desde 01/01/1970 e isso corresponde a mais ou menos 47 ANOS (credo 2 ) e realmente, se somarmos todos esses dias com a data de 01/01/1970… Criei esse executável na data informada No caso eram 18:45, o sistema não está com o horário de Brasília, mas você pegou a ideia! PointerToSymbolTable e NumberOfSymbols Estas duas DWORDS são, respectivamente, ponteiro para a tabela de símbolos e número de símbolos. O primeiro campo é o offset para a tabela de símbolos(em bytes) e o segundo é o número de entradas na tabela de símbolos. SizeOfOptionalHeader Esta WORD é o tamanho do cabeçalho opcional. Caso estejamos tratando de um arquivo objeto este campo estará zerado. Para nós agora ele é simplesmente o tamanho do IMAGE_OPTIONAL_HEADER. Temos 00E0, ou seja, 224 em decimal, 224 bytes. Nao acredita? #include <stdio.h> #include <windows.h> int main(){ printf("O tamanho do header eh de: %d bytes\n", sizeof(IMAGE_OPTIONAL_HEADER)); } Characteristics Aqui temos uma máscara de bits (16 no caso), sabe o registrador EFLAGS[3]? É por ai a ideia. Como a documentação da Microsoft é bem enxuta quanto a isso vou simplesmente dar Ctrl+C Ctrl+V na tabela Flag Value Description IMAGE_FILE_RELOCS_STRIPPED 0x0001 Image only, Windows CE, and Microsoft Windows NT® and later. This indicates that the file does not contain base relocations and must therefore be loaded at its preferred base address. If the base address is not available, the loader reports an error. The default behavior of the linker is to strip base relocations from executable (EXE) files. IMAGE_FILE_EXECUTABLE_IMAGE 0x0002 Image only. This indicates that the image file is valid and can be run. If this flag is not set, it indicates a linker error. IMAGE_FILE_LINE_NUMS_STRIPPED 0x0004 COFF line numbers have been removed. This flag is deprecated and should be zero. IMAGE_FILE_LOCAL_SYMS_STRIPPED 0x0008 COFF symbol table entries for local symbols have been removed. This flag is deprecated and should be zero. IMAGE_FILE_AGGRESSIVE_WS_TRIM 0x0010 Obsolete. Aggressively trim working set. This flag is deprecated for Windows 2000 and later and must be zero. IMAGE_FILE_LARGE_ADDRESS_ AWARE 0x0020 Application can handle > 2‑GB addresses. 0x0040 This flag is reserved for future use. IMAGE_FILE_BYTES_REVERSED_LO 0x0080 Little endian: the least significant bit (LSB) precedes the most significant bit (MSB) in memory. This flag is deprecated and should be zero. IMAGE_FILE_32BIT_MACHINE 0x0100 Machine is based on a 32-bit-word architecture. IMAGE_FILE_DEBUG_STRIPPED 0x0200 Debugging information is removed from the image file. IMAGE_FILE_REMOVABLE_RUN_ FROM_SWAP 0x0400 If the image is on removable media, fully load it and copy it to the swap file. IMAGE_FILE_NET_RUN_FROM_SWAP 0x0800 If the image is on network media, fully load it and copy it to the swap file. IMAGE_FILE_SYSTEM 0x1000 The image file is a system file, not a user program. IMAGE_FILE_DLL 0x2000 The image file is a dynamic-link library (DLL). Such files are considered executable files for almost all purposes, although they cannot be directly run. IMAGE_FILE_UP_SYSTEM_ONLY 0x4000 The file should be run only on a uniprocessor machine. IMAGE_FILE_BYTES_REVERSED_HI 0x8000 Big endian: the MSB precedes the LSB in memory. This flag is deprecated and should be zero. No nosso caso: Nossos bytes invertidos ficam 01 07 e isso em binário fica 0000 0001 0000 0111 Hexa 01 07 Binário 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 1 Bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Agora basta ver com o que o nosso binário bate: IMAGE_FILE_RELOCS_STRIPPED – Há informacoes de remanejamento IMAGE_FILE_EXECUTABLE_IMAGE – É um executável IMAGE_FILE_LINE_NUMS_STRIPPED – A numeracao de linhas foi eliminada IMAGE_FILE_32BIT_MACHINE – A máquina é baseada em uma arquitetura de 32 bits Fico por aqui e queria só falar duas coisas: 1 - Para quem curte estudar pelo blog numaboa[4] aconselho baixar os PDFs pois esses dias aparentemente estava fora do ar e não é a primeira vez que vejo isso acontecer. O material vale muito a pena ser guardado. 2 - A outra é que pretendo colocar isso tudo no meu github essa semana, para quem quiser baixar etc. Como sempre, correções, dicas e opiniões são sempre bem-vindas. Obrigado e boa noite [1] https://www.youtube.com/watch?v=oZeezrNHxVo&list=PLIfZMtpPYFP5qaS2RFQxcNVkmJLGQwyKE [2] https://www.microsoft.com/en-us/download/details.aspx?id=19509 [*] https://msdn.microsoft.com/en-us/library/windows/desktop/ms680198(v=vs.85).aspx [3] https://en.wikipedia.org/wiki/FLAGS_register [4] http://numaboa.com.br/
  11. É praticando que se aprende

    Esse mesmo. Vale tu assistir sim, ele faz algumas comparacoes com assembly na hora de explicar os conceitos e monta um projetinho que aborda praticamente tudo tratado em aula no fim. Existem várias apostilas/livros interessantes sobre C, acho que vale a pena focar um tempo nisso. Obrigado gzn =)
  12. É praticando que se aprende

    Opa, com certeza meu vei, sou totalmente a favor do compartilhamento hehe. E po legal sobre os cursos, não tinha ouvido ainda uma opinião sobre esse da CISCO. O único de R.E que posso falar é o do próprio Mente Binária (pois foi o único que fiz sobre o assunto) e não tenho do que reclamar, da uma olhada lá depois. Sobre a plataforma eu sinceramente não conheço =/
  13. É praticando que se aprende

    Interessante... o que vejo de mais próximo disso (no caso não sou nem um pouco especialista em E.R para dar muitos exemplos) são os desafios crackme da vida, tem vários por sinal. E.R costuma ser um assunto delicado, tendo em vista que nem todos usam pro bem de forma geral. De qualquer forma, bem legal a ideia
  14. Formato PE

    Para quem não entendeu o motivo de tudo isso dei uma editada colocando as vantagens que vejo em relação a esse aprendizado
  15. Formato PE

    Obrigado mano!
×