I'm trying to write a pam backdoor scanner, which may call fopen function in pam_sm_authenticate(normal file will not call fopen in this function) to store username and password, but I can't use external command such as "nm, readelf" or something like that, so the only way seems to scan pam_sm_authenticate function and find all call instructions and caculate the address to check if it is calling fopen, but it is too troublesome and i'm not very familiar with ELF file(I even dont know how to find offset of pam_sm_authenticate, I'm useing dlopen and dlsym to get the address..), so I wonder if there is a better or easy way to detect it? Thankyou.
TL;DR: building a robust "pam backdoor scanner" is theoretically impossible, so you should give up now and think about other ways to solve your problem.
Your question is very confusing, but I think what you are asking is: "can I determine programmatically whether pam_sm_authenticate calls fopen".
That is the wrong question to ask, for several reasons:
if pam_sm_authenticate calls foo, and foo calls fopen, then you still have a problem, so you really should be scanning pam_sm_authenticate and every function it calls (recursively),
the fopen is far from the only way to write files: you could also use open, or system (as in system("echo $secret > /tmp/backdoor"), or direct sys_open syscall, or a multitude of other hacks.
finally, the pam_sm_authenticate can use just-in-time compilation techniques to build arbitrary code (including code calling fopen) at runtime, and answering whether it does by examining its code is equivalent to solving the halting problem (i.e. impossible).
Related
I've learned something about thread local storage(TLS). From my point of view, this is a totally black box - you give it a key, and it gives you the thread local data back. No idea what the key is like and where these local data is saved.
Recently I've found some hacky ways to retrieve TLS data, but couldn't figure out how they work.
In project async-profiler(at src/vmStructs.cpp line:347), pthread key is an int, why? I read the source code about pthread manipulation of Hotspot JVM and didn't find any clue. Hotspot doesn't specify the type of pthread key (and I don't think it can either). And why we could guarantee to find the pthread key with just a simple integer loop? Not sure this is a TLS question or a Hotspot question. :(
pthread_tis an address of pthread. I think it points to some OS thread instance that we may not parse it directly. But, according to Phoenix87's answer, we could regard pthread_t as an address of pthread_t list in which we could find TID(the return of gettid()) with a simple loop (a simple loop, again). You could find it in Austin (at src/linux/py_proc.h line: 613). How does it work?
Both of these make assumptions about the pthread implementation they are working on.
Such assumptions are not warranted in general, and are almost guaranteed to break with a different implementation.
Don't write code like that unless absolutely necessary, and if you do write code like that, please clearly state exactly which implementation(s) and which versions you support.
Recently, I've been trying to write to a .PAK file while it is being used by another process in ring 0. This has been a problem for quite a while and i haven't had much success. I am able to use any programming language necessary to accomplish this, but C#/VB.net is preferred. I originally wanted to use a find and replace system when editing, but I will just choose and offset to write to and such instead.
No, I can't just terminate the process then edit; the process must be running. Yes, I obviously know the process with the file handle attached.
No, I can't just run as admin because the process is established in ring 0/the kernel.
I've tried multiple methods including setting the process speed temporarily to 0 to edit then revert, and changing the FileShare and other parameters, none with any success.
One approach which I have been told a lot and which I have no experience in is creating a "Kernel Driver". I'm not sure how to go about this and I cant find much info online so if you think that's is the best method please inform me on how to get started. Any help is appreciated!
Always create a temporary file (a copy of your original file). If you need to process a file within your codes, create a temp file, use the temp file and process that file. So if you need another process, there will be no problem.
This is actually a two-fold question, I guess. On one part, I'd like to know whether there's a neat way to enumerate all declared UTIs on a given system.
I know lsregister -dump is an option, given some grep and parsing on my side; however, I'm left to wonder if there isn't a better solution.
Further... I'm wondering if there's a way to retrieve a list of imported/exported UTIs given an app's path. I know the reverse should be possible (i.e. finding which bundle has declared a given UTI).
One of the reasons why I'm wondering about this is because a possible solution for the first part of the question would be to iterate through all apps and retrieve their imported/exported UTIs (although I think it would probably not be a very efficient solution)
I've searched everywhere I can think of and am not really any closer to an answer. So far, it would seem it's either parse output of lsregister -dump, or try to read UTI keys directly from apps' Info.plist files...
Finally, in my searching I've come across a private API that might be of use, but I have absolutely no idea how to use it, since there's absolutely no documentation for it online... I'm talking about "__UTCopyDeclaredTypeIdentifiers"... maybe somebody is aware of which (if any) parameters does that function take, and/or what exactly does it return?
import Foundation
#_silgen_name("_UTCopyDeclaredTypeIdentifiers") func UTCopyDeclaredTypeIdentifiers() -> CFArray
let UTIs = UTCopyDeclaredTypeIdentifiers()
print(UTIs)
Should print all the UTIs that the function knows about.
I'm writing a Linux kernel module that needs to open and read files. What's the best way to accomplish that?
Can I ask why are you trying to open a file?
I like to follow Linux development (out of curiosity, I'm not a kernel developer, I do Java), and I've seen discussion of this question before. I was able to find a LKML message about this, basically mentioning it's usually a bad idea. I'm almost positive that LWN covered it in the last year, but I'm having trouble finding the article.
If this is a private module (like for some custom hardware and the module won't be distributed) then you can do this, but I'm under the impression that if you are going to submit your code to the mainline then it may not be accepted.
Evan Teran mentioned sysfs, which seems like a good idea to me. If you really need to do harder custom stuff you could always make new ioctrls.
EDIT:
OK, I found the article I was looking for, it's from Linux Journal. It explains why doing this kind of stuff is generally a bad idea, then goes on to tell you exactly how to do it anyway.
assuming you can get pointers to the relavent function pointers to the open/read/close system calls, you can do something like this:
mm_segment_t fs = get_fs();
set_fs(KERNEL_DS);
fd = (*syscall_open)(file, flags, mode);
if(fd != -1) {
(*syscall_read)(fd, buf, size);
(*syscall_close)(fd);
}
set_fs(fs);
you will need to create the "syscall_*" function pointers I have shown though. I am sure there is a better way, but I believe that this would work.
Generally speaking, if you need to read/write files from a kernel module, you're doing something wrong architecturally.
There exist mechanisms (netlink for example - or just register a character device) to allow a kernel module to talk to a userspace helper process. That userspace helper process can do whatever it wants.
You could also implement a system call (or such like) to take a file descriptor opened in userspace and read/write it from the kernel.
This would probably be neater than trying to open files in kernel space.
There are some other things which already open files from kernel space, you could look at them (the loop driver springs to mind?).
/proc filesystem is also good for private use, and it's easy.
http://www.linuxtopia.org/online_books/Linux_Kernel_Module_Programming_Guide/x773.html
All of the kernel developers say that file I/O from kernel space is bad (especially if you're referring to these files by their paths) but the mainstream kernel does this when you load firmware. If you just need to read from files, use the
kernel_read_file_from_path(const char *path, void **buf, loff_t *size, loff_t max_size, enum kernel_read_file_id id)
function, which is what the firmware loader code uses, declared in include/linux/fs.h. This function returns a negative value on error.
I'm not really sure of the point of the id variable at the end, if you look at the code it's not really used, so just put something like READING_FIRMWARE there (no quotes).
buf is not null terminated, instead refer to its size in size. If you need it to be null terminated, create a string size + 1 bytes long and copy it over or rewrite the kernel_read_file() function (used by kernel_read_file_from_path(), defined in fs/exec.c) and add one to i_size where memory is allocated. (If you want to do this, you can redefine the kernel_read_file() function in your module with a different function name to avoid modifying the whole kernel.)
If you need to write to files, there is a kernel_write() function (analogous to kernel_read(), which is used by kernel_read_file() and therefore also by kernel_read_file_from_path()), but there is no kernel_write_file() or kernel_write_file_from_path() function. You can look at the code in the fs/exec.c file in the Linux kernel source tree where kernel_read_file() and kernel_read_file_from_path() are defined to write your own kernel_write_file() and kernel_write_file_from_path() functions that you can include in your module.
And as always, you can store a file's contents in a char pointer instead of a void pointer with this function by casting it.
You can also find some informations about sys_call_open in this Linux Kernel Module Programing Guide.
I want something that looks like a file handle but is really backed by an in-memory buffer to use for I/O redirects. How can I do this?
I just wrote a library which provides this, called "knob" [hackage]. You can use it to create Handles which reference/modify a ByteString:
import Data.ByteString (pack)
import Data.Knob
import System.IO
main = do
knob <- newKnob (pack [])
h <- newFileHandle knob "test.txt" WriteMode
hPutStrLn h "Hello world!"
hClose h
bytes <- Data.Knob.getContents knob
putStrLn ("Wrote bytes: " ++ show bytes)
If you can express what you want to do in terms of C or system calls you could use Haskell's Foreign Function Interface (FFI). I started to suggest using mmap, but on second thought I think mmap might be a mapping the wrong way even if you used it with the anonymous option.
You can find more information about the Haskell FFI at the haskell.org wiki.
This is actually a bug in the library design, and one that's annoyed me, too. I see two approaches to doing what you want, neither of which is terribly attractive.
Create a new typeclass, make the current handle an instance of it, write another instance to do the in-memory-data thing, and change all of your programs that need to use this facility. Possibly this is as simple as importing System.SIO (or whatever you want to call it) instead of System.IO. But if you use the custom I/O routines in libraries such as Data.ByteString, there's more work to be done there.
Rewrite the I/O libraries to extend them to support this. Not trivial, and a lot of work, but it wouldn't be particularly difficult work to do. However, then you've got a compatibility issue with systems that don't have this library.
This may not be possible. GHC, at least, seems to require a handle to have an OS file descriptor that is used for all read/write/seek operations.
See /libraries/base/IOBase.lhs from the GHC sources.
You may be able to get the same effect by enlisting the OS's help: create a temporary file, connect the handle to it and then memory map the file for the I/O redirects. This way, all the handle I/O would become visible in the memory mapped section.
To add a modern answer to this question, you could use createPipe from System.Process:
createPipe :: IO (Handle, Handle)
https://www.stackage.org/haddock/lts-10.3/process-1.6.1.0/System-Process.html#v:createPipe
It's not possible without modifying the compiler. This is because Handle is an abstract data type, not a typeclass.