Thank you!

Right, but why is a process necessary? It’s not like you’ll be able to run this code, right? So what are you planning to do with this process that can’t be done with your own internal representation? ps I suspect it would be possible to create a process and then map relevant bits of data into it from your core file. However, that’s gonna require some gnarly low-level programming (it may even involve… Mach gasp :-). Your life will be easier if you can avoid that. Oh, and if you do need to do that then it’s gonna be important to know why, because that determines how much of the process you need to running. We acknowledge that the whole process won't be fully functional, but getting the memory mapped in for inspection is a goal, and running fragments of code from the mapped image should work. Can you elaborate on why we need Mach? We are not against learning new technology, we just could use a little help pointing us in the right direction. Any more insight on how we should proceed? Thank you.

Qiunn said: In fact, LLDB supports something similar using the --core option. Did you look at that already? I had the exact same thought and when I asked about it, the original author of the code, he said: So with a debugger like gdb, attaching live it uses ptrace or similar to read memory that's already loaded. On a core, it isn't really loading libraries into a live process. It builds its own process model in memory but doesn't need to use the regular loader to get it there (as I understand it!).... (edited) So, based on his understanding, studying gdb will not help, is he wrong?

Thank you Quinn for your response. This is impractical in the general case because macOS leans heavily into Mach IPC. The vast bulk of system services aren’t provided by the kernel but are instead provided by daemons and agents via IPC. A process typically interacts with those via Mach IPC, and specifically XPC, and rebuilding those connections is pretty much impossible. So, if your OK with limiting this to Unix-y APIs then it might be worth continuing down this path. But if you want to get this working for apps, you should rethink your life choices )-: Yes, I am aware of the limitations - the purpose is not to fully "resurrect" the process, just to get enough running to do light poking. And yes, we are talking about POSIX APIs here. I read the Apple Library Primer, but not 100% sure which way should I proceed. I think the easiest would be to create a location dependent dylib and load that to make everything match. Are there any other paths? Is there any documentation describing how to build location dependent dylib?