Open w296488320 opened 2 years ago
Not sure what does your question mean, so I'm kinda guessing question:
When syscall is invoked number of syscall to invoke is put in one of registers and one has to use syscall table to determine to what function given number corresponds. Here is table for AArch64 (ARM64).
In PRoot code that is wrapped in get_sysnum
function (and example of its use in translate_syscall_enter
)
PRoot doesn't know (and doesn't need to know) what function actually invoked syscall (libc wrapper, syscall(2)
, directly through assembly)
Use gdb
(if you need to debug program under proot
launch gdb
inside proot
as well)
Usually syscalls are invoked through libc wrappers and you can set breakpoint on those (break syscall_name
)
In cases when they aren't, you can use catch syscall syscall_name
command to set catchpoint on syscall invocation
Then use bt
(backtrace
) command to see stack trace
Thanks so much for your reply
Question 1:
I want to get the symbol of the function of svc when the function is called (similar to dlsym() parameter 2) I want to get the content of the parameter 2.
Question 2: Why do you still need to use seccomp with ptrace? Is it for a faster program execution, or for some other reason
Why do you still need to use seccomp with ptrace?
Seccomp allows performing syscall filtering inside kernel so PRoot is notified only when tracee calls syscall it is interested with (so context switch to PRoot will happen only if tracee calls syscall PRoot handles (e.g. openat()
), when tracee calls syscall which it doesn't handle (e.g. read()
) it can directly proceed without need for context switch to proot)
I want to get the symbol of the function of svc when the function is called (similar to dlsym() parameter 2)
PRoot doesn't know these (it does know instruction pointer register value (inside PRoot it can be retrieved through peek_reg(tracee, CURRENT, INSTR_POINTER)
)), however to map it to function name one would need to parse /proc/pid/maps
to determine which file/offset it corresponds to and then parse ELF file symbol belong to.
That might find just wrapper through or may not be possible at all (for example for stripped static binaries)
Why do you need name of caller function?
Question 1: Why do you still need to use seccomp with ptrace?
Why not use ptrace directly. My understanding is to filter out some functions through seccomp first. In order to increase the proot efficiency, do I understand that?
Question 2: I am also what you think, I tried to implement this function, but failed, do not know why always reported wrong.It is not being resolved as yet.If you have a good way to write, you can tell me, another happy New Year's day!
Why not use ptrace directly
It should be noted that PRoot configures seccomp to trigger ptrace event when interesting syscall happens so it still goes through same ptrace flow
Question 2: I tried to implement this function, ...
Do you really need information about symbol name (libc wrapper name) and not just syscall name?
(e.g. if application uses syscall(2)
you'd want "syscall"
text?)
yes ,Of course, this is certain, sorry, I previously expressed a problem, I am using the translation software to translate Chinese into English.Forgiving me for not expressing my problem clearly you can encapsulate this feature into a utils for easy developers for debugging analysis use.
I still don't know what you'd need. I should note that PRoot already has debugging output with messages like:
proot info: vpid 1: sysenter start: execve(0xa9380b30, 0xbeb7555c, 0xbeb75588, 0x2f, 0xa9486100, 0xbeb7555c) = 0xa9380b30 [0xbeb73478, 0]
in which you can find syscall name (in this case execve
)
and for further debugging I'd recommend using gdb
I want the so to listen on is not just libc but some other svc calls for so and I need to try to output his path but I hope to get his symbol.Good and more quickly to locate my problem, so I raised this idea.
pay attention to: The svc may be called by many so.
Sorry but your comment got completly mangled in translation so I don't know what you mean
Are you saying that neither proot debug output (looks like this, enable with proot -v 9
or export PROOT_VERBOSE=9
) nor running gdb
inside proot aren't what you need?
android studio compile this project
Usually PRoot isn't built with Android Studio but as separate executable, when building outside Android Studio libtalloc.h
is provided by libtalloc-dev
package (or libtalloc
or talloc
depending on distro)
If you really want to build with Android Studio you'll need to include talloc sources as well: https://talloc.samba.org/
I tried to decompile the dynamic library of talloc.But they always fail. Do you have a talloc static library or a dynamic library that you can use directly?
Is there any way for the windows system to access it (libtalloc-dev) ?
I haven't tested proot under WSL, but you should be able to install libtalloc-dev through apt
Is there any way I can get the function where the tracee calls the svc ?
I know the ptrace function of ptrace that can modify the register contents of certain functions and I don t know why he works with seccomp and how they have to divide?What information should I get this information from?I am really curious about how he did it.