Skip to main content

Procedure Linkage Table And Global Offset Table

 It's a way to get code fixups without having to maintain a separate copy of the code for each process. The PLT is the procedure linkage table, one of the structures which makes dynamic loading easier to use.
printf@plt is actually a small stub which calls the real printf function. This real function may be mapped into any location in a given virtual address space so, in order to allow proper code sharing of your own code (left side below), you don't want to apply the fixups to it directly since it too can be mapped anywhere in the virtual address space.

The plt variant is a smaller process-specific area which isn't shared so a given process can change that however it wants to.
In other words:
         Mapped to: 0x12345678       0x90000000   0x88888888
        +-------------------------+ +----------+ +---------------------+
        |                         | | Private  | |                     |
ProcA   |                         | |  PLT/GOT | |                     |
        |                         | |   area   | |                     |
        |                         | +----------+ |                     |
========| Shared application code |==============| Shared library code |========
        |                         | +----------+ |                     |
        |                         | | Private  | |                     |
ProcB   |                         | |  PLT/GOT | |                     |
        |                         | |   area   | |                     |
        +-------------------------+ +----------+ +---------------------+
         Mapped to: 0x20202020       0x90000000   0x66666666
This is a simple case where the PLT maps to a known location. In your scenario, it appears to be located relative to the current program counter so it's probably a separate section following the shared application code.Example:
<printf@plt+0>:  jmpq  *0x2004c2(%rip)  # 0x600860 <_GLOBAL_OFFSET_TABLE_+24>
It's clearly using a program-counter-relative lookup to find the actual printf function. That _GLOBAL_OFFSET_TABLE_ will hold fix-ups for as many functions as needed.
Another good article can be found here, detailing how glibc is loaded at runtime.
Basically, the original way in which libraries were made meant that they had to be loaded at the same memory location in the virtual address space of every process that used them. Either that or they couldn't be shared, since the act of fixing up the single shared copy for one process would totally stuff up another process where it was mapped to a different location.
By using position independent code, along with a global offset table (GOT) and the PLT, the first call to printf@plt (in the PLT) is a multi-stage operation, in which:
  • you call printf@plt in the PLT.
  • it calls the GOT version which initially points back to some set-up code in the PLT.
  • that set-up code modifies the GOT so that subsequent calls don't use the setup code (instead they go directly to the real printf).

On subsequent calls, because the GOT has been modified:
  • you call printf@plt in the PLT.
  • it calls the GOT version which points to the real printf.


Popular posts from this blog

Hacking Windows 10 UWP App: DLL Injection & common Vulnerabilities

I recently started working on  widows 10 Apps( Apps not Applications) security. Before diving deep in hacking terms lets try to understand what's new in Windows 10 UWP( Universal Platform) as compared to old Apps. Lets begin with how apps actually work on windows 10(desktop/tablet). Now windows 10 comes with a container only for running apps inside the isolated environment. By default, /APPCONTAINER(Linker Flag) is off. This option modifies an executable to indicate whether the app must be run in the appcontainer process-isolation environment. Specify /APPCONTAINER for an app that must run in the appcontainer environment—for example, a Windows Store app. (The option is set automatically in Visual Studio when you create a Windows Store app from a template.) For a desktop app, specify /APPCONTAINER:NO or just omit the option. The /APPCONTAINER option was introduced in Windows 8. Now there is no registry entry concept for these app in the System HIVE rather they install they own hiv

Animated Cursor Vulnerability

Step1: create two file on attacker side 1) default index.html and 2) cursor file to load Now save the proof of concept in a txt file(cursor.txt). use above command to cut down the hex part from proof of concept and paste it in buffer.ani Step2 :upload the above two files in your apache webserver.  Step3: Try to open index.html from window-xp and analyse the behavior of IE using ollydgb in order to find the offset address where EIP will get over written. Attach IE in ollydgb and put malicious url in it. As we can see now that EIP is overwritten with 42424242 that means this place is our offset. Now we will put the address of jump instruction in place of 42424242 which we will get from user32.dll by searching for command JUMP DWORD [EBX],now we jumped at ebx because it contain the malicious .ani file address. Just go into view=>executable=>user32.dll , press enter. Now try to find a jump [ebx] instruction in user32.dll by pressing ctrl

Assignment 01(Enroll TO Offensive-Security Course)

Steps 1:download the page. 2:open fc4.js in your favourite editor and add following lines in it or just replace it with vode given below. 3:then open the download html file in browser and fill the form with your email and a garbage value string. 4:thats it? it will show you the real security string?? yeah but  ...theirs another challenge waiting for you ... :D function fc4me(srvstr) {    if(! || !document.pleazfc4me.securitystring.value) {       alert("Please fill in all the required fields!");       return false;    }    else {       document.pleazfc4me.submit();     }    var t=hexMD5("\x74\x72\x79\x68\x61\x72\x64\x65\x72"+srvstr) alert(t) document.write(t) } Finally Got In :-)