Just wondering if it is possible to obtain a task for a given proc_t inside a kext.
I have tried task_for_pid() which didn't work for some reason that I don't remember.
I tried proc_task(proc_t p) from sys/proc.h but I can't load my kext since that function is not exported.
I guess that I'm doing something wrong but I can't quite figure out what. Assuming I can get the task for a process, I'd like to use some mach calls and allocate memory, write memory and whatnot but for that, I would need the task I believe.
After some research it would appear that it's not the case.
There is proc_task() defined in proc.h but it's under the #ifdef KERNEL_PRIVATE. The KEXT will compile albeit the warning.
In order to use that function, you have to add the com.apple.kpi.private in the list of dependencies but even that will fail since you are most likely NOT Apple :)
Only Apple kexts may link against com.apple.kpi.private.
Anyway, the experiment was interesting in the sense that other APIs such as vm_read, vm_write etc. are not available to use inside a KEXT (which probably makes sense since they are declared in a vm_user.h and I suppose are reserved for user mode).
I'm not aware of a public direct proc_t->task_t lookup KPI, unfortunately.
However, in some cases, you might be able to get away with using current_task() and holding on to that pointer for as long as you need it. Use task_reference and task_deallocate for reference counting (but don't hold references forever obviously, otherwise they'll never be freed). You can also access the kernel's task (corresponding to process 0) anytime via the global variable kernel_task.
Related
Is there a straigtforward way with ready-at-hand tooling to suspend a traced process' execution when a certain syscalls are called with specific parameters? Specifically I want to suspend program execution whenever
stat("/${SOME_PATH}")
or
readlink("/${SOME_PATH}")
are called. I aim to then attach a debugger, so that I can identify which of the hundreds of shared objects that are linked into the process is trying to access that specific path.
strace shows me the syscalls alright, and gdb does the rest. The question is, how to bring them together. This surely can be solved with custom glue-scripting, but I'd rather use a clean solution.
The problem at hand is a 3rd party toolsuite which is available only in binary form and which distribution package completely violates the LSB/FHS and good manners and places shared objects all over the filesystem, some of which are loaded from unconfigurable paths. I'd like to identify which modules of the toolsuite try to do this and either patch the binaries or to file an issue with the vendor.
This is the approach that I use for similar condition in windows debugging. Even though I think it should be possible for you too, I have not tried it with gdb in linux.
When you attached your process, set breakpoint on your system call which is for example stat in your case.
Add a condition based on esp to your breakpoint. For example you want to check stat("/$te"). value at [esp+4] should point to address of string which in this case is "/$te". Then add a condition like: *(uint32_t*)[esp+4] == "/$te". It seems that you can use strcmp() in your condition too as described here.
I think something similar to this should work for you too.
I need to hold a specific value (a string, to be exact) throughout the lifetime of a single WinDbg session.
The reason for that, is that I need to address this variable in a few places throughout the lifetime of the WinDbg session (through .if statements, to be exact), and I want it to be defined at the startup of the session - using an argument that'll be passed. It can't be undefined or disposed - I must be able to address it in any point in the debugging session, and of course I don't want to risk that it might be redefined.
I was thinking of using a file for that purpose, or a shared memory, but I much prefer to solve this using WinDbg scripting.
If it's possible, it's obviously a much more elegant solution.
I've done some reading online on this matter and the issue is that I couldn't find a reference where the differences between Aliases (defined by an aS command) and User-Defined Pseudo-Registers (the registers in the range $t0..$t19, which are accessed by using the r command) were described. I couldn't find really understand the use cases for each.
The seemed to me Aliases is the better option, due to the fact that they can be named, in contrast to User-Defined Pseudo-Registers which have set names (wasn't sure regarding how to pick the "right" registered, to minimize possible collisions with other scripts which might use it, or is there any difference at all).
Am I missing something here?
Which should I use in this case, or are they both unsuitable for this situation?
I've written an app in LuaJIT, using a third-party GUI framework (FFI-based) + some additional custom FFI calls. The app suddenly loses part of its functionality at some point soon after being run, and I'm quite confident it's because of some unpinned objects being GC-ed. I assume they're only referenced from the C world1, so Lua GC thinks they're unreferenced and can free them. The problem is, I don't know which of the numerous userdata are unreferenced (unpinned) on Lua side?
To confirm my theory, I've run the app with GC disabled, via:
collectgarbage 'stop'
and lo, with this line, the app works perfectly well long past the point where it got broken before. Obviously, it's an ugly workaround, and I'd much prefer to have the GC enabled, and the app still working correctly...
I want to find out which unpinned object (userdata, I assume) gets GCed, so I can pin it properly on Lua side, to prevent it being GCed prematurely. Thus, my question is:
(How) can I track which userdata objects got collected when my app loses functionality?
One problem is, that AFAIK, the LuaJIT FFI already assigns custom __gc handlers, so I cannot add my own, as there can be only one per object. And anyway, the framework is too big for me to try adding __gc in each and every imaginable place in it. Also, I've already eliminated the "most obviously suspected" places in the code, by removing local from some variables — thus making them part of _G, so I assume not GC-able. (Or is that not enough?)
1 Specifically, WinAPI.
For now, I've added some ffi.gc() handlers to some of my objects (printing some easily visible ALL-CAPS messages), then added some eager collectgarbage() calls to try triggering the issue as soon as possible:
ffi.gc(foo, function()
print '\n\nGC FOO !!!\n\n'
end)
[...]
collectgarbage()
And indeed, this exposed some GCing I didn't expect. Specifically, it led me to discover a note in luajit's FFI docs, which is most certainly relevant in my case:
Please note that [C] pointers [...] are not followed by the garbage collector. So e.g. if you assign a cdata array to a pointer, you must keep the cdata object holding the array alive [in Lua] as long as the pointer is still in use.
I have foo.exe which is using some of Windows API functions. I want to get memory addresses of those functions, how do I do that? Any software available which I can use?
Note, that I am looking for non-programatically way of doing that.
Thanks
I am looking for non-programatically way of doing that.
Either this is not possible or it doesn't make any sense. Likely both.
You see, in order to call one of the Windows API functions, a program must import it from the DLL that contains the function of interest. This requires that DLL to be loaded into the address space of that program's process. And because each process has its own address space, each process gets its own unique instance (or copy) of the DLL. That means that the "memory address" of functions provided by DLLs is going to be different in each process.
Retrieving this information non-programmatically just doesn't make sense. Even if you could get it, it wouldn't do you any good.
I could probably provide better advice if you edited your question to explain what you're hoping to accomplish, rather than just asking about the approach you already settled upon.
The addresses of exported functions can be different for every process that loads the DLL. The GetProcAddress function can tell you what they are for your process.
Anyone knows anything about running executable from memory in OSX?
anything like this:
char *exeFile[size];
loadFromFile(exeFile, "/path/to/data");
execute(exeFile);
I want do that for security reasons. for example It is possible to encrypt exe and decrypt it before launch.
Well, yes, you can do it but its complex. I don't have access to working code right now but I do know others that are/have used it. The key is "NSCreateObjectFileImageFromMemory()", which is deprecated, but that said a few big apps like Skype reputed use it so its probably not going to disappear anytime soon (YMMV).
You have to allocate a memory buffer that's a multiple of the pagesize with vm_allocate. Copy the mach-o executable of the same architecture as the current process to there. Call NSCreateObjectFileImageFromMemory() which returns an object image. Then call successively NSLinkModule, NSLookupSymbolInModule and NSAddressOfSymbol. That last one gets you an actual function pointer to call.
This should give you most of what you need to know, and if you search you may find code that does it too. Good luck!