Understanding relocation information
in [Win32 Kernel]
|
Prev: Please tell me do i have a Win32 API which captures capture WinXp DDK DbgPrint messeges
Next: Shutdown dialog window handle ?
From: AG on 8 Mar 2010 09:35 Hi, I couldn't find a more appropriate newsgroup to post this question, so If you think of a better place, please redirect me gently. I am trying to understand how relocation information apply, but I am only half the way. For Image files, I think I am ok. But for COFF relocations, I don't understand the specifications. As far as I understand, relocation information is a field which needs to be modified when the file is loaded. Thus the relocation information is made of three parts: 1°/ the address of the item to which the relocation is applied : let's call it A 2°/ the address to be used for the relocation: let's call it B 3°/ the way the relocation is applied: let's call it f() (a function). Again, the way I understand it, the loader has to fix address A using address B and the function f() as: A = f(B) Is this a correct formalism ? Then if so, I don't understand how the relocation must be applied, as described in the specification. A table is given which I put an extract of below for your convenience: Constant Value Description IMAGE_REL_I386_DIR32 0x0006 The targets 32-bit VA. IMAGE_REL_I386_DIR32NB 0x0007 The targets 32-bit RVA. IMAGE_REL_I386_SECTION 0x000A The 16-bit section index of the section that contains the target. This is used to support debugging information. IMAGE_REL_I386_SECREL 0x000B The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage. IMAGE_REL_I386_TOKEN 0x000C The CLR token. IMAGE_REL_I386_SECREL7 0x000D A 7-bit offset from the base of the section that contains the target. IMAGE_REL_I386_REL32 0x0014 The 32-bit relative displacement to the target. This supports the x86 relative branch and call instructions. In this table, the relocation type is given, followed by its value, and a description of "the way the relocation must be applied". But if I take for instance the first one, I don't understand what "target" is referring to (A or B in my example) and what "The target's 32-bit VA" means. What shall I do with the 32 bit virtual address ? I understand it is a very specific question, but if by chance you have an answer, or a direction to point me to, I would be very grateful. Thanks in advance, Alexandre.
From: m on 8 Mar 2010 19:31 IIRC, the relocation information can be formalized as: C = f(A), where the value located at B is updated from A to C When the loader runs, it uses this information to update various binary values in the loaded image that the compiler / linker set to values assuming the default base address to the correct values for the base address of the loaded image. Since the address space is linear, the transformation function f is a trivial addition (or subtraction), but to work correctly the loader must know both the address in the binary to update as well as the RVA to which it ought to point. The latter could be implied from the value at that location in the binary, but for safety is explicitly specified. IMHO the PE format is well defined, but the loader interactions are poorly documented and difficult for the uninured ;) "AG" <heyji2(a)gmail.com> wrote in message news:20fb43c4-5cb9-4a6b-b101-e0707684eaed(a)g10g2000yqh.googlegroups.com... > Hi, > > I couldn't find a more appropriate newsgroup to post this question, so > If you think of a better place, please redirect me gently. > > I am trying to understand how relocation information apply, but I am > only half the way. For Image files, I think I am ok. But for COFF > relocations, I don't understand the specifications. > > As far as I understand, relocation information is a field which needs > to be modified when the file is loaded. Thus the relocation > information is made of three parts: > > 1�/ the address of the item to which the relocation is applied : let's > call it A > 2�/ the address to be used for the relocation: let's call it B > 3�/ the way the relocation is applied: let's call it f() (a > function). > > Again, the way I understand it, the loader has to fix address A using > address B and the function f() as: > A = f(B) > > Is this a correct formalism ? > > Then if so, I don't understand how the relocation must be applied, as > described in the specification. A table is given which I put an > extract of below for your convenience: > > Constant Value Description > IMAGE_REL_I386_DIR32 0x0006 The target�s 32-bit VA. > IMAGE_REL_I386_DIR32NB 0x0007 The target�s 32-bit RVA. > IMAGE_REL_I386_SECTION 0x000A The 16-bit section index of the section > that contains the target. This is used to support debugging > information. > IMAGE_REL_I386_SECREL 0x000B The 32-bit offset of the target from the > beginning of its section. This is used to support debugging > information and static thread local storage. > IMAGE_REL_I386_TOKEN 0x000C The CLR token. > IMAGE_REL_I386_SECREL7 0x000D A 7-bit offset from the base of the > section that contains the target. > IMAGE_REL_I386_REL32 0x0014 The 32-bit relative displacement to the > target. This supports the x86 relative branch and call instructions. > > In this table, the relocation type is given, followed by its value, > and a description of "the way the relocation must be applied". But if > I take for instance the first one, I don't understand what "target" is > referring to (A or B in my example) and what "The target's 32-bit VA" > means. What shall I do with the 32 bit virtual address ? > > I understand it is a very specific question, but if by chance you have > an answer, or a direction to point me to, I would be very grateful. > > Thanks in advance, > > Alexandre.
From: AG on 9 Mar 2010 04:33 thanks m for the answer. Though according to your explanations, there is only one way (a simple addition) to apply the relocations. But I gave seven different relocation types: IMAGE_REL_I386_* I assume you don't know how they should be interpreted? Alexandre. On Mar 9, 1:31 am, "m" <m...(a)b.c> wrote: > IIRC, the relocation information can be formalized as: > > C = f(A), where the value located at B is updated from A to C > > When the loader runs, it uses this information to update various binary > values in the loaded image that the compiler / linker set to values assuming > the default base address to the correct values for the base address of the > loaded image. Since the address space is linear, the transformation > function f is a trivial addition (or subtraction), but to work correctly the > loader must know both the address in the binary to update as well as the RVA > to which it ought to point. The latter could be implied from the value at > that location in the binary, but for safety is explicitly specified. > > IMHO the PE format is well defined, but the loader interactions are poorly > documented and difficult for the uninured ;) > > "AG" <hey...(a)gmail.com> wrote in message > > news:20fb43c4-5cb9-4a6b-b101-e0707684eaed(a)g10g2000yqh.googlegroups.com... > > > > > Hi, > > > I couldn't find a more appropriate newsgroup to post this question, so > > If you think of a better place, please redirect me gently. > > > I am trying to understand how relocation information apply, but I am > > only half the way. For Image files, I think I am ok. But for COFF > > relocations, I don't understand the specifications. > > > As far as I understand, relocation information is a field which needs > > to be modified when the file is loaded. Thus the relocation > > information is made of three parts: > > > 1 / the address of the item to which the relocation is applied : let's > > call it A > > 2 / the address to be used for the relocation: let's call it B > > 3 / the way the relocation is applied: let's call it f() (a > > function). > > > Again, the way I understand it, the loader has to fix address A using > > address B and the function f() as: > > A = f(B) > > > Is this a correct formalism ? > > > Then if so, I don't understand how the relocation must be applied, as > > described in the specification. A table is given which I put an > > extract of below for your convenience: > > > Constant Value Description > > IMAGE_REL_I386_DIR32 0x0006 The target s 32-bit VA. > > IMAGE_REL_I386_DIR32NB 0x0007 The target s 32-bit RVA. > > IMAGE_REL_I386_SECTION 0x000A The 16-bit section index of the section > > that contains the target. This is used to support debugging > > information. > > IMAGE_REL_I386_SECREL 0x000B The 32-bit offset of the target from the > > beginning of its section. This is used to support debugging > > information and static thread local storage. > > IMAGE_REL_I386_TOKEN 0x000C The CLR token. > > IMAGE_REL_I386_SECREL7 0x000D A 7-bit offset from the base of the > > section that contains the target. > > IMAGE_REL_I386_REL32 0x0014 The 32-bit relative displacement to the > > target. This supports the x86 relative branch and call instructions. > > > In this table, the relocation type is given, followed by its value, > > and a description of "the way the relocation must be applied". But if > > I take for instance the first one, I don't understand what "target" is > > referring to (A or B in my example) and what "The target's 32-bit VA" > > means. What shall I do with the 32 bit virtual address ? > > > I understand it is a very specific question, but if by chance you have > > an answer, or a direction to point me to, I would be very grateful. > > > Thanks in advance, > > > Alexandre.
From: m on 9 Mar 2010 19:19 I suggest that you search MSDN / the web for information on COFF, PE, linking and loading as a complete answer to your question would be very long. In brief, these values tell the loader how to add and if there is any other special handling required for the relocation. "AG" <heyji2(a)gmail.com> wrote in message news:6e44480e-380d-4fe6-aa85-ef3fdc201ada(a)d27g2000yqf.googlegroups.com... > thanks m for the answer. > > Though according to your explanations, there is only one way (a simple > addition) to apply the relocations. But I gave seven different > relocation types: IMAGE_REL_I386_* > I assume you don't know how they should be interpreted? > > Alexandre. > > On Mar 9, 1:31 am, "m" <m...(a)b.c> wrote: >> IIRC, the relocation information can be formalized as: >> >> C = f(A), where the value located at B is updated from A to C >> >> When the loader runs, it uses this information to update various binary >> values in the loaded image that the compiler / linker set to values >> assuming >> the default base address to the correct values for the base address of >> the >> loaded image. Since the address space is linear, the transformation >> function f is a trivial addition (or subtraction), but to work correctly >> the >> loader must know both the address in the binary to update as well as the >> RVA >> to which it ought to point. The latter could be implied from the value >> at >> that location in the binary, but for safety is explicitly specified. >> >> IMHO the PE format is well defined, but the loader interactions are >> poorly >> documented and difficult for the uninured ;) >> >> "AG" <hey...(a)gmail.com> wrote in message >> >> news:20fb43c4-5cb9-4a6b-b101-e0707684eaed(a)g10g2000yqh.googlegroups.com... >> >> >> >> > Hi, >> >> > I couldn't find a more appropriate newsgroup to post this question, so >> > If you think of a better place, please redirect me gently. >> >> > I am trying to understand how relocation information apply, but I am >> > only half the way. For Image files, I think I am ok. But for COFF >> > relocations, I don't understand the specifications. >> >> > As far as I understand, relocation information is a field which needs >> > to be modified when the file is loaded. Thus the relocation >> > information is made of three parts: >> >> > 1 / the address of the item to which the relocation is applied : let's >> > call it A >> > 2 / the address to be used for the relocation: let's call it B >> > 3 / the way the relocation is applied: let's call it f() (a >> > function). >> >> > Again, the way I understand it, the loader has to fix address A using >> > address B and the function f() as: >> > A = f(B) >> >> > Is this a correct formalism ? >> >> > Then if so, I don't understand how the relocation must be applied, as >> > described in the specification. A table is given which I put an >> > extract of below for your convenience: >> >> > Constant Value Description >> > IMAGE_REL_I386_DIR32 0x0006 The target s 32-bit VA. >> > IMAGE_REL_I386_DIR32NB 0x0007 The target s 32-bit RVA. >> > IMAGE_REL_I386_SECTION 0x000A The 16-bit section index of the section >> > that contains the target. This is used to support debugging >> > information. >> > IMAGE_REL_I386_SECREL 0x000B The 32-bit offset of the target from the >> > beginning of its section. This is used to support debugging >> > information and static thread local storage. >> > IMAGE_REL_I386_TOKEN 0x000C The CLR token. >> > IMAGE_REL_I386_SECREL7 0x000D A 7-bit offset from the base of the >> > section that contains the target. >> > IMAGE_REL_I386_REL32 0x0014 The 32-bit relative displacement to the >> > target. This supports the x86 relative branch and call instructions. >> >> > In this table, the relocation type is given, followed by its value, >> > and a description of "the way the relocation must be applied". But if >> > I take for instance the first one, I don't understand what "target" is >> > referring to (A or B in my example) and what "The target's 32-bit VA" >> > means. What shall I do with the 32 bit virtual address ? >> >> > I understand it is a very specific question, but if by chance you have >> > an answer, or a direction to point me to, I would be very grateful. >> >> > Thanks in advance, >> >> > Alexandre. >
From: Pavel A. on 9 Mar 2010 19:38
Have you looked at PE loader code of Wine, Reactos? --pa "AG" <heyji2(a)gmail.com> wrote in message news:20fb43c4-5cb9-4a6b-b101-e0707684eaed(a)g10g2000yqh.googlegroups.com... > Hi, > > I couldn't find a more appropriate newsgroup to post this question, so > If you think of a better place, please redirect me gently. > > I am trying to understand how relocation information apply, but I am > only half the way. For Image files, I think I am ok. But for COFF > relocations, I don't understand the specifications. > > As far as I understand, relocation information is a field which needs > to be modified when the file is loaded. Thus the relocation > information is made of three parts: > > 1�/ the address of the item to which the relocation is applied : let's > call it A > 2�/ the address to be used for the relocation: let's call it B > 3�/ the way the relocation is applied: let's call it f() (a > function). > > Again, the way I understand it, the loader has to fix address A using > address B and the function f() as: > A = f(B) > > Is this a correct formalism ? > > Then if so, I don't understand how the relocation must be applied, as > described in the specification. A table is given which I put an > extract of below for your convenience: > > Constant Value Description > IMAGE_REL_I386_DIR32 0x0006 The target's 32-bit VA. > IMAGE_REL_I386_DIR32NB 0x0007 The target's 32-bit RVA. > IMAGE_REL_I386_SECTION 0x000A The 16-bit section index of the section > that contains the target. This is used to support debugging > information. > IMAGE_REL_I386_SECREL 0x000B The 32-bit offset of the target from the > beginning of its section. This is used to support debugging > information and static thread local storage. > IMAGE_REL_I386_TOKEN 0x000C The CLR token. > IMAGE_REL_I386_SECREL7 0x000D A 7-bit offset from the base of the > section that contains the target. > IMAGE_REL_I386_REL32 0x0014 The 32-bit relative displacement to the > target. This supports the x86 relative branch and call instructions. > > In this table, the relocation type is given, followed by its value, > and a description of "the way the relocation must be applied". But if > I take for instance the first one, I don't understand what "target" is > referring to (A or B in my example) and what "The target's 32-bit VA" > means. What shall I do with the 32 bit virtual address ? > > I understand it is a very specific question, but if by chance you have > an answer, or a direction to point me to, I would be very grateful. > > Thanks in advance, > > Alexandre. |