On 02/25/2015 02:28 PM, Aleksandar Nikolic wrote:
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?
That would be aligning up to the next 1MB boundary, which is an ELF
requirement. If it doesn't hold for PE files, it should be okay to relax
that.
(Side note: we really ought to add format_elf and format_pe #defines
where applicable, mapped appropriately to relevant OSes. If you feel
particularly motivated, it's fine to use this as the initial motivating
test case.)
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
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
bill@xxxxxxxxxxx
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}