Re: How to get the slide of another process
Re: How to get the slide of another process
- Subject: Re: How to get the slide of another process
- From: "Gerriet M. Denkmann" <email@hidden>
- Date: Fri, 06 Apr 2012 23:50:00 +0700
On 6 Apr 2012, at 22:27, Shantonu Sen wrote:
> What are you trying to do? If you don't have experience with mach_vm_read, why do you care about other processes' slide?
I am trying to make my own vmmap.
And learning lots of things, among others how to use mach_vm_read.
> On Apr 6, 2012, at 3:59 AM, "Gerriet M. Denkmann" <email@hidden> wrote:
>
>>
>> On 5 Apr 2012, at 23:05, Joseph Ranieri wrote:
>>
>>> On Thu, Apr 5, 2012 at 11:49 AM, Gerriet M. Denkmann
>>> <email@hidden> wrote:
>>>>
>>>> On 5 Apr 2012, at 15:31, Quinn The Eskimo! wrote:
>>>>
>>>>> On 4 Apr 2012, at 12:28, Gerriet M. Denkmann wrote:
>>>>>
>>>>>> Given a normal app (NOT a kext) (which might run as root if necessary) and the pid of another process, how to I get the slide of it?
>>>>>
>>>>> One way to do it--and I'm certainly not sure that this is the best way--is to find dyld and then use the dyld debug interface to find all the images in the process.
>>>>
>>>> Could you be a bit more specific?
>>>>
>>>> I don't know how to "find dyld".
>>>> Do you mean find a memory region starting at 'a' where proc_regionfilename( pid, a, ... ) gives: "/usr/lib/dyld" ?
>>>>
>>>> If so, there are typically about half a dozen of those.
>>>>
>>>> And where (in which header file?) is the "dyld debug interface" documented?
>>>
>>> Basically you need to find dyld_all_image_infos in the remote process.
>>> gdb uses task_info passing in TASK_DYLD_INFO to get the address. lldb
>>> also has to find the symbol, but I'm not certain how it does it and
>>> couldn't find it quickly in the source code.
>>>
>>> Once you've found the address, it's fairly trivial to read from it via
>>> the Mach APIs. Just keep in mind that you might be inspecting a 32-bit
>>> process from a 64-bit process or the other way around.
>>
>> I got this:
>>
>> - (uint64_t)localAddressFor: (uint64_t)addressInTargetTask size: (uint64_t)sizeInBytes inTask: (vm_map_t)target_task
>> {
>> uint64_t pagesize = getpagesize();
>> uint64_t mask = pagesize - 1;
>>
>> mach_vm_address_t startAddress = (mach_vm_address_t)addressInTargetTask;
>> mach_vm_address_t endAddress = startAddress + sizeInBytes;
>> mach_vm_address_t baseAdr1 = startAddress & ~mask;
>> mach_vm_address_t baseAdr2 = endAddress & ~mask;
>> mach_vm_size_t size = baseAdr2 - baseAdr1 + pagesize;
>> mach_msg_type_number_t dataCnt;
>> vm_offset_t data;
>> kern_return_t kr = mach_vm_read ( target_task,
>> baseAdr1,
>> size,
>> &data,
>> &dataCnt
>> );
>> if ( kr != KERN_SUCCESS ) // error ...
>> if ( dataCnt != size ) // error ...
>>
>> mach_vm_address_t lowAdr = startAddress & mask;
>> uint64_t localAddress = data + lowAdr;
>> return localAddress;
>> }
>>
>> This seems to work.
>> Any obvious errors?
>> Do I have to release (free) the "data" pointer?
>>
>> One problem: calling this method twice with the same arguments results in different "data" being returned.
>> Any way to fix this? Or do I just have to keep a list of already translated addresses?
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden