On Thu, Oct 14, 2010, [email protected] wrote: > Thanks Steve, > > Following the FIPS_incore_fingerprint() gave a good insight about the > data that is taken for calculating the digest. After dumping the data > once in the target I was able to adjust the offset. But still I see > binary content is slightly differed in the executable before loading and > the content in the memory > > For eg the objdump information in the openssl lib before loading > > 000e4100 <FIPS_text_start>: > e4100: 4b ff ff ec b e40ec <instruction_pointer> > > 000e4104 <fips_set_mode>: > e4104: 7d 80 00 26 mfcr r12 > e4108: 94 21 ff e8 stwu r1,-24(r1) > e410c: 7c 08 02 a6 mflr r0 > e4110: 93 e1 00 14 stw r31,20(r1) > e4114: 7c 7f 1b 78 mr r31,r3 > e4118: 93 a1 00 0c stw r29,12(r1) > e411c: 90 01 00 1c stw r0,28(r1) > e4120: 91 81 00 08 stw r12,8(r1) > e4124: 48 00 00 01 bl e4124 <fips_set_mode+0x20> > e4128: 7c 7d 1b 78 mr r29,r3 > e412c: 48 00 00 01 bl e412c <fips_set_mode+0x28> > e4130: 2f 83 00 00 cmpwi cr7,r3,0 > e4134: 2e 1d 00 00 cmpwi cr4,r29,0 > e4138: 41 9e 00 14 beq- cr7,e414c <fips_set_mode+0x48> > e413c: 41 92 00 38 beq- cr4,e4174 <fips_set_mode+0x70> > e4140: 3d 20 00 00 lis r9,0 > e4144: 93 e9 00 00 stw r31,0(r9) > e4148: 41 92 00 24 beq- cr4,e416c <fips_set_mode+0x68> > e414c: 80 01 00 1c lwz r0,28(r1) > e4150: 81 81 00 08 lwz r12,8(r1) > . > . > . > > Whereas the objdump from the memory > > FIPS_text_start: > 0x9f1700 4bffffec b 0x9f16ec # instruction_pointer > fips_set_mode: > 0x9f1704 7d800026 mfcr r12 > 0x9f1708 9421ffe8 stwu r1,-24(r1) > 0x9f170c 7c0802a6 mfspr r0,LR > 0x9f1710 93e10014 stw r31,20(r1) > 0x9f1714 7c7f1b78 or r31,r3,r3 > 0x9f1718 93a1000c stw r29,12(r1) > 0x9f171c 9001001c stw r0,28(r1) > 0x9f1720 91810008 stw r12,8(r1) > 0x9f1724 480008e5 bl 0x9f2008 # fips_is_owning_thread > value = 10426152 = 0x9f1728 = fips_set_mode + 0x24 > Working: [Kernel]->l > 0x9f1728 7c7d1b78 or r29,r3,r3 > 0x9f172c 480008d1 bl 0x9f1ffc # fips_is_started > 0x9f1730 2f830000 cmpi crf7,0,r3,0x0 # 0 > 0x9f1734 2e1d0000 cmpi crf4,0,r29,0x0 # 0 > 0x9f1738 419e0014 bc 0xc,30, 0x9f174c # 0x009f174c > 0x9f173c 41920038 bc 0xc,18, 0x9f1774 # 0x009f1774 > 0x9f1740 3d200e86 lis r9,0xe86 # 3718 > 0x9f1744 93e9ce40 stw r31,-12736(r9) > 0x9f1748 41920024 bc 0xc,18, 0x9f176c # 0x009f176c > 0x9f174c 8001001c lwz r0,0x1c(r1) # 28 > value = 10426192 = 0x9f1750 = fips_set_mode + 0x4c > Working: [Kernel]->l > 0x9f1750 81810008 lwz r12,0x8(r1) # 8 > > > The branching instructions and the offset to store the return address > from the r31 are changed while loading in to memory, thus the resulting > digest in both case are different. I guess this is normal when the ELF > are relocated after loading or do I miss any option while compiling. > > I would appreciate any help/clue on this >
Well your other option is to change the signature script to something that copies it to the target system, executes it and returns the signature. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
