Ir para conteúdo

Leandro Fróes

Apoiadores
  • Total de itens

    37
  • Registro em

  • Última visita

Reputação

9 Neutral

1 Seguidor

Sobre Leandro Fróes

Últimos Visitantes

241 visualizações
  1. Sou novo e estou perdido.

    Acho que antes de qualquer coisa vc precisa decidir o que gosta MAIS, independente se tudo eh legal, nao da pra saber tudo saca.
  2. Sou novo e estou perdido.

    Certo... vou explicar as operações que sei que são: AND, OR, XOR e NOT. O que elas fazem é exatamente isto que o nome sugere, mas vamos aos exemplos: Pense em binário e atribua 1 como verdadeiro e 0 como falso e olhe para o seguinte circuito (sim, bem artístico): 0 --------| |-------- - ? 1 --------| Temos aqui o 0 em cima e o 1 em baixo. A operação AND diz que só podemos "passar" se OS DOIS forem verdadeiros, então ali qual o resultado? Zero!! Pois se perguntarmos "Ele passa?" A resposta seria não, pois apenas um bit é 1 ali. Aqui está uma linha desta tabela: 0 | 1 | 0 onde 0 AND 1 resulta em 0. A operação OR, ao contrário da AND permite passar se ao menos um dos dois bits ali de cima foram 1, entenda que será 1 o resultado se "ou um ou outro" forem verdadeiros. Ali passaria então, certo? E se fosse 0 | 0 ? Não passaria, afinal ambos são falsos. A operação XOR significa Exclusive OR, ou seja, só passará se tiver APENAS UM (considerando os dois bits do exemplo) dos bits como verdadeiros. Com isto, 0 | 0 ou 1 | 1 resultarão em 0. A operação NOT simplesmente inverte os bits, o que é 0 vira 1 e o que é 1 vira 0. Talvez a aplicabilidade disso seja algo complicado pra quem está começando, mas temos que ter em mente que o processador "só entende" sinais elétricos, né? Considerando o 0 como "não tem sinal" e o 1 como "tem sinal" podemos dizer o que quisermos para o processador. Um processador pode ler o número 255 se passarmos a seguinte sequência para ele: 11111111, ou seja, 8 "sinais", mas e se ele quiser ler o número zero? Terá que passar vários bits com 0 ? Não! A operação NOT pode ser usada em cima destes 8 bits e economizar tempo Por mais que o exemplo esteja fraquinho espero que tenha clareado um pouco a importância das operações e da notação binária na computação.
  3. Sou novo e estou perdido.

    Boa noite!! Bem vindo primeiramente. Passei exatamente por isso em um período da minha faculdade (que também é Analise de Sistemas) e vou relatar o que fiz/faço para lidar com isso. Suponha que você tenha 5 matérias: Pascal, Arquitetura, Contabilidade, Administração geral e Economia. Nota-se logo de cara que há uma diversificação um tanto grande de algumas matérias, mas vamos dar uma olhada em Pascal/Arquitetura, elas tem tudo a ver, certo? Lógica, linguagem de programação e arquitetura de computadores tem tudo a ver, use isso ao seu favor. Estude estas materias que se relacionam mais a fundo e procure sempre relaciona-las, tenha sempre uma visão curiosa do por que das coisas. As outras matérias estude apenas para passar(a não ser que você de fato goste delas também), afinal passar é "preciso" se um diploma for seu objetivo. Sobre dificuldade com lógica eu não sei o que ti recomendar a não ser estudar um pouco sobre fluxogramas e ler um pouco sobre teoria de algoritmos, fora a própria programação (eu não sei livros sobre isso, mas há vários, só dar uma "googlada"). Sobre arquitetura, poderia me dizer quais livros eles ti recomendam e no que vc tem dificuldade exatamente? Faça uma linha de estudos mediano para aquilo que você precisa passar e tudo o que você ver que agrada/tem a ver com S.I priorize, com isso você passa em tudo e mata 2 coisas com uma porrada só, faculdade e o prazer de estudar os fundamentos da S.I. Espero ter ajudado em algo maninho, estas dicas foram para vc melhorar o desempenho da faculdade etc. Caso queira saber como iniciar em S.I aconselho dar uma olhada neste artigo aqui. Qualquer coisa estou por aqui
  4. Sugestões

    Boa noite galera, queria deixar aqui 2 sugestões que acho bem interessantes para o mente binária como um todo: 1- ter uma forma de feedback mais direta para o próprio mente binária. As vezes a pessoa não curte/tem preguiça de escrever algo sobre o portal, por que não um meio com opções: excelente, bom, médio, ruim. Daria pra mensurar melhor, colher resultados pós implementação de algo novo, por exemplo. 2- Busca. Temos nossos perfis com nossa reputação, foto, git etc... por que não o que estamos procurando? Ex interesses: r.e, c, redes, Linux, Windows, saca? E uma barrinha pra procurar pessoas com os mesmos interesses. O que precisarem estou por aqui para ajudar
  5. Formato PE - 4

    Boa noite pessoal! Essas semanas andam meio corridas e não consegui estudar do jeito que gostaria, mas ainda sim bora lá, o importante é estudar, certo? Peço que dêem uma olhada na estrutura do post passado (IMAGE_OPTIONAL_HEADER) e observem o último campo: IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; Para quem manja de C já bate o olho e de cara nota que isso é um array de estruturas chamado DataDirectory de tamanho IMAGE_NUMBEROF_DIRECTORY_ENTRIES e do tipo IMAGE_DATA_DIRECTORY Se dermos uma olhada na biblioteca winnt.h podemos ver que há um valor pré-definido de 16 para o campo IMAGE_NUMBEROF_DIRECTORY_ENTRIES #define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16 A estrutura 'DataDirectory' segue o seguinte escopo: typedef struct _IMAGE_DATA_DIRECTORY { DWORD VirtualAddress; DWORD Size; } IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY; Esta estrutura possui, respectivamente, RVAs e Tamanhos de tabelas usadas em tempo de execução que podem ser usadas pelo Windows. Aqui está nossa referência: Offset (PE/PE32+) Size Field Description 96/112 8 Export Table The export table address and size. For more information see section 6.3, “The .edata Section (Image Only).” 104/120 8 Import Table The import table address and size. For more information, see section 6.4, “The .idata Section.” 112/128 8 Resource Table The resource table address and size. For more information, see section 6.9, “The .rsrc Section.” 120/136 8 Exception Table The exception table address and size. For more information, see section 6.5, “The .pdata Section.” 128/144 8 Certificate Table The attribute certificate table address and size. For more information, see section 5.7, “The Attribute Certificate Table (Image Only).” 136/152 8 Base Relocation Table The base relocation table address and size. For more information, see section 6.6, "The .reloc Section (Image Only)." 144/160 8 Debug The debug data starting address and size. For more information, see section 6.1, “The .debug Section.” 152/168 8 Architecture Reserved, must be 0 160/176 8 Global Ptr The RVA of the value to be stored in the global pointer register. The size member of this structure must be set to zero. 168/184 8 TLS Table The thread local storage (TLS) table address and size. For more information, see section 6.7, “The .tls Section.” 176/192 8 Load Config Table The load configuration table address and size. For more information, see section 6.8, “The Load Configuration Structure (Image Only).” 184/200 8 Bound Import The bound import table address and size. 192/208 8 IAT The import address table address and size. For more information, see section 6.4.4, “Import Address Table.” 200/216 8 Delay Import Descriptor The delay import descriptor address and size. For more information, see section 5.8, “Delay-Load Import Tables (Image Only).” 208/224 8 CLR Runtime Header The CLR runtime header address and size. For more information, see section 6.10, “The .cormeta Section (Object Only).” 216/232 8 Reserved, must be zero Aqui está nosso array, cada diretório representa um índice nesta lista. Vou pegar apenas um como exemplo, tendo em vista que todos os outros seguem o mesmo modelo Este é o array na posição 1(considerando que estamos começando de zero). Este se chama Import Directory. Mais pra frente vou tentar falar melhor sobre ele, pois o danado é importante pra caramba. A primeira DWORD é o RVA da tabela (relativo ao BaseAddress) quando carregada em memória. A segunda DWORD é o tamanho dela em bytes. Que tal revermos alguns conceitos? Quando estamos olhando os bytes de um arquivo por meio de um editor/dumper hexa, estamos olhando diretamente para os bytes do arquivo em disco. Para quem está familiarizado com a seguinte instrução: FILE *fp; Saiba que isto significa um ponteiro para o primeiro byte do arquivo, isto é, o início em disco. Com um ponteiro para um arquivo podemos manipular(imprimir, alterar, pular) os bytes diretamente através de várias funções que estão a nossa disposição e isso tudo através de uma abstração chamada stream(abstração, interface, chame do que quiser). Nos nossos estudos estamos falando de um binário, não de um arquivo em formato texto! Mais algumas considerações legais: Por acaso o termo “Offset” significa algo pra vocês? Este significa deslocamento (em relação a algo). Lembram do RVA ? Relative Virtual Address? Ele tem a mesma ideia do offset e é relativo ao BaseAddress. Ainda não ficou claro? Vamos lá… Quando executamos um programa é reservado um espaço de memória para ele chamado Virtual Address Space, o Windows cria este espaço para cada processo criado. O ‘VirtualAddress’(VA), também conhecido como Linear Address, pode ser achado facilmente. Lembram que o RVA é o deslocamento relativo ao BaseAddress? Sendo assim: VA = BaseAddress + RVA Vamos para a próxima estrutura!! Lembram do campo 'NumberOfSections' no FileHeader? O valor daquele campo nos mostra uma coisa interessante: o número de entradas na Section Table. Ok, não faz sentido *-*. Bom, no primeiro byte após os headers (logo após o ‘OptionalHeader’) está localizado um array de 'SectionHeaders' (ou Section Table Entries, use o que lhe agradar mais). Podemos referenciar da seguinte forma: struct IMAGE_SECTION_HEADER SectionHeaders[Num_no_Optional] e cada seção com seu respectivo índice no array. A estrutura de cada SectionHeader segue o seguinte escopo: typedef struct _IMAGE_SECTION_HEADER { BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; union { DWORD PhysicalAddress; DWORD VirtualSize; } Misc; DWORD VirtualAddress; DWORD SizeOfRawData; DWORD PointerToRawData; DWORD PointerToRelocations; DWORD PointerToLinenumbers; WORD NumberOfRelocations; WORD NumberOfLinenumbers; DWORD Characteristics; } IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER; No caso aqui não vou me preocupar em traduzir cada seção, tendo em vista que os campos do cabeçalho são iguais para todas. Vou apenas explicar pegando uma como exemplo e o resto deixo pra vocês Name O primeiro campo é um array de caracteres(uma string) com valor IMAGE_SIZEOF_SHORT_NAME, tá, mas o que é isso? Dê uma olhada neste campo do header winnt: #define IMAGE_SIZEOF_SHORT_NAME 8 Lá está o valor. Tenha em mente que são 8 bytes contando com um caractere nulo no fim da string(este caractere nulo é ignorado caso o nome tenha de fato 8 bytes). Há alguns detalhes a mais nesta definição, mas vou me preocupar apenas com a imagem de um executável, esta que suporta até 8 bytes em UTF-8 Note que cada byte representa um caractere do nome(no caso aqui é .text) e o resto é preenchido com zeros, ou seja, é feito um padding, um preenchimento para chegarmos ao valor definido pela diretiva #define =D Union (Misc) Pra você que estudou um pouco de estrutura de dados, sabe o que é uma union? Resumindo é parecida com uma struct, a questão é que o espaço de memória usado para as variáveis da union é compartilhado (geralmente em momentos diferentes). O compilador cria automaticamente uma variável grande o bastante para conter o maior tipo de variável da union. Voltando ao PE: PhysicalAddress e VirtualSize(Misc) Aqui temos duas DWORDS, uma indicando o endereço no arquivo e outra indicando o tamanho da seção depois que for carregada em memória(em bytes). Se este valor for maior que ‘SizeOfRawData’ a seção é preenchida com zeros. O campo ‘VirtualSize’ só é válido para imagens executáveis e será zero para arquivos objeto. No nosso caso deu 5744 bytes, 0x1670h VirtualAddress Para imagens executáveis é uma DWORD indicando o RVA, o primeiro byte da seção quando carregada em memória(lembrando que temos que somar ao 'BaseAddress'). Para arquivos objeto os compiladores setam este valor para zero Ali no canto esquerdo podemos ver o valor do VirtualAddress somado ao BaseAddress, resultando no primeiro byte da seção após ser carregada em memória =D SizeOfRawData Após o endereço virtual vêm 32 bits para os Tamanho dos Dados ('SizeOfRawData'), que nada mais é do que o tamanho dos dados da seção arredondado para cima, para o próximo múltiplo de 'FileAlignment' (alinhamento de arquivo). No nosso exemplo, o valor encontrado é 0000 1800, faça a conta e veja se é múltiplo mesmo =D. Caso a seção possua apenas dados não-inicializados este campo é preenchido com zeros(como é o caso da seção .bss ) PointerToRawData Este campo é bem interessante(não que os outros não sejam, claro). Para executáveis é uma DWORD indicando o offset dentro do arquivo(e deve ser múltiplo de 'FileAlignment') até os dados da seção propriamente ditos. Caso a seção possua apenas dados não-inicializados este campo é preenchido com zeros, de novo… No offset 400h na esquerda podemos ver justamente o início da seção .text em nosso arquivo PointerToRelocations, PointerToLinenumbers, NumberOfRelocations e NumberOfLineNumbers Aqui os dois primeiros campos são DWORDS e os seguintes WORDS. Todas estas informações somente são utilizadas para arquivos objeto, ou seja, estarão zeradas no nosso caso. Os executáveis não possuem um diretório de remanejamento base especial e a informação de número de linha, se é que está presente, geralmente está localizada num segmento especial para debugging ou em qualquer outro lugar. Para deixar um pouco mais claro(bem por cima): COFF Relocations (que só acontece em arquivos objeto) é a forma como os dados da seção devem ser modificados quando colocados na imagem e, posteriormente, carregados em memória. Characteristics Uma DWORD com uma porção de flags dizendo características da seção. Podemos dizer que é uma enum. Segue a documentação: Flag Value Description 0x00000000 Reserved for future use. 0x00000001 Reserved for future use. 0x00000002 Reserved for future use. 0x00000004 Reserved for future use. IMAGE_SCN_TYPE_NO_PAD 0x00000008 The section should not be padded to the next boundary. This flag is obsolete and is replaced by IMAGE_SCN_ALIGN_1BYTES. This is valid only for object files. 0x00000010 Reserved for future use. IMAGE_SCN_CNT_CODE 0x00000020 The section contains executable code. IMAGE_SCN_CNT_INITIALIZED_DATA 0x00000040 The section contains initialized data. IMAGE_SCN_CNT_UNINITIALIZED_ DATA 0x00000080 The section contains uninitialized data. IMAGE_SCN_LNK_OTHER 0x00000100 Reserved for future use. IMAGE_SCN_LNK_INFO 0x00000200 The section contains comments or other information. The .drectve section has this type. This is valid for object files only. 0x00000400 Reserved for future use. IMAGE_SCN_LNK_REMOVE 0x00000800 The section will not become part of the image. This is valid only for object files. IMAGE_SCN_LNK_COMDAT 0x00001000 The section contains COMDAT data. For more information, see section 5.5.6, “COMDAT Sections (Object Only).” This is valid only for object files. IMAGE_SCN_GPREL 0x00008000 The section contains data referenced through the global pointer (GP). IMAGE_SCN_MEM_PURGEABLE 0x00020000 Reserved for future use. IMAGE_SCN_MEM_16BIT 0x00020000 Reserved for future use. IMAGE_SCN_MEM_LOCKED 0x00040000 Reserved for future use. IMAGE_SCN_MEM_PRELOAD 0x00080000 Reserved for future use. IMAGE_SCN_ALIGN_1BYTES 0x00100000 Align data on a 1-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_2BYTES 0x00200000 Align data on a 2-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_4BYTES 0x00300000 Align data on a 4-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_8BYTES 0x00400000 Align data on an 8-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_16BYTES 0x00500000 Align data on a 16-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_32BYTES 0x00600000 Align data on a 32-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_64BYTES 0x00700000 Align data on a 64-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_128BYTES 0x00800000 Align data on a 128-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_256BYTES 0x00900000 Align data on a 256-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_512BYTES 0x00A00000 Align data on a 512-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_1024BYTES 0x00B00000 Align data on a 1024-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_2048BYTES 0x00C00000 Align data on a 2048-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_4096BYTES 0x00D00000 Align data on a 4096-byte boundary. Valid only for object files. IMAGE_SCN_ALIGN_8192BYTES 0x00E00000 Align data on an 8192-byte boundary. Valid only for object files. IMAGE_SCN_LNK_NRELOC_OVFL 0x01000000 The section contains extended relocations. IMAGE_SCN_MEM_DISCARDABLE 0x02000000 The section can be discarded as needed. IMAGE_SCN_MEM_NOT_CACHED 0x04000000 The section cannot be cached. IMAGE_SCN_MEM_NOT_PAGED 0x08000000 The section is not pageable. IMAGE_SCN_MEM_SHARED 0x10000000 The section can be shared in memory. IMAGE_SCN_MEM_EXECUTE 0x20000000 The section can be executed as code. IMAGE_SCN_MEM_READ 0x40000000 The section can be read. IMAGE_SCN_MEM_WRITE 0x80000000 The section can be written to. Nesta parte não vou colocar o valor que deu no meu, vou apenas destacar um fato interessante que é: a seção .text possui permissão de leitura e execução (os bits 29 e 30 estão sempre setados nela), pelo menos deveriam Muito obrigado por aguentar até aqui, espero que tenha sido claro e como sempre, qualquer feedback só mandar bala. Queria também avisar que coloquei todo esse material no meu github (https://github.com/leandropf/pecoff). Sei que não é lá essas coisas, apenas um mero mortal descrevendo os campos, mas ainda sim quem sabe não ajude alguém ou no mínimo dê uma direção . Abraços e bom domingo!
  6. Inicio para um programador

    Bom dia!! Legal aprender algoritmo em C/C++, forma uma base bem mais sólida que a maioria das linguagens. Sobre o caminho eu indico não se preocupar tanto com a linguagem em si no momento, mas sim no fundamento, na lógica. A ideia de algoritmo é entender o problema, dividi-lo em pedaços menores e resolve-los (a junção das partes forma o algoritmo). Aconselho junto à lógica procurar entender o que de fato está rolando em cada linha do seu código, use um disassembly, por exemplo. Sabendo como acontece o resto é resto mano!! Sobre referencias... de C sempre curti o "C Completo e Total" que fala do C puro ou o "Advanced Programming in the Unix Environment" que já joga pro lado do *nix, mostra uma aplicabilidade legal. C++ eu não sei livros, mas um fórum que acho legal é o cplusplus. De resto há muita coisa legal na net, no próprio GNU/Linux tem as man pages das funcões (ler códigos no git e entender tem me ajudado tb). Espero ter ajudado em algo. Saiba que a linguagem é poderosa pra caramba e ainda há mercado, principalmente pra pessoas experientes . E caso você fique insatisfeito com "apenas" C estude também assembly, ele vai solidificar muito mais as coisas
  7. 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!!
  8. 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
  9. 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!!
  10. Projetos Open Source

    Acho que deletaram pra ficar só o do Eduardo pra galera
  11. 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
  12. Descobrindo se um Linux é de 64-bits

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

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

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

    Estava faltando uns trechos pq meu editor estava bugado, mas já está certinho
×