3

I'm newbie to Linux, so I've got gut feeling that answer is trivial, but after couple of days of looking for the answer I'm giving up and counting on your help...

I'm using software on CentOS 7. When I start it on TTY pseudo terminal (e.g. /dev/tty2) it prints out a lot of interesting information on the screen I need to analyze. Due to amount of information and for archiving I would like to save them in a file. So obviously I tried to redirect stdout, stderr to a file, but it turned out I can save only small portion of the information visible on the terminal screen (hundreds of lines). I used strace later to figure out the way application prints those information on the screen - it is writing to /dev/tty0 device (not /dev/tty, but /dev/tty0, currently visible console, which makes - I think - a big difference). Realizing this I tried many possible solutions to capture this output including:

It all works well for catching /dev/tty writes, but not for /dev/tty0!

Can you suggest any solution or even just an idea I could try?

rafgrz
  • 41
  • 6
  • The next levels of messing with misbehaving programs are: Force-preloading a shared library that intercepts `open` with an argument of `"/dev/tty0"` and redirects it; using `ptrace` to intercept `write` calls directly; writing a custom kernel module. – melpomene Aug 27 '18 at 10:03
  • Thank you melpomene! I was thinking about it, but sounds like not an easy task (I still call myself newbie in Linux world :)), if nothing else works I will try to do this... If you can direct me to any skeleton of such a library I would appreciate! ptrace - interesting, need to investigate. Custom kernel module - I think it is too difficult to me, but maybe I will need to try this as well. – rafgrz Aug 27 '18 at 10:09
  • https://www.osletek.com/pg/150/Intercepting_C++_functions_using_LD_PRELOAD looks relevant, only your case is a bit simpler because it's a plain C function you want to override. – melpomene Aug 27 '18 at 10:35
  • Thank you melpomene! Great and simple. You are right I need to intercept plain C functions - I think only two standard functions: 'open' and 'write'. Open to find a descriptor used in further write invocations, and write to actually capture output to e.g. file. I will try this in the evening, and this will be great lesson how to intercept system calls for me :). I've also started to read about ptrace, if someone is interested here: https://nullprogram.com/blog/2018/06/23/ you can find a nice explanation, but your library approach looks like more simple and elegant for me. – rafgrz Aug 27 '18 at 10:52

1 Answers1

1

for those who may be interested... After couple of weeks of experimenting I share what I've learnt:

  1. Force-preloading method - easy and quick one, but with major drawback in my case - it in fact doesn't intercept syscalls, but libc standard library calls. Drawback, as application can directly call syscall bypassing libraries and it won't be intercepted. It happened in my case.

  2. Later on I tried kernel module, relatively quickly I could create basic one with intercepting syscalls by modifying syscall function address in syscall_table (requires some dirty hacks, like unprotecting write to that memory with CR0 register manipulation, etc...), but more I tried to progress I have faced more issues, especially in the context of intercepting process which is forking children, and I want to intercept syscalls for the forked processes as well. Of course big plus is that you have an ultimate access to any kernel structures, etc... After some time I've given up and tried the third option.

  3. Ptrace method - looks like complex one at first sight, but is quite logical, but you need to read longy man to have understanding. Again for forked processes things get complicated, but I'm close to create workable solution now, and stuff like PTRACE_O_TRACEFORK etc. helps a lot.

My conclusion - creation of universal solution for this is not an easy stuff anyway (for instance look at 'strace' source code...), for me ptrace is the best option, however you need to invest some time to understand it, especially for forking processes.

Conclusion no. 2 - trying to solve the issue it was great adventure for me and diving into depths of linux kernel and how syscall works was amazing learning :)

Thank you melpomene for inspiration! :)

rafgrz
  • 41
  • 6