I'm trying to hook the fopen syscall in linux using Go.
Normally I would use C for something like this (Example: https://stackoverflow.com/a/880278/5572976) but the CTF states that the solution needs to be written in Go.
I've looked at the syscall package and basically what I'm looking for is using the following in Go.
dlsym(RTLD_NEXT, "open");
EDIT: That's open, not fopen.
try this Runtime dynamic library loader (dlopen / dlsym) for Go (golang)
Related
Is there the possibility to emit ASM when compiling something using Cranelift? By "ASM" I mean the assembler text-representation, in e.g. Intel-Syntax or similar
Now I was planing on implementing this myself using a dissasembler-library like Capstone or Iced, but then I found Context::set_disasm(bool) which apparently does exactly what I need. The problem is I'm unable to find where to extract this assembler-code from. There's no function like get_disasm as far as I looked.
If it's relevant, I'm building both a JIT and an AOT compiler and I want the dissasembler to work when using either.
Can one help me out?
Retrieve the disasm field of CompiledCode. It is in CompiledCodeBase, so it is not documented, unfortunately.
I'm running Linux and have a situation like this:
A binary file 'bin1' loads via dlopen 'shared1.so' which is linked with 'shared2.so' and 'shared3.so'.
if 'shared2.so' or 'shared3.so' is missing the program 'bin1' won't run.
There are runs that I know that I won't touch any code from 'shared2.so' and I want 'bin1' to be able to run even when this library is missing, can this be done ?
You could ship program with dummy shared2.so library. You might need to add dummy functions which shared1 expects to find there. This can be done manually or via automatic tool like Implib.so.
I'm building a syscall to kernel Linux, so I need to export a structure to use in user level. I've read some documentation and they said I need to use a *.h below kernel/include/uapi or use make headers_install. But nothing seems to work. gcc doesn't identify the data type I tried to export.
So, what are the prerequisites to use this command and what exactly it makes (what headers it export and under what conditions) ?
I want to implement Control-Flow Integrity in Clang/llvm. (I know there is Forward-Edge CFI already implemented)
My problem is, that I have never implemented anything for a compiler (I am new to compiler based approaches) and therefore don't know where to start.
For my implementation I need first to get a list of all calls (internal => no library calls) and than change how functions are ended (for example: pop + jmp instead of ret).
Does anyone know where to start or even if this is possible using the plugin system (LibClang, Clang Plugins, LibTooling)?
Thanks in advance
here is a advanced one CCFI :
https://bitbucket.org/CCFI/
it based on this :
http://iot.stanford.edu/pubs/mashtizadeh-ccfi-ccs15.pdf
you can learn that how to add your code to each jmp,call,jmp,ret and so on...
I am using CreateRemoteThread in Windows and would like to know if the same thing is possible in Linux. Is it possible to do this in Linux?
The traditional way of doing this on Linux would be to create a dynamic library (.so) with your code in it, then separately force the loading of your library into the running application. There is no one-stop shop as there is with CreateRemoteThread on Windows.
So here are the basic steps:
Create and link a .so dynamic library (.dylib on macOS) that contains the code you wish to execute in the remote process.
Write some very simple code in assembly that loads the specified so file (mainly copy and paste from this link, part 1).
Embed said loader ASM as a binary payload in a buffer in a 2nd code file/app. Here you will use ptrace to run the binary payload written in step 2, which will trigger the target app to call _dl_open() on the .so created in step 1, which contains the actual code you wish to run. (Sample given in the same link, part 2.)
If you need your code to run in a separate thread from the main pump, then you should use pthread_create in the code in step 1.
Hope this answers your question. Yes, it's more involved than on Windows; but it should work equally well. Plus, you can reuse just about the entire code from steps 2 and 3 for future remote code injection projects.
`#include pthread.h
int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine) (void *), void *arg);`
Compile and link with -pthread.
see man pthread_create for detail