Android Roaming note (3)---relocation Got & PLT & R_arm_jump_slot

The dynamic Link tool for the Android system is/system/bin/linker (the General Linux system is ld.so), although the names are different, but the basic dynamic linking process is similar. It is important to note that Linux is generally lazy, the so-called "lazy" loading mode, but the Android system is a bit different, the non-lazy way, that is, all the relocation operations, before the first execution of the process has been completed. This is probably one of the reasons why Android apps are slow to start for the first time!

About the PLT and got of the android system can be written on a college entrance examination as, here do not mention the concept of things, there is a blog online: http://www.codeproject.com/Articles/70302/ Redirecting-functions-in-shared-elf-libraries, this article is based on the I386 architecture, and arm is different, but the principle is the same. If there are students interested in the following content, you can first go to see, the basic things first clear, this may be smooth, of course, it is best to know some arm assembly ~ ~ ~

Still the old habit, I will write a small demo directly also demonstrates how the Android system linker is handling the relocation, of course, the type of elf relocation is very much, we focus here: R_arm_jump_slot (386 architecture called R_386_jump_slot, It's like, isn't it? This type of relocation is generally referred to external functions, that is, you want to reference an externally defined function symbol, linker when loading your application, you need to apply this type of relocation, to complete the symbolic to the real function of the link!

For example, if your application needs to print a piece of text to an interrupt, you might call libc.so the C library's puts function. This is an external reference, so there must be a R_arm_jump_slot relocation information in your application for puts calls.

First, a very small program:

/* *  plt&got Resolver *  Created on:2014-6 * author:chris.z * *  #include <stdio.h> #include < stdlib.h>/** * Define the Local method * */void Local_method_call () {     printf ("[+]i ' M local method.\n");} int main () {    //printf ("[+]plt&got resolver...\n");    Local_method_call ();    Call puts to check R_arm_jump_slot    puts ("[+]call the method of puts from libc.\n");    GetChar ();    return 0;}

This program does not do other things, is called the puts output a text, where the puts is defined in the Libc.so library. Perfectly formed, we verify how linker is implemented for puts "dynamic link".

First use readelf to look at the elf content of the binary files generated by the program (Interception section):

Note the arrows in the pointed, exactly what we call the R_arm_jump_slot relocation, located in the. Rel.plt area. Note that the first column of offset in this line of information, the value is 0x9ff8, is recorded first and will be used later.

We actually run the above applet dynamically, while using GDB to attach to the process for remote dynamic debugging (GDB is a big artifact of Android system-level debugging!). ）。

Since we want to look at the details of the execution of the instruction, we need to do assembly-level debugging, after entering GDB, after entering the remote target:p ort, enter the GDB prompt, we enter Disas main to see the disassembly code of the main function:

> Disas Maindump of Assembler code for function main:0x00008378 <+0>:p ush{r3, R4, R11, LR} 0x0000837c <+4 >:addr11, sp, #12 = 0x00008380 <+8>:ldrr4, [pc, #124]; 0x8404 <main+140>, current PC register refers to location 0x00008384 &LT;+12&GT;:ADDR4, PC, R4 0x00008388 <+16>:ldrr3, [pc, #120]; 0x8408 <main+144> 0x0000838c &LT;+20&GT;:ADDR3, PC, R3 0x00008390 <+24>:movr0, R3 0x00008394 <+28> : bl0x82b0; jump to puts call!!! <============== 0x00008398 &LT;+32&GT;:LDRR3, [pc, #108]; 0x840c <main+148> 0x0000839c &LT;+36&GT;:LDRR3, [R4, R3] 0x000083a0 &LT;+40&GT;:LDRR3, [R3, #4] 0X000083A4 &lt ; +44>:subr2, R3, #1 0x000083a8 <+48>:ldrr3, [pc, #92]; 0x840c <main+148> 0x000083ac &LT;+52&GT;:LDRR3, [R4, R3] 0x000083b0 &LT;+56&GT;:STRR2, [R3, #4] 0X000083B4 &lt ; +60>:ldrr3, [PC, #80]; 0x840c <main+148> 0x000083b8 &LT;+64&GT;:LDRR3, [R4, R3] 0X000083BC &LT;+68&GT;:LDRR3, [R3, #4] 0x000083c0 &lt ; +72&GT;:CMPR3, #0 0x000083C4 <+76>:bge0x83dc <main+100> 0x000083c8 <+80>:ldrr3, [pc, #60]; 0x840c <main+148> 0x000083cc &LT;+84&GT;:LDRR3, [R4, R3] 0x000083d0 <+88>:movr0, R3 0x000083d4 &LT;+92&G T;:BL0X82BC 0x000083d8 <+96>:b0x83f8 <main+128> 0x000083dc <+100>:ldrr3, [pc, #40]; 0x840c <main+148> 0x000083e0 &LT;+104&GT;:LDRR3, [R4, R3] 0x000083e4 &LT;+108&GT;:LDRR3, [R3] 0x000083e8 <+ 112&GT;:ADDR2, R3, #1 0x000083ec <+116>:ldrr3, [pc, #24]; 0x840c <main+148> 0x000083f0 &LT;+120&GT;:LDRR3, [R4, R3] 0x000083f4 &LT;+124&GT;:STRR2, [R3] 0x000083f8 <+ 128&GT;:MOVR3, #0 0x000083fc <+132>:movr0, R3 0x00008400 <+136>:p op{r3, R4, R11, PC} 0x00008404 <+140 &GT;:ANDEQR1, R0, R8, ASR R12 0x00008408 <+144>:andeqr0, R0, R12, LSR #1 0x0000840c <+148>:; <UNDEFINED> instruction:0xfffffffcend of Assembler dump.

Notice the red part of my note, the BL instruction is to jump to puts (of course, see below, actually jump to the PLT area first). We execute B *0x8394, place the breakpoint at the BL command, and then the C command continues execution.

Then we execute x/i $pc see if the current instruction is executed to our breakpoint:

> display/i $pc > x/i $pc = 0x8394 <main+28>:bl0x82b0

OK, it's true that in the 0x8394, we stop here to check out some important information.

First we look at the 0x00008394 <+28>: bl0x82b0 This line of assembly, it means with a link to jump to 0x82b0 execution, then 0x82b0 exactly what instructions?

Execute Disas 0x82b0,0x82c0, output as follows:

> Disas 0x82b0,0x82c0dump of Assembler code from 0X82B0 to 0x82c0:   0x000082b0:addr12, PC, #0   0x000082b4:addr12 , R12, #4096; 0x1000   0x000082b8:ldrpc, [R12, #3392]!; 0XD40 jump to libc.so puts entrance <span style= "font-family:arial, Helvetica, Sans-serif; " ><==============</span>   0x000082bc:addr12, PC, #0End of assembler dump.

The previous two instructions we ignore the past (mainly calculated. Got offset), we directly execute to 0X82B8, namely superscript red instructions.

A simple explanation of the directive meaning: the memory word that R12+0XD40 points to is loaded into the PC register, actually jumps to that address.

Let's see what the value of R12+0XD40 is at this time, execute p/x $r 12+0XD40:

1:x/i $pc = 0x82b8:ldrpc, [R12, #3392]!; 0xd40> p/x $r 12+0xd40$1 = 0x9ff8

See, this 0x9ff8 is exactly the address we recorded above!

We are executing the info symbol 0X9FF8 command:

> Info symbol 0x9ff8_global_offset_table_ + section. Got

Here, let's make a brief summary:

Elf files in the. Rel.plt area, the offset of the R_arm_jump_slot type is the. Got area the address of the symbol, which is located at the Got table base, is offset by 20 bytes (in this case, the Got table base is 0x9fe4).
To illustrate, there is a difference in how the executable and. So dynamic link libraries are computed. So needs to be added to the module base at the time of loading.

Below, we are looking at. What's in Got's 0X9FF8:

Perform p/x *0X9FF8:

> p/x *0x9ff8$2 = 0x4011a7dc         puts true entry address <====================

We're in control of the maps of the process:

It is the address of libc.so, which is actually puts's function entry address! All right, I'll write it down here today, Enjoy it!.

Reprint please indicate the Source: Life Show