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
Thanks
John Paul
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Dr. Stephen Henson
Sent: Wednesday, October 13, 2010 9:59 PM
To: [email protected]
Subject: Re: Incore.gz different signature from target machine
On Wed, Oct 13, 2010, [email protected] wrote:
> I got the FIPS openssl integrated with my application. Unfortunately I
> had to stick to build environment which is on sun solaris and my
> target machine is a powerpc embedded system. Until now I had to
> create the application in solaris machine execute in the target, after
> getting the hmac signature recompiled the fips_premain.c with that
> signature. After checking Dr.Steve's post I tried using incore.gz on
my application.
> Somehow the signatures are different
>
> I noticed that the 'file format' of the object I have is "elf32-big"
> which is not handled in the script. I assume the INCORE_ADJUST should
> be
> -8 for that type of format too. I added that code but still it returns
> a different signature that does not match with the generated signature
> from the target.
>
> Any values I should check between the script's result on the host
> machine vs code loaded in the target to make it match ?
>
There are several ways to do this. One is to not embed a signature and
call the executable on the target: it should then output the expected
signature. You can then tweak the offset so the two match.
Alternatively check out the code in FIPS_incore_fingerprint(). You can
write a simple program to dump the data that OpenSSL fingerprints, then
modify the script to dump the same data for its external fingerprint.
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]
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
