I seem to have tracked down the cause of all my issues, at least partialy, to this piece of code in binaryEdit:
base += (1024*1024); base -= (base & (1024*1024-1)); in openFile Now, this base adjustment clearly has a purpose, but if commented out, the instrumented PE file that is produced has a good import table and good trampolines to instrumentation code. I guess it's required for opening other (non PE) files? On 02/25/2015 07:59 PM, Bill Williams wrote: > >>> I'll take a look at the patches over the next couple of days, but this >>> all sounds very promising. >>> >>> I don't have a definite answer for the trampoline issue, but I'd look at >>> whether there's a similar issue to the one with the imports where we >>> generated branches before .dyninst was fixed and didn't recalculate >>> them. The springboard code is very good at doing what it's told, so I'd >>> strongly suspect that we moved the section of relocated code after we >>> generated springboards. >>> >> >> It would seem that that is the case. If if fix the base address >> "manually", it sort of works. As my patch for imports is hacky, is >> there a part of the API that does the recalculations or should I do >> them myself? >> > If memory serves, what we do on Linux is ensure that .dyninstInst is > created somewhere fixed (end of the binary, more or less), so that we > can actually generate the code correctly at instrumentation time. That's > going to be the safest/easiest approach, I think--otherwise we might > need to replace 5-byte near branches with longer code sequences and > wholly regenerate the section contents. > >> >>>> Cheers, >>>> Alex >>>> >>>> On 02/11/2015 06:20 PM, Matthew LeGendre wrote: >>>>> >>>>> At one point, perhaps 6-7 years ago, a student had windows binary >>>>> rewriting working to the point where you could do basic binary >>>>> rewriting >>>>> on notepad.exe. They left before finishing the project, and it was >>>>> never feature complete nor functional on complicated binaries. You're >>>>> likely seeing the remains of that effort. I don't know how much of >>>>> that >>>>> code is still valid or useful. >>>>> >>>>> -Matt >>>>> >>>>> >>>>> On Wed, 11 Feb 2015, Aleksandar Nikolic wrote: >>>>>> Hi, >>>>>> >>>>>> looking at the codebase, a lot of code seems to already be there. >>>>>> I'll be getting to know the code in more details. Any directions >>>>>> into what would need to be implemented or what parts are missing? >>>>>> >>>>>> Thanks, >>>>>> Alex >>>>>> >>>>>> On 02/08/2015 10:59 PM, Barton Miller wrote: >>>>>>> BTW, if there are any individuals or groups that would like to >>>>>>> work on >>>>>>> getting rewriting to work on Windows, we'd be happy to provide >>>>>>> support. >>>>>>> Not a small effort but interesting and worthwhile. >>>>>>> >>>>>>> --bart >>>>>>> >>>>>>> >>>>>>> On 2/6/2015 4:36 PM, Bill Williams wrote: >>>>>>>> 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. >>>>>>> _______________________________________________ >>>>>>> Dyninst-api mailing list >>>>>>> [email protected] >>>>>>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >>>>>> _______________________________________________ >>>>>> Dyninst-api mailing list >>>>>> [email protected] >>>>>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >>>>>> >>>> _______________________________________________ >>>> Dyninst-api mailing list >>>> [email protected] >>>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >>>> >>> >>> > > _______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
