immunityinc / libptrace Goto Github PK

I would like to point out that identifiers like “__PT_FACTORY_H” and “__PYTHON_PTRACE_H” do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Hello,

Is the write method supposed to be included in the process class? I'm aware that the docs are dated but it has the write method available. Via the following Python 3.7 snippet it looks like the method is not present.

def illegal_instruction(process, thread, chance=None):
    # read process memory
    print(dir(process))

Output

['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__
gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex_
_', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'breakpoint_find', 'breakpoint_set', 'breakp
oint_unset', 'brk', 'creation_time', 'export_find', 'free', 'handlers', 'id', 'malloc', 'mmap', 'modules', 'name', 'opti
on_set', 'read', 'read_utf16', 'read_utf8', 'resume', 'suspend', 'thread_create', 'threads']

I installed the library via the release downloads.

There's no .cmake file for linux, I want to build it on Linux 32(CentOS7)
How should I do?

This is a great project,Why is there no one.

Extra null pointer checks are not needed in functions like the following.

• service_list_destroy
• __update_errmsg

Given the imminent sunsetting of 2.7, any plans for 3.x compatibility?

Edit: After reading the full readme the lack of 3.x makes more sense since this hasn't been under active development for many years. I'd imagine the answer is "it's open source, do it yourself", but figure I'll at least leave the issue open for now since it's a reasonable request.

Currently pt_inject can be used to execute code in a pt_process. Although this is a very low-level primitive, it is not very flexible. An additional function for loading shared libraries into processes is therefore desirable.

One approach is to describe shared libraries using pt_module, and add a function such as pt_process_module_load(struct pt_process *p, struct pt_module *m) to load them into processes. The drawback here is that it adds additional meaning to the pt_module structure, which would now describe both shared libraries loaded into a debuggee process, as well as on disk shared libraries. This weakens type safety, and creates behind the scenes management code overhead.

Another approach is to add pt_process_library_load(struct pt_process *p, const char *pathname), which is simple, but does not allow for other shared library representations than one that can be referred to by a pathname. In other words, we could load shared libraries from disk, but not from memory.

Finally, a new structure such as pt_library could be added to refer to libraries external to the debuggee, and the new function would be pt_process_library_load(struct pt_process *p, struct pt_library *l). Once loaded it would then appear as a pt_module within the debuggee process.

The last option has my preference, but I'm leaving this open for a bit for further discussion and contemplation.