Security Summer School

User Tools

Site Tools

session:03

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:03 [2020/06/24 16:05]
Razvan Deaconescu 		session:03 [2020/07/19 12:49] (current)
Line 1: Line 1:
 ====== 0x02. Executable File Formats ====== ====== 0x02. Executable File Formats ======
  
-== Resources+===== Resources =====
  
 [[https://security.cs.pub.ro/summer-school/res/slides/03-executable-file-formats.pdf|Session 2 slides]] [[https://security.cs.pub.ro/summer-school/res/slides/03-executable-file-formats.pdf|Session 2 slides]]
Line 52: Line 52:
 There are several ELF types but the most common types we will be dealing with are:   There are several ELF types but the most common types we will be dealing with are:  
  
-* Relocatable Files +  * Relocatable Files 
-* Executable Files +  * Executable Files 
-* Shared Objects+  * Shared Objects
  
 === Relocatable Files === === Relocatable Files ===
Line 94: Line 94:
 All libraries should adhere to a strict naming convention.  All libraries should adhere to a strict naming convention. 
 Shared objects have two names: Shared objects have two names:
-* **soname** - that consists of the prefix //lib// followed by the library name, a //.so// , another dot, then the major version (ex:libtest.so.1) +  * **soname** - that consists of the prefix //lib// followed by the library name, a //.so// , another dot, then the major version (ex:libtest.so.1) 
-* **real name** - is actually a file name, that usually adds a dot and minor version number along with the release version (ex: libtest.so.1.23.3)+  * **real name** - is actually a file name, that usually adds a dot and minor version number along with the release version (ex: libtest.so.1.23.3)
 Additionally, each library source file should have an accompanying header file with the extension //.h// and the same name. Additionally, each library source file should have an accompanying header file with the extension //.h// and the same name.
  
Line 127: Line 127:
  
 <note important> <note important>
-** The chapters on ELF structure are not meant to be known by heart, don't try and read them all in one breath, but rather use them as a reference for the exercises **+    * The chapters on ELF structure are not meant to be known by heart, don't try and read them all in one breath, but rather use them as a reference for the exercises **
  
 **Tools of the trade** **Tools of the trade**
-* [[http://mylinuxbook.com/readelf-command/|readelf]] +  * [[http://mylinuxbook.com/readelf-command/|readelf]] 
-* [[http://sourceware.org/binutils/docs/binutils/objdump.html|objdump]] +  * [[http://sourceware.org/binutils/docs/binutils/objdump.html|objdump]] 
-* [[http://gsp.com/cgi-bin/man.cgi?section=1&topic=ldd|ldd]]+  * [[http://gsp.com/cgi-bin/man.cgi?section=1&topic=ldd|ldd]]
 Because IDA is expensive and rarely found on machines you just hacked Because IDA is expensive and rarely found on machines you just hacked
  
Line 284: Line 284:
 </code> </code>
  
-* **Name** - is obtained by reading the value of the section names table at the specified index +  * **Name** - is obtained by reading the value of the section names table at the specified index 
-* **Type**+  * **Type**
       * **PROGBITS** - information that is given meaning by the program when loaded into memory       * **PROGBITS** - information that is given meaning by the program when loaded into memory
       * **NOBITS** - similar to PROGBITS in meaning but occupies no space in the file       * **NOBITS** - similar to PROGBITS in meaning but occupies no space in the file
Line 293: Line 293:
       * **DYNSYM** - holds a set of symbols used in the dynamic linking process       * **DYNSYM** - holds a set of symbols used in the dynamic linking process
       * **REL** - holds relocation entries       * **REL** - holds relocation entries
-* **Addr** - if the section is part of an executable it will hold the virtual address where the section could be found in memory. If not it would be 0. +  * **Addr** - if the section is part of an executable it will hold the virtual address where the section could be found in memory. If not it would be 0. 
-* **Off** - offset from the beginning of the file to where the section starts +  * **Off** - offset from the beginning of the file to where the section starts 
-* **Size** - size of the section in bytes +  * **Size** - size of the section in bytes 
-* **ES** - size in bytes per entry, if fixed entry size is used +  * **ES** - size in bytes per entry, if fixed entry size is used 
-* **FLG**+  * **FLG**
   * **X** - contains executable code   * **X** - contains executable code
   * **W** - contains writable code   * **W** - contains writable code
   * **A** - will be loaded into memory as-is during process execution   * **A** - will be loaded into memory as-is during process execution
-* **Al** - section alignment constraints+  * **Al** - section alignment constraints
  
 **Inf** and **Lnk** have specific interpretations depending on the section type **Inf** and **Lnk** have specific interpretations depending on the section type
Line 427: Line 427:
 Relocations and how they get applied are very complex topic and we will only try to cover as far is helps detecting file and symbol types Relocations and how they get applied are very complex topic and we will only try to cover as far is helps detecting file and symbol types
 If you want to read more you can refer to some of these resources: If you want to read more you can refer to some of these resources:
-* [[http://www.mindfruit.co.uk/2012/06/relocations-relocations.html|Some Assembly Required]] +  * [[http://www.mindfruit.co.uk/2012/06/relocations-relocations.html|Some Assembly Required]] 
-* [[http://netwinder.osuosl.org/users/p/patb/public_html/elf_relocs.html|Study Of ELF Loading and Relocs]]+  * [[http://netwinder.osuosl.org/users/p/patb/public_html/elf_relocs.html|Study Of ELF Loading and Relocs]]
  
 </note> </note>
Line 459: Line 459:
 </code> </code>
  
-* **Offset** - In relocatable files and linked shared objects it contains the offset from the beginning of the section , where the relocation needs to be applied +  * **Offset** - In relocatable files and linked shared objects it contains the offset from the beginning of the section , where the relocation needs to be applied 
-* **Info** - This field is used to derive the index in the symbol table to the affected symbol as well as the algorithm needed for fixing.+  * **Info** - This field is used to derive the index in the symbol table to the affected symbol as well as the algorithm needed for fixing.
   * **info>>8** - symbol table index   * **info>>8** - symbol table index
   * **info&0xff** - algorithm type as defined in the documentation   * **info&0xff** - algorithm type as defined in the documentation
Line 468: Line 468:
 By looking at the types of relocations we can draw some basic conclusions about the symbol types and also about the files. By looking at the types of relocations we can draw some basic conclusions about the symbol types and also about the files.
  
-* **Reloctable Files**+  * **Reloctable Files**
   * **R_386_32 ** - usually used to reference changes to a local symbol   * **R_386_32 ** - usually used to reference changes to a local symbol
   * **R_386_PC32 ** - reference a relative distance from here to the symbol   * **R_386_PC32 ** - reference a relative distance from here to the symbol
-* **Relocatable Files for Shared object **+  * **Relocatable Files for Shared object **
   * **R_386_GOTOFF** - usually found in the code area, describes the offset from the beginning of GOT to a local symbol   * **R_386_GOTOFF** - usually found in the code area, describes the offset from the beginning of GOT to a local symbol
   * **R_386_GOT32 ** - also speicific to the code area. These entries persist in the linkage phase   * **R_386_GOT32 ** - also speicific to the code area. These entries persist in the linkage phase
   * **R_386_PLT32 ** - used when describing calls to global subroutines. when the linker will read this information it will generate an entry in the **GOT** and **PLT** tables   * **R_386_PLT32 ** - used when describing calls to global subroutines. when the linker will read this information it will generate an entry in the **GOT** and **PLT** tables
   * **R_386_GOTPC** - used in function to calculate the start address of the  **GOT**   * **R_386_GOTPC** - used in function to calculate the start address of the  **GOT**
-* **Executables that use dynamic linking **+  * **Executables that use dynamic linking **
   * **R_386_JMP** - the dynamic linker will deposit the address of the external subroutine during execution   * **R_386_JMP** - the dynamic linker will deposit the address of the external subroutine during execution
   * **R_386_COPY** - the address of global variable from  shared object will be deposited here   * **R_386_COPY** - the address of global variable from  shared object will be deposited here
-* **Shared object files **+  * **Shared object files **
   * **R_386_JMP** - the dynamic linker will deposit the address of the external subroutine from one of the shared object dependencies during execution   * **R_386_JMP** - the dynamic linker will deposit the address of the external subroutine from one of the shared object dependencies during execution
   * **R_386_GLOB_DATA** - used to deposit the address of a global symbol defined in one of the shared object dependencies   * **R_386_GLOB_DATA** - used to deposit the address of a global symbol defined in one of the shared object dependencies
Line 485: Line 485:
  
 <note important> <note important>
-** Executable files that are statically linked do not contain relocations **+    * Executable files that are statically linked do not contain relocations **
 </note> </note>
    
Line 987: Line 987:
  
 Use proper compiler/linker flags/options to create a running executable for ''flag1.o'' and ''caller.c'' and for ''flag2.o'' and ''caller.c''. Submit the flag [[https://sss-ctf.security.cs.pub.ro/challenges|on the platform]]. Use proper compiler/linker flags/options to create a running executable for ''flag1.o'' and ''caller.c'' and for ''flag2.o'' and ''caller.c''. Submit the flag [[https://sss-ctf.security.cs.pub.ro/challenges|on the platform]].
 +
 +<note tip>
 +It's the same flag, it's just to make sure you are able to find the flag with both formats of the ''flag*.o'' object files.
 +</note>
  
 ==== 05. Print Flag ==== ==== 05. Print Flag ====
Line 1030: Line 1034:
 </note> </note>
  
-=== Further pwning+==== Further pwning ====
  
 [[http://crackmes.cf/users/geyslan/crackme.02.32/]] is a challenge that will test your knowledge from the first three sessions. The password for the archive is '''crackmes.de'''. [[http://crackmes.cf/users/geyslan/crackme.02.32/]] is a challenge that will test your knowledge from the first three sessions. The password for the archive is '''crackmes.de'''.
  
session/03.1593003915.txt.gz · Last modified: 2020/06/24 16:05 by Razvan Deaconescu

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki