Re: [DynInst_API:] BPatch_binaryEdit openBinary crashing


Date: Fri, 06 Feb 2015 23:39:59 +0100
From: Aleksandar Nikolic <nikolic.alek@xxxxxxxxx>
Subject: Re: [DynInst_API:] BPatch_binaryEdit openBinary crashing
Ah, I see.
Thanks for a quick response.
Keep up the good work.


On 02/06/2015 11:36 PM, Bill Williams wrote:
> On 02/06/2015 04:20 PM, Aleksandar Nikolic wrote:
>> Hello list,
>>
>>
>> I've been trying to use Dyninst to instrument a binary on Windows 7.
>> There are some problems I'm having and I was wondering if it's a bug
>> or I am doing something wrong.
>>
> No, and not exactly. Windows binary rewriting is not supported, and is
> documented as such. If it were to be supported, what you are doing would
> work quite reasonably.
> 
> Note to self: apparently we need to verify/hard-exit in openBinary on
> Windows. Stupid assert semantics.
> 
>> What follows are some details.
>>
>> I've built Dyninst 8.2.1 on Windows 7 (32bit) with VS2010 and SDK 7.1,
>> with boost and debugging tools properly installed.
>>
>> To test it, I've built and compiled the "retee" example
>> from the API manual and it works correctly.
>>
>> My problems start when I try to open the binary using BPatch API.
>> I'd like to add some instrumentation to the binary and write it
>> back to the disk.
>> Simply doing
>>      BPatch_binaryEdit *appBin = bpatch.openBinary ("pathtobin.exe",
>> true);
>> causes a crash (specifying either true or false for loading libraries
>> makes
>> no difference).
>>
>> Here is the output with DYNINST_DEBUG_STARTUP enabled:
>>
>> Enabling DyninstAPI startup debug
>> [2644][BPatch_binaryEdit.C:89] - Opening original file calc.exe
>> [2644]mapped_object.C[146]:  about to parseImage
>> [2644]mapped_object.C[148]: name calc.exe, codeBase 0x0, dataBase 0x0
>> [2644]image.C[1067]:  about to create image
>> [2644]image.C[1296]: opening file calc.exe
>> [2644]image.C[1353]:  before findMain
>> [2644][src\image.C:761] - findmain could not find symbol for main, using
>> binary
>> entry point 12d6c
>> [2644]image.C[1384]:  before determineImageType
>> [2644]image.C[1069]:  created image
>> [2644]image.C[1074]: processing executable object
>> [2644]mapped_object.C[195]:  creating mapped object
>> [2644][mapped_object.C:105] Creating new mapped_object calc.exe/
>> [2644][mapped_object.C:107]     codeBase 0x0, codeOffset 0x1000, size
>> 339105
>> [2644][mapped_object.C:109]     dataBase 0x0, dataOffset 0x54000, size
>> 16576
>> [2644][mapped_object.C:111]     fileDescriptor: code at 0x0, data 0x0
>> [2644][mapped_object.C:113]     Code: 0x1000 to 0x53ca1
>> [2644][mapped_object.C:115]     Data: 0x54000 to 0x580c0
>> [2644]mapped_object.C[200]:  leaving createMappedObject(calc.exe)
>> [2644]mapped_object.C[146]:  about to parseImage
>> [2644]mapped_object.C[148]: name C:\Program
>> Files\Dyninst\lib\dyninstAPI_RT.dll,
>>   codeBase 0x0, dataBase 0x0
>> [2644]image.C[1067]:  about to create image
>> [2644]image.C[1296]: opening file C:\Program
>> Files\Dyninst\lib\dyninstAPI_RT.dll
>>
>> [2644]image.C[1353]:  before findMain
>> [2644]image.C[1384]:  before determineImageType
>> [2644]image.C[1069]:  created image
>> [2644]image.C[1072]: processing shared object
>> [2644]mapped_object.C[195]:  creating mapped object
>> [2644][mapped_object.C:105] Creating new mapped_object C:\Program
>> Files\Dyninst\
>> lib\dyninstAPI_RT.dll/
>> [2644][mapped_object.C:107]     codeBase 0x0, codeOffset 0x1000, size
>> 7166
>> [2644][mapped_object.C:109]     dataBase 0x0, dataOffset 0x5000, size 512
>> [2644][mapped_object.C:111]     fileDescriptor: code at 0x0, data 0x0
>> [2644][mapped_object.C:113]     Code: 0x1000 to 0x2bfe
>> [2644][mapped_object.C:115]     Data: 0x5000 to 0x5200
>> [2644]mapped_object.C[200]:  leaving createMappedObject(C:\Program
>> Files\Dyninst
>> \lib\dyninstAPI_RT.dll)
>>
>> So, it crashes after loading the dyninstAPI_RT.dll.
>> Digging further into the source reveals that the crash
>> happens because of an read access violation during memcpy
>> that is being called via BinaryEdit::createMemoryBackingStore
>> () in binaryEdit.C. Specifically, it happens on creating
>> a new memory tracker on line 763 for ".data" segment.
>> One thing to note is that the .data segment of the dyninstAPI_RT.dll
>> has a somewhat big
>> virtual size value 0x01484BF4 which ends up being a size param of the
>> memcpy...
>> Another thing, the compiled binary doesn't have .bss segment.
>>
>> Does the binary rewriting API not work on Windows or am I doing
>> something wrong?
>>
>> I've also tried the latest published build for windows on your site
>> (version 8.1.2)
>> with the same results.
>>
>> Thanks,
>> Aleksandar
>>
>>
>> _______________________________________________
>> Dyninst-api mailing list
>> Dyninst-api@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>
> 
> 
[← Prev in Thread] Current Thread [Next in Thread→]