Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - seci

Pages: [1] 2
1
Hacking and Security / Re: What keeps you up to date?
« on: August 25, 2011, 05:43:27 pm »
Added the ones you said Kulverstukas :)

This is now a news-feed-list thread.

2
Hacking and Security / Re: What keeps you up to date?
« on: August 25, 2011, 04:08:25 pm »
Twitter.

Obviously.. But the point of this topic was to get some feeds! Post in more details mate ;)

3
Hacking and Security / What keeps you up to date?
« on: August 25, 2011, 03:44:29 pm »
Hi Evilzone!

I have recently wanted to have some sort of centralized page for all tech, hacker, programmer, security and other computer related things news feed. Be it facebook, twitter, normal pages, rss feeds etc. I want to know how YOU keep yourself updated on the hacking scene. I know there is a few pages out there, like thehackernews n such. But I want to broaden my horizon.

Post your news feeds!

Here is a few I use:
http://www.thehackernews.com/
http://wired.com
+ a few contry-local facebook groups.


The list:
http://packetstormsecurity.org/
http://www.thehackernews.com/
http://wired.com
http://pentestit.com/
http://www.securitytube.net/
http://securityphresh.com/
http://www.theprohack.com/
http://news.hitb.org/
[dutch] http://security.nl
http://nakedsecurity.sophos.com/
http://threatpost.com/

4
Tutorials / Re: Getting into the hacker mindset
« on: July 17, 2011, 10:09:43 pm »
I posted link about hacker mindest,not cracker mindest :P

Makes no sense.

Are you suggesting this topic is about a crackers mindset?

5
Tutorials / Re: Getting into the hacker mindset
« on: July 17, 2011, 04:11:33 pm »
http://www.wikihow.com/Become-a-Hacker

Oh hello there thread pooper.

You clearly fail to see the value of Evilzone content and a guy who post links. Anyway, I might add some words from that article nonetheless. You probably want to read the entire post and realize its not even quarter done aswell.

6
Tutorials / Getting into the hacker mindset
« on: July 16, 2011, 01:42:27 am »
Yes, this is a how-to-start-hacking topic. Yet another one.. I hope this topic will guide new hackers out there in the right direction. Or the direction which I see as right anyway.


Getting into the hacker mindset
By Seci of Evilzone.org

I have seen this board(Evilzone), and IRC- having a lot of people asking; Where to start? But there are few real good answers. There has been answers, but I can understand the issues surrounding answering, making none of the answers complete. And to be honest, there is no answer. Only guidence. Where to begin is not one fixed point. It will totally depend on what aspects of hacking you want to learn(first?). As well as your definitions of a hacker or and hacking.

Lets start off by getting some definitions straight. These are not facts, but rather how I like to see things. And how most other experienced hackers like myself views things. There are no right or wrong. But my understanding is that Evilzone got many of the same point of views as me, therefore I believe the coming definitions will fit smoothly for anyone browsing Evilzone and are willing to learn. If you disagree with my definitions you better have a good reason why. Or not. Who am I to judge.


<definitions>

A hacker is a knowledgeable person with a mindset fit to crack any challenge. He or she might even enjoy the challenge more than the end product. In general a hacker is creative, not destructive. But destruction will most likely happen at some point. A hacker will never let his challange go without a real fight. A hacker will act professional in all situations, speak properly and remain calm in any situation. And last but not least, a hacker has a lot of fun.

Hacking is in very broad words; Fixing, modifying or make something do something it was not designed to do. This is the stereotypical definition of hacking. Hacking is not limited to computer related stuff. This is an important note. However, the word hacking is today mostly used for the idea of computer-hacking.
Software exploitation is hacking because you are making the software do something it was not designed for.
Web-application exploitation is hacking because you are making the software run in a way the designer did not intend.
Reverse engineering is hacking because programs was not designed to be decompilable.
Social engineering is hacking because you are making people do something they would not have done without modification of the situation.
And so on.

</definitions>



Now we have laid down some ground rules for the coming words. Many of you probably already knew this. But this is a beginner topic. So we have to start with the basics.

Lets jump back to the question; Where to start?
Again, you have to pick a more narrow topic within the bounds of hacking. But then again, how can you do that when you do not know its aspects. I will try to list most of the aspects of hacking, but this is no way a complete list;



The stereotypical computer-hacker topics:


Software exploitation
- Exploiting user-input vulnerabilities like bufferoverflow to gain control over programs that was not intended to be controlled.
Will require a in-depth understanding of computer logics and programming. C/++, ASM, Perl or and Python are key languages that should be learned. In order to perform software exploitation you will need to know how to code vulnerable code, how to spot it and how to NOT code vulnerable code.
Can be used to hack almost any system, locally and remotely.

How to start:
- C# / VB
- Perl / Python
- C / C++
- Assembly
- Hacking theory ( Bufferoverflows )



Web-application exploitation
By far the most used method to get publicity now-days. Exploitation of server-side scripts and programs running web interfaces. Typical topics: Remote File Inclusion(RFI), Local File Inclusion(LFI), SQL injection, Cross Site Scripting(XSS) and Cross Site Request Forgery(CSRF). There will be other topics to, either mix-ups of the ones above, similar ones or completely different ones.
Must-know languages: PHP, HTML, Javascript, SQL and one of the following Perl, Python, C/++
You should also have good knowledge on TCP/IP stuff.

How to start:
- HTML
- Javascript
- PHP
- SQL (MySQL)
- Perl / Python
- C / C++
- Hacking Theory ( RFI, LFI, XSS, SQLi and SCRF )



Software modification

Changing software to do as you want it to. Typically called cracking, reversing or patching. This will allow you to remove or add things like license, mods, hacks to all sorts of applications.
To do this, you need an in-depth understanding of programming languages, compilers, linkers and IDE's. As well as understanding computer logic and machine code translated to Assembly. You will need to know how to work with a debugger and decompilers and disassemblers.
You probably need to know Assembly, C/++, Perl/Python and more wont hurt.

How to start:
- C# / VB
- Perl / Python
- C / C++
- Assembly
- Hacking theory ( Debugging, patching and mods )





Less computer related hacking:

Social Engineering
The ability to manipulate people into doing things they would not normally do in the given situation. Straight up tricking people.
To do this, you simply need to Practice. Don't force it, just act natural. Understand concepts of trust and so forth.
Many major hacks have been pulled off like this.

How to start:
- Chat around
- Chat some more
- Body language
- Facial expressions
- Trust concepts
- Psychology
- Start doing small scale engineerings
- Have fun







In addition, maybe except Social Engineering. In-depth computer logics, concepts and understanding are a must. But you don't really need to think about it that much, as you will gain that by learning to code, using your computer and so forth.






I will end this text here for the moment. This tutorial is not complete, maybe it will. Some time. There about a million more words that could be written. More to come later.







Notes:
- Hacker behavior
- Maturity
- Proper writing
- Coding is the key to all success
- How to start coding
- Coding project
- Make projects
- Make plans
- Write down ideas
- Follow your ideas
- Share your ideas
- Use Google
- Set goals
- Follow your goals
- Hacker mind set in every day life
- Good jobs
- Lots of money to be made
- Most importantly, have fun

7
Projects and Discussion / Re: The PE(EXE) Structure
« on: July 16, 2011, 12:42:18 am »
please post it!

ontopic: I have a question, I understand the structure you explained so far, but how do you read the headers?
I made a own program  that could load the bytes of a file into a Datagridview,
this would work for every type of file, but I didn't see anything of those sections names in there
is there a certain byte that represent them?
or is there a conversion needed?

Hello again. To all. Sorry I have been away for a while. Been busy.

Anyway, I dont got the function on this laptop. But I found something close to it with a quick google search:
Code: [Select]
/*----------------------------------------------------------*
*
* RVAToOffset: Convert value from RVA to file offset.
*----------------------------------------------------------*/
DWORD CPE::RVAToOffset(DWORD dwRVA)
{
int i;
WORD wSections;
PIMAGE_SECTION_HEADER pSectionHdr;

/* Map first section */
pSectionHdr = IMAGE_FIRST_SECTION(m_pNtHdr);
wSections = GetNumberOfSections();

for (i = 0; i < wSections; i++)
{
if (pSectionHdr->VirtualAddress <= dwRVA)
if ((pSectionHdr->VirtualAddress + pSectionHdr->Misc.VirtualSize) > dwRVA)
{
dwRVA -= pSectionHdr->VirtualAddress;
dwRVA += pSectionHdr->PointerToRawData;
return (dwRVA);
}
pSectionHdr++;
}
return (-1);
}

/*----------------------------------------------------------*
*
* OffsetToRVA: Convert value from file offset to RVA.
*----------------------------------------------------------*/
DWORD CPE::OffsetToRVA(DWORD dwOffset)
{
int i;
WORD wSections;
PIMAGE_SECTION_HEADER pSectionHdr;

/* Map first section */
pSectionHdr = IMAGE_FIRST_SECTION(m_pNtHdr);
wSections = GetNumberOfSections();

for (i = 0; i < wSections; i++)
{
if (pSectionHdr->PointerToRawData <= dwOffset)
if ((pSectionHdr->PointerToRawData + pSectionHdr->SizeOfRawData) > dwOffset)
{
dwOffset -= pSectionHdr->PointerToRawData;
dwOffset += pSectionHdr->VirtualAddress;
return (dwOffset);
}

pSectionHdr++;
}
return (-1);
}

If you got any issues let me know :)

8
Projects and Discussion / Re: The PE(EXE) Structure
« on: May 28, 2011, 03:15:49 pm »
I think everything is correct. Nice summary.That's it. You have an array of those sctructures at OptionalHeader->DataDirectory. It has 16 members, in order: export, import, resource, exception, security, basereloc, debug, copyright, globalptr, tls, load_config, bound_import, iat, delay_import, com_descriptor.
DataDirectory, being that structure you said, has Size (its size, obviously) and VirtualAddress, which is a RVA. If you want the real physical address of that section in the file, you have to do it like this:
Physical_Address = RVA - [Container section].VirtualAddress + [Container section].PointerToRawData
This RVA thing is a pain, when you are exploring a PE file in C you have to be always doing this conversion.

Yes, I am aware of the RVA issue. But I wrote a function for it that can convert any RVA to physical offset.


Also, I was thinking about writing some texts about PE as I am learning. Would you like to do it together?

I could possibly help out, double check facts and such. I am still reading up on OpCodes and how the CPU instructions are organized and a little bit of more PE structure.

9
Projects and Discussion / The PE(EXE) Structure
« on: May 28, 2011, 04:11:47 am »
Hello again, been a few days since I have posted anything at Evilzone now. I have been reading a lot of papers on various things related to assembly, disassembly, CPU architecture, PE/COFF structure documentation and so on. But now am back for further questions!

Also, for those of you who have been reading my other topics. I will update them with solutions once they are solved, I am still working on translating bytes into assembly instructions and so on. Should be doing some progress tonight/tomorrow.


Now, to my question. Or rather, verification.
I just want someone with experience with this to verify that I got things right. When or if this topic/my question gets verified to be correct it can probably be used as guidance for others to :) So. I will just write up what I have read/interpriated about the PE structure below this text block. Then someone who knows his shit read thought it and see if I got anything wrong. There might be a question or two in the text to. Thanks in advance :)
-------------------------------


The PE(Portable Executable) Structure

Any PE file will consist of the following structures(roughly, we will go in more details later). List will be in the order as they will be in the file structure.
  • DOS MZ Header. This is the very first bytes in any PE, it states various things about the PE. (In-depth details will be put along side the structure(s) below)
  • DOS Stub. This is 100 bytes++ with machine code just to output "This program cannot run in DOS mode". This is here to avoid programs from running in DOS Mode. This part of the PE is not required tho, you can tell your compiler to not include this.
  • PE Signature, part of the PE Header. Its the first 4 bytes in the IMAGE_NT_HEADERS. Its there to verify that this is in fact a PE. The signature for a valid PE file is the ASCII letters 'PE' followed by 2x 0-bytes
  • PE Header(s). This is the vital part of a PE, it contains information about the entire PE structure. It also contains two inner headers and one inner inner header. They are listed below.
  • PE Header - File Header. This header contains further vital information about the file. Details will be listed in the header structures below.
  • PE Header - Optional Header. Despite its name, this header is NOT optional at all. This is the largest header in the PE Header. Once again, this header contains tons of information regarding the PE layout/structure. Among other things, the PE entry point. (The first 'line' of code that will be executed once the program runs)
  • PE Header - Optional Header - DataDirectory. The DataDirectory header is an array of the IMAGE_DATA_DIRECTORY structure that contains information about the various directories in the PE. Import Directory, Export Directory, Resource Directory and so on. These directories contains information about where to locate other information, in short.
  • Section Header(s). Section header structures. One structure for each of the sections in the file. Normally like 4-6 sections. Structure contains section name, size, address and so on. More info on sections 4 points down. The number of sections are set in PE Headers -> File Header -> NumberOfSections
  • Data Directories. These are the directories mentioned above, containing various information. Resources, imported DLL's and so on. (I haven't read so much about all of these yet)
  • Data Directories ...
  • [...]
  • Sections. Sections are large chunks of bytes that can be anything. Code, resources, icon(s), information and so on. Each section have its own "rules", some are read-only, some are executable and some are data - read and writable. The sections are typically called ".text", ".data", ".rsrc", ".reloc". There can be up to 16 sections. The number of sections are set by a value in the File Header. Each section have a structure of IMAGE_SECTION_HEADER about itself containing its name, size, address, offset and "rules" or Characteristics.
  • Sections ...
  • [...]
  • EOF. End Of File
The structures (C/++ syntax)

DOS MZ Header
Code: [Select]
typedef struct _IMAGE_DOS_HEADER {  // DOS .EXE header
    USHORT e_magic;         // Magic number                                       // 2 bytes
    USHORT e_cblp;          // Bytes on last page of file                         // 2 bytes
    USHORT e_cp;            // Pages in file                                     // 2 bytes
    USHORT e_crlc;          // Relocations                                       // 2 bytes
    USHORT e_cparhdr;       // Size of header in paragraphs                      // 2 bytes
    USHORT e_minalloc;      // Minimum extra paragraphs needed                   // 2 bytes
    USHORT e_maxalloc;      // Maximum extra paragraphs needed                    // 2 bytes
    USHORT e_ss;            // Initial (relative) SS value                        // 2 bytes
    USHORT e_sp;            // Initial SP value                                   // 2 bytes
    USHORT e_csum;          // Checksum                                           // 2 bytes
    USHORT e_ip;            // Initial IP value                                    // 2 bytes
    USHORT e_cs;            // Initial (relative) CS value                       // 2 bytes
    USHORT e_lfarlc;        // File address of relocation table                  // 2 bytes
    USHORT e_ovno;          // Overlay number                                     // 2 bytes
    USHORT e_res[4];        // Reserved words                                     // 2*4 bytes
    USHORT e_oemid;         // OEM identifier (for e_oeminfo)                     // 2 bytes
    USHORT e_oeminfo;       // OEM information; e_oemid specific                 // 2 bytes
    USHORT e_res2[10];      // Reserved words                                    // 2 * 10 bytes
    LONG   e_lfanew;        // File address of new exe header                     // 4 bytes
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
Total bytes: 64
e_lfanew points to the offset of the PE Header, this is because of the DOS header. Because its optional and it can be as small or large as you want/your compiler wants. The offset of the PE Header can vary.
Couldn't find any MS.com link :S


PE Header
Code: [Select]
typedef struct _IMAGE_NT_HEADERS {        // Includes the PE signature, File Header and Optional Header
  DWORD                 Signature;        // The PE signature                                               // 4 bytes
  IMAGE_FILE_HEADER     FileHeader;        // The File Header structure                                      // 20 bytes
  IMAGE_OPTIONAL_HEADER OptionalHeader;        // The Optional Header structure                            // 224 bytes
} IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS;
Total bytes: 248 (including the other structures)(Maximum, can be less depending on the amount of DataDirectories in the Optional Header
http://msdn.microsoft.com/en-us/library/ms680336%28v=vs.85%29.aspx


File Header
Code: [Select]
typedef struct _IMAGE_FILE_HEADER {
  WORD  Machine;                // Machine type (alpha/motorola/...)(001, 076 == I386)        // 2 bytes
  WORD  NumberOfSections;            // Number of sections in the file                      // 2 bytes
  DWORD TimeDateStamp;                // The time that the file was created                  // 4 bytes
  DWORD PointerToSymbolTable;            // The file offset of the COFF symbol table         // 4 bytes
                                                // This field is only used in OBJ files and PE files
                                                // with COFF debug info
  DWORD NumberOfSymbols;            // The number of symbols in the COFF symbol table         // 4 bytes
  WORD  SizeOfOptionalHeader;            // Size of the OptionalHeader structure           // 2 bytes
  WORD  Characteristics;            // Flags of the file (EXE/DLL/System file/...)             // 2 bytes
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
Total bytes: 20
http://msdn.microsoft.com/en-us/library/ms680313%28v=vs.85%29.aspx


Optional Header
Code: [Select]
typedef struct _IMAGE_OPTIONAL_HEADER {
  WORD                 Magic;                            // 2 bytes identifying the state of the file.                                                  // 2 bytes
  BYTE                 MajorLinkerVersion;                    // Linker major version number.                                                                // 1 bytes
  BYTE                 MinorLinkerVersion;                    // Linker minor version number.                                                                // 1 bytes
  DWORD                SizeOfCode;                        // Size of the code section OR Sum of all code sections (multiple sections).                   // 4 bytes
  DWORD                SizeOfInitializedData;                    // Size of the initialized data OR .... multiple data sections.                                // 4 bytes
  DWORD                SizeOfUninitializedData;                    // Size of the uninitialized data section (BSS) OR ... multiple BBS sections.                  // 4 bytes
  DWORD                AddressOfEntryPoint;                    // Address of entry point (RVA of the 1st instruction to be executed)                          // 4 bytes
  DWORD                BaseOfCode;                        // Address (RVA) of beginning of code section.                                                 // 4 bytes
  DWORD                BaseOfData;                        // Address (RVA) of beginning of data section.                                                 // 4 bytes
  DWORD                ImageBase;                        // The *preferred* load address of the file (default is 0x00400000).                           // 4 bytes
  DWORD                SectionAlignment;                    // Alignment (in as strings) of sections when loaded into memory.                              // 4 bytes
  DWORD                FileAlignment;                        // Alignment (in as strings) of sections in the file (multiplies of 512 as strings).           // 4 bytes
  WORD                 MajorOperatingSystemVersion;                // Major version number of required OS.                                                        // 2 bytes
  WORD                 MinorOperatingSystemVersion;                // Minor version number of required OS.                                                        // 2 bytes
  WORD                 MajorImageVersion;                    // Major version number of image.                                                              // 2 bytes
  WORD                 MinorImageVersion;                    // Minor version number of image.                                                              // 2 bytes
  WORD                 MajorSubsystemVersion;                    // Major version number of subsystem.                                                          // 2 bytes
  WORD                 MinorSubsystemVersion;                    // Minor version number of subsystem.                                                          // 2 bytes
  DWORD                Win32VersionValue;                    // Dunno! But I guess for future use.                                                          // 4 bytes
  DWORD                SizeOfImage;                        // Total size of the PE image in memory (All Headers & Sections aligned to SectionAlignment).  // 4 bytes
  DWORD                SizeOfHeaders;                        // Size of all headers & section table. (The file offset of the first section in the PE file)  // 4 bytes
  DWORD                CheckSum;                        // Image file checksum. (computing algorithm is in IMAGHELP.DLL)                               // 4 bytes
  WORD                 Subsystem;                        // Target subsystem of the PE file. (Mostly GUI & CUI)                                         // 2 bytes
  WORD                 DllCharacteristics;                    // Flags used to indicate if a DLL image includes EPs.                                         // 2 bytes
  DWORD                SizeOfStackReserve;                    // Size of stack to reserve.                                                                   // 4 bytes
  DWORD                SizeOfStackCommit;                    // Size of stack to commit.                                                                    // 4 bytes
  DWORD                SizeOfHeapReserve;                    // Size of local heap space to reserve.                                                        // 4 bytes
  DWORD                SizeOfHeapCommit;                    // Size of local heap space to commit.                                                         // 4 bytes
  DWORD                LoaderFlags;                        // Choose to (break/debug/run normally (default)) on load.                                     // 4 bytes
  DWORD                NumberOfRvaAndSizes;                    // The length of the DataDirectory array that follows.                                         // 4 bytes
  IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];        // An array of IMAGE_DATA_DIRECTORY, lenght = 16                                               // 8 bytes * 16
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;
Total max bytes: 224
http://msdn.microsoft.com/en-us/library/ms680339%28v=vs.85%29.aspx


DataDirectory
Code: [Select]
typedef struct _IMAGE_DATA_DIRECTORY {
  DWORD VirtualAddress;                               // RVA of the location of the directory                 // 4 bytes
  DWORD Size;                                               // Size of the directory                           // 4 bytes
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
* IMAGE_NUMBEROF_DIRECTORY_ENTRIES
Additionally I am guessing there is structures for each of the directories, export, import, resource, exception, security, basereloc, debug, copyright. etc. etc
http://msdn.microsoft.com/en-us/library/ms680305%28v=vs.85%29.aspx


Section Header(s)
Code: [Select]
typedef struct _IMAGE_SECTION_HEADER {
  BYTE  Name[IMAGE_SIZEOF_SHORT_NAME];        // Simply the name of the section (ANSI name)                                 // 8 bytes
  union {
    DWORD PhysicalAddress;            //?                                          //
    DWORD VirtualSize;                // Size of the file when its mapped to memory. Must be multiple of 4096       // 4 bytes
  } Misc;
  DWORD VirtualAddress;                // The RVAof the file where it should be mapped to memory                     // 4 bytes
  DWORD SizeOfRawData;                // The size of the section, rounded to the next multiply of the FileAlighment // 4 bytes
  DWORD PointerToRawData;            // The offset in the file of the beginning og the section                     // 4 bytes
  DWORD PointerToRelocations;            // Not used                                                                   // 4 bytes
  DWORD PointerToLinenumbers;            // Not used                                                                   // 4 bytes
  WORD  NumberOfRelocations;            // Not used                                                                   // 2 bytes
  WORD  NumberOfLinenumbers;            // File-based offset of the line number table. (Not really used)              // 2 bytes
  DWORD Characteristics;            // Flags for section charactaristics as follow below                          // 4 bytes
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
Total bytes: 40
There is one of this structure for each section in the PE
http://msdn.microsoft.com/en-us/library/ms680341%28v=vs.85%29.aspx



Now, I believe this is all the headers and whatnot. Except the directory structures, import, export and so on. Am I rit?

10
Projects and Discussion / Re: Translating bytes into assembly
« on: May 23, 2011, 08:55:03 pm »
if the instruction line are 2 - 14 long
then try
the total amount of bytes - (the number of bytes that are used for setting the length)
then divide by 2 / 14 and see which gives a good number
since the length of those instruction line are set to a certain number
then the length of the total amount of bytes should be in the range of the Multiplication table of that number
but you have to exclude the first bytes from the total amount since they set the whole length
at least this is what I think
I have no further knowledge of this stuff :P

If it only was that simple :(

Basically, there is no way knowing from reading it anywhere how long each instruction is. You have to judge it by the byte values.
First there is a instruction prefix that can be anything from 0 to 4 bytes(optional), this prefix modifies the function of the instruction, which is the coming 1 or 2 bytes(required). Then there is another 1 byte(optional) that does modification to the way the instruction work. Then another 1 byte that does more modification of the instruction(optional). Then there is something called displacement(optional) which I am not 100% what is, I am reading this right now. Then there is the last bytes which is immediate data, 1 to 4 bytes(optional)

In total there is 1 byte minimum and 16 bytes maximum for each instruction. More on this later.


I have been reading tons and tons of research the past days, learned a lot. I will maybe write a rather large guide/tutorial or whatever on PE/COFF, reading headers and starting reversing of PE's from bottom up and close up the two topics I have about this to now.

11
Projects and Discussion / Translating bytes into assembly
« on: May 23, 2011, 12:44:25 am »
This is a continued discussion of http://evilzone.org/projects-and-discussion/calculating-entrypoint-and-mapping-it-to-byte-array/, which I will be updating soon with the information I have learned. I now have managed to read all of the PE headers, calculating the entrypoint and finding the bytes at the entrypoint.

Now I want to translate these bytes into something meaningful! So, how on earth do I do this? If someone could point me to tutorials, guides, books(not to big :() I would be very grateful!

I have a rough understanding of it, an instruction can be anything from ~2 bytes to like 14 or 17 or something. And the length of the instruction is determined by the early bytes in the instruction etc. But there is no good tables/descriptions etc for how to actually do this. I tried looking at the Intel opcode instruction reference PDF, but its like 1500 pages of nonsense :(

12
We could keep this thread alive with our research in this topic. It could be helpful to both us and the rest of people interested.

Sure, ill post up some info when I have done a bit more coding and things are starting to work :)

13
I have not enought knoweldge to aswer you trusting myself, sorry. I think we know more or less the same about this topic. I attach you a rar with various PDFs about PE. There is one og them, called "PE format", which is a diagram of the PE structure and the structs it is composed of.

Ah yes, that diagram actually helped a bit. Thanks ca0s, you have been great help :) Further comments are welcome.

14
Okay so. I have managed to read in the IMAGE_DOS_HEADER structure, locate the PE header address, address of the IMAGE_NT_HEADERS structure. Read in the IMAGE_NT_HEADERS signature. Read the IMAGE_FILE_HEADER inside the IMAGE_NT_HEADERS structure. Read big parts of IMAGE_OPTIONAL_HEADER which is also a part of IMAGE_NT_HEADERS. However, the last bit in IMAGE_OPTIONAL_HEADER got me confused;

The DataDirectory structure inside IMAGE_OPTIONAL_HEADER, IMAGE_DATA_DIRECTORY. Its an array of the structure IMAGE_DATA_DIRECTORY, which is 2x 4 bytes(VirtualAddress and isize DWORD's). The array length is 16, so 16 * 8 bytes = 128 bytes. However, I don't understand where to read this/these structures.

The last DWORD successfully read in IMAGE_OPTIONAL_HEADER is NumberOfRvaAndSizes and right after that is the array of the structure IMAGE_DATA_DIRECTORY, DataDirectory[]. Now, where do you read those IMAGE_DATA_DIRECTORY[]'s? It dosen't fit right after the NumberOfRvaAndSizes.. Rather, it doesn't match up.



EDIT:

Okay, wait! I just read trough my old comments:
Code: [Select]
        // DWORD NumberOfRvaAndSizes                     // [b]The length of the DataDirectory array that follows[/b].                     // 4 bytes
        // IMAGE_DATA_DIRECTORY DataDirectory[]     // An array of IMAGE_DATA_DIRECTORY, lenght = 16                      // 8 bytes * 16

So, am I right if I am supposed to read the next 8 bytes * (NumberOfRvaAndSizes/8) into structures of IMAGE_DATA_DIRECTORY?

15
You have to look at the PE structure. First you have the DOS header, which ha a pointer to the PE header. This one has a pointer to the optional header, where you have the entrypoint address. In C you have those structs to work with, when I have access to my lap I will post an example, if you still need it.

I was up rather late yesterday and read a lot about the PE/COFF structure and its headers, started building some structs and reading in a bit of data to them. I seam to get the hang of it now, but please. Do post examples if you can :)

Pages: [1] 2