My main requirement is to profile the mentioned anti-debugging check program twice ( Once in the presence of a debugger and the other without it ) to collect some information for analysis during run-time (Assuming only the binary is available)
#include <stdio.h>
#include <sys/ptrace.h>
int i_am_debugged()
{
if (ptrace(PTRACE_TRACEME, 0, 1, 0) < 0)
{
printf("Avoid debugging please");
return 1;
}
return 0;
}
int main()
{
if(i_am_debugged())
{
return 1;
}
printf("It's going well ! No debugging !\n");
return 0;
}
Currently , I wrote a Intel PIN tool for the same but I am unable to profile a run when a debugger is not attached because of the way PIN works and always executes 'It's going well ! No debugging !'.
So, my question:
Is there anything I can do (attach a debugger and run the pin tool or something) to profile both types of runs using my PIN tool or will any other type of profiling (for ex Binary translation, etc) help me in this case?
I want to collect specific information about instructions and not just Call graph,etc and hence would like some functionality similar to PIN's C++ programmer interface.
A detailed answer would be great, Thanks.
Pin uses ptrace to inject itself into the application. This means that using gdb won't be possible when attempting to launch an application with Pin, and also that Pin won't successfully attach to an application that is being debugged.
My suggestion is to start Pin with the -pause_tool knob, and then attach gdb to the process. This will make the application's ptrace call return what you want.
I hope i get what you want.
Intel PIN is NOT a debugger. It's more like a VM which on-the-fly instruments binary code (for x86/x64) and then executes this freshly instrumented code.
Because PIN is not opensource, it's internals are rather "secret" ;).
But its CLEARLY not a debugger.
If i understand you correctly you want some sort of test-suite which
runs your application twice, one time with a debugger attached and one time without?
Then you probably should use gdb.
Just start:
./a.out for the normal run
and e.g. (this one is a little hacky ;-) ) for the debugger-run:
Create a file mygdbscript (needs arguments to gdb like: gdb -x ./mygdbscript)
The content of this file is just:
# you probably dont want gdb to stop under ANY circumstances
# as this is an automatic check. So pass all signals to the application.
handle all nostop print pass
run
quit
Then run with gdb -x ./mygdbscript --args ./a.out
Hope this helps :)
Related
Is there a source code for /usr/bin/ulimit? I need to see a user's complete list of rlimit's without him being in a shell.
In this case, we have problems running memory-intensive programs from the web server (user wwwrun, usually having /bin/false as login shell in /etc/passwd), and we suspect some system-imposed limits are blocking it from completing these programs.
In former times, there has been a /usr/bin/ulimit binary, but these seem to be gone.
So what I'm looking for is a C implementation of the ulimit command (nowadays usually being only available as (ba)sh built-in). It doesn't need to have any "setrlimit" capabilities - just printing all limits would be sufficient. We'd then set this command as wwwrun's login shell and a "su - wwwrun" would show all rlimits this user has.
Thanks for any hints!
There cannot be any /usr/bin/ulimit (or /usr/bin/cd) executable, because the setrlimit(2) syscall operate on the current shell process (changing a property of the current process which will by default be inherited by further child processes, see fork(2) & execve(2)). So ulimit, like cd (which invokes the chdir(2) syscall), has to be a shell builtin
From inside your C program just call the setrlimit syscall. Don't forget to test for failure (and on failure display errno perhaps using perror or strerror). To query the current limits, use getrlimit(2) or read -within your program- sequentially the /proc/self/limits pseudo-file (see proc(5) for more, or /proc/1234/limits for process of pid 1234).
FILE* f = fopen("/proc/self/limits", "r");
if (f) {
char linbuf[128];
do {
memset (linbuf, 0, sizeof(linbuf));
fgets (linbuf, sizeof(linbuf), f);
fputs(linbuf, stderr);
} while (!feof(f));
fclose (f);
fflush(NULL);
} else perror("/proc/self/limits");
I also recommend reading Advanced Linux Programming and intro(2). See also Linux PAM and configuration files like /etc/security/limits.conf and under /etc/pam.d/
Thanks for the hints - I've set a simple text file cat-limits as login shell for wwwrun, simply containing one line with
#!/bin/cat /proc/self/limits
and that gave me what I want.
Cheers
I need to write some commands in command window using C++ code. How to implement it. I have tried with CreateProcess function but it seems some wrong in it. Please refer my code below:
STARTUPINFO sInfo = {0};
sInfo.cb = sizeof(sInfo);
PROCESS_INFORMATION pInfo = {0};
CreateProcess("C:\\WINDOWS\\System32\\cmd.exe",""0,0,TRUE,
NORMAL_PRIORITY_CLASS,0,0,&sInfo,&pInfo);
It opens the command window successfully. My doubt is how to write command through code in it.
First thing, you need not to create a separate process just to write text output to a console window.
It depends what and how you want to write. You may create a console application itself, or create a console itself, and attach to the current process. You need to use pipes for the same and redirect the output to given pipe (i.e. send data to pipe). At the other end of pipe, you will read the text/buffer and render the output wherever you would like to.
These articles may help:
Console Output from GUI program
Real time Console Output redirection
Since your question is not very clear, this is just assumption.
Or, are you playing with the console itself - like changing colors, dimension etc?
I went through the Linux man page for access command, but not sure about the application of the command.
Can someone explain this.
Can it be used like this:
access -f filename;
If i want to check whether the file is existing or not?
But I am getting an error :
The transaction failed: no-cache,
Same thing happens with:
access -w filename;
if I want to check whether the file is writable by current user.
Also this can also easily be done with test command easily. Then what is the exact difference between these two commands. Please elaborate.
thanks in advance.
That is not a Linux command. It's C function that can be loaded through the unistd.h library.
You can use it in a C program as follows:
#include <unistd.h>
#include <stdio.h>
int main () {
int writeable;
writeable = access("/path/to/file", W_OK);
if (writeable == -1)
printf("Not writeable!");
else
printf("Writeable!";
return 0;
}
Note that it returns 0 on success. And 0 is false for C and many other languages, but in this case it means true.
The fact that you can see man access doesn't mean at all that it's a Linux command as any standard Linux distribution has man pages for every C library and function. You can also see man malloc. You can determine if it's a Linux command or a C library man page by viewing the header. For example man access:
ACCESS(2) Linux Programmer's Manual ACCESS(2)
NAME
access - check real user's permissions for a file
SYNOPSIS
#include <unistd.h>
int access(const char *pathname, int mode);
As you can see, the first line states Linux Programmer's Manual.
I had compiled some examples from svgalib, the console show :
Using EGA driver
svglib 1.4.3
Nothing more, its like its drawing somewhere but I cannot see it.
This could be a ver very noob question about svgalib, but also a configuration problem.
Also I check the virtual console that it says is drawing (if I run from X), running from console just stays there. I also put sleep in the code
example code :
include stdlib.h
include vga.h
int main(void)
{
vga_init();
vga_setmode(G320x200x256);
vga_setcolor(4);
vga_drawpixel(10, 10);
sleep(5);
vga_setmode(TEXT);
return EXIT_SUCCESS;
}
compile with
gcc -o tut tut.c -lvga
So do you have other SVGAlib applications working on your system? Such svgatest, which may be in a separate distribution package (svgalib-bin or similar).
Have you configured svgalib for your system? Common locate of the config file is /etc/vga/libvga.config and read man svgalib should give you more details.
I suspect that once you have SVGAlib working in general, the tutorial example program will work.
Install by software manager all svgalibrary.
Set the resolution at yours graphics screen
es : G1024x768x256
set color pixel white = 15
my linux mint (mate) 17.1 on hard disk work fine.
good luck !
I'm working on an application controller for a program that is spitting text directly to /dev/tty.
This is a production application controller that must be able to catch all text going to the terminal. Generally, this isn't a problem. We simply redirect stdout and stderr. This particular application is making direct calls to echo and redirecting the result to /dev/tty (echo "some text" > /dev/tty). Redirects via my application controller are failing to catch the text.
I do have the source for this application, but am not in a position to modify it, nor is it being maintained anymore. Any ideas on how to catch and/or throw away the output?
screen -D -m yourEvilProgram
should work. Much time passed sinced I used it, but if you need to read some of its output it could even be possible that you could utilize some sockets to read it.
[Added: two links, Rackaid and Pixelbeat, and the home page at GNU]
The classic solution to controlling an application like this is Expect, which sets up pseudo-terminals, does logging, and drives the controlled application from a script. It comes with lots of sample scripts so you can probably just adapt one to fit your needs.
This is what I did in python
import pty, os
pid, fd = pty.fork()
if pid == 0: # In the child process execute another command
os.execv('./my-progr', [''])
print "Execv never returns :-)"
else:
while True:
try:
print os.read(fd,65536),
except OSError:
break
I can't quite determine whether the screen program mentioned by #flolo will do what you need or not. It may, but I'm not sure whether there is a logging facility built in, which appears to be what you need.
There probably is a program out there already to do what you need. I'd nominate sudosh as a possibility.
If you end up needing to write your own, you'll probably need to use a pseudo-tty (pty) and have your application controller sit in between the user's real terminal connection and the the pty device, where it can log whatever you need it to log. That's not trivial. You can find information about this in Rochkind's "Advanced UNIX Programming, 2nd Edn" book, and no doubt other similar books (Stevens' "Advanced Programming in the UNIX Environment" book is a likely candidate, but I don't have a copy to verify that).