I included some sample ASM code in a small program to do a test.
My program is:
#include <stdio.h>
static inline
unsigned char inb (int port) {
unsigned char data;
asm volatile("inb %w1,%0" : "=a" (data) : "d" (port));
return data;
}
int main()
{
printf("hello world %d\n", inb(22));
return 0;
}
When I run the program, it crashes with a segmentation fault when executing the ASM code.
Could someone tell me what's wrong with this small program? Thanks a lot.
You need to use ioperm before you're allowed to use port I/O. Also, note the kernel already provides inb and outb functions.
Use ioperm(2) or alternatively iopl(2) to tell the kernel to allow the
user space application to access the I/O ports in question. Failure
to do this will cause the application to receive a segmentation fault.
If your OS is Windows or Linux, most likely your program is terminated because the OS doesn't allow regular applications access I/O ports.
You syntax is absolutely correct. Just find and use the valid or unused port on your system.
Related
I have Win7 Pro (32 bit) and CodeBlocks IDE.
I would like to know is there any way to detect line with a segmention fault in C. My code is PRIME1.c
I find somewhere on Stack Overflow that this is possible on linux in terminal, but I would like to do that in Windows.
Could anyone tell me how to do that?
Many thanks!
In other words, I would like to know how to use debugger from cmd in windows 7 and how it can tell me which line is problematic.
I just found this link
Determine the line of C code that causes a segmentation fault?
But, as you can see, this is for Linux.
I would like to know how can I do that in Windows cmd?
You can catch seg fault. But, unfortunately, can not handle this event anyhow or get any info about that fault (in standard way, there are workarounds specific for compilers). So, maybe put printf in every line with __LINE__ macro and just wait until it fails.
#include <signal.h>
#include <conio.h>
#include <stdio.h>
void listener(int sig) {
printf("listener: access violation");
_getch();
}
void main() {
char a = 10;
char *p = &a;
signal(SIGSEGV, listener);
do {
printf("%d", *p++);
} while (1);
_getch();
}
sorry if my english is horrible: I'm realy stresed :(
I'm using Ubuntu 11.04 that work as virtual machine. Using VMWARE as virtual machine operating system is windows 7.
I'm trying to write a program on linux with C language: that using shared memory. when I try to compile there are no errors but when I execute it I see an error like this:
Segmentation fault (core dumped)
I'm not sure but as far as I learned VMWARE is causing this :S
here are the codes:
#include<stdio.h>
#include<sys/wait.h> //Process wait
#include <fcntl.h> //File
//#include <cstdlib>
//#include<fstream.h>
int main(){
printf("\n Here we go...!");
int *Numbers;
Numbers=(int*)getmem(327); // shared memory
int i,ProcID;
ProcID=fork(); //depart processor
if(ProcID==0){ // child processor
for(i=0;i<50;i++){
Numbers[i]=random()%50;
}
}else if(ProcID<0){
printf("\n Hmm... There is an error!");
}
int Waiting;
wait(&Waiting);
if(ProcID>0){ // parent processor
int fileeven,fileodd;
fileeven=open("EK_even.txt",O_RDWR|O_CREAT,0600);
fileodd=open("EK_odd.txt",O_RDWR|O_CREAT,0600);
for(i=0;i<50;i++){
if(Numbers[i]%2==0){
write(fileeven,&Numbers[i],sizeof(Numbers[i]));
}else{
write(fileodd,&Numbers[i],sizeof(Numbers[i]));
}
}
close(fileeven);
close(fileodd);
}else if(ProcID<0){
printf("\n Hmm... There is an error!");
}
return 1;
}
I'm using this to compile on terminal:gcc -o ./RUN ./EK.c -shared
to Run :./RUN
as result :Segmentation fault (core dumped)
Thanks for your time and reponds I'm realy in need...
Assuming getmem takes a number of bytes as a parameter, you allocate 327 bytes for your array of numbers:
Numbers=(int*)getmem(327);
If you are on a 64 bit system with 8-byte int, this is enough space for 40 integers.
You then proceed to put 50 numbers into that array, more than you allocated space for. This might very well cause a segmentation fault.
Generally, start your program in a debugger to see where exactly the segmentation fault occurs. This way you can more easily locate the error in your program.
The problem is VMWare as Marc B said. I tryed it on a real operating system and it worked. getmem() function is not my own function. To use it you have to add "-shared" at the end of compile line. Thanks for replies...
For educational purposes I'm trying to accomplish a bufferoverflow that directs the program to a different adress.
This is the c-program:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void secret1(void) {
puts("You found the secret function No. 1!\n");
}
int main () {
char string[2];
puts("Input: ");
scanf("%s", string);
printf("You entered %s.\n", string);
return 0;
}
I used gdb to find the address of secret1 as well es the offset the my variable string to the RIP. Using this information I created the following python-exploit:
import struct
rip = 0x0000000100000e40
print("A"*24 + struct.pack("<q", rip))
So far everything works - the program jumps to secret1 and then crashes with "Segmentation fault".
HOWEVER, if I extend my program like this:
...
void secret1(void) {
puts("You found the secret function No. 1!\n");
}
void secret2(void) {
puts("You found the secret function No. 2!\n");
}
void secret3(void) {
puts("You found the secret function No. 3!\n");
}
...
...it SegFaults WITHOUT jumping to any of the functions, even tho the new fake RIPs are correct (i.e. 0x0000000100000d6c for secret1, 0x0000000100000d7e for secret2). The offsets stay the same as far as gdb told me (or don't they?).
I noticed that none of my attempts work when the program is "big enough" to place the secret-functions in the memory-area ending with 0x100000 d .. - it works like a charm tho, when they are somewhere in 0x100000 e ..
It also works with more than one secret function when I compile it in 32-Bit-mode (addresses changed accordingly) but not in 64-Bit-mode.
-fno-stack-protector // doesn't make any difference.
Can anybody please explain this odd behaviour to me? Thank you soooo much!
Perhaps creating multiple hidden functions puts them all in a page of memory without execute permission... try explicitly giving RWX permission to that page using mprotect. Could be a number of other things, but this is the first issue I would address.
As for the -fno-stack-protector gcc option, I was convinced for a while this was obfuscated on gcc 4.2.1. But after playing with it a bit more, I have learned that in order for canary stack protection to be enabled, sizeof(buffer) >= 8 must be true. Additionally, it must be a char buffer, unless you specify the -fstack-protector-all or -fnostack-protector-all options, which enable canaries even for functions that don't contain char buffers. I'm running OS X 10.6.5 64-bit with aforementioned gcc version and on a buffer overflow exploit snippet I'm writing, my stack changes when compiling with -fstack-protector-all versus compiling with no relevant options (probably because the function being exploited doesn't have a char buffer). So if you want to be certain that this feature is either disabled or enabled, make sure to use the -all variants of the options.
This is a mad-hack, but I am trying to deliberately cause a segfault at a particular point in execution, so valgrind will give me a stack trace.
If there is a better way to do this please tell me, but I would still be curious to know how to deliberaly cause a segfault, and why my attempt didn't work.
This is my failed attempt:
long* ptr = (long *)0xF0000000;
ptr = 10;
I thought valgrind should at least pick up on that as a invalid write, even if it's not a segmentation violation. Valgrind says nothing about it.
Any ideas why?
EDIT
Answer accepted, but I still have some up-votes for any suggestions for a more sane way to get a stack trace...
Just call abort(). It's not a segfault but it should generate a core dump.
Are you missing a * as in *ptr = 10? What you have won't compile.
If it does, somehow, that of course won't cause a seg-fault, since you're just assigning a number. Dereferencing might.
Assuming dereferencing null on your OS results in a segfault, the following should do the trick:
inline void seg_fault(void)
{
volatile int *p = reinterpret_cast<volatile int*>(0);
*p = 0x1337D00D;
}
Sorry for mentioning the obvious but why not use gdb with a breakbpoint and then use backtrace?
(gdb) b somewhere
(gdb) r
(gdb) bt
As mentioned in other answers you can just call abort() if you want to abnormally terminate your program entirely, or kill(getpid(), SIGSEGV) if it has to be a segmentation fault. This will generate a core file that you can use with gdb to get a stack trace or debug even if you are not running under valgrind.
Using a valgrind client request you can also have valgrind dump a stack trace with your own custom message and then continue executing. The client request does nothing when the program is not running under valgrind.
#include <valgrind/valgrind.h>
...
VALGRIND_PRINTF_BACKTRACE("Encountered the foobar problem, x=%d, y=%d\n", x, y);
Wouldn't it be better to send sig SEGV (11) to the process to force a core dump?
Are you on x86? If so then there is actually an opcode in the CPU that means "invoke whatever debugger may be attached". This is opcode CC, or more commonly called int 3. Easiest way to trigger it is with inline assembly:
inline void debugger_halt(void)
{
#ifdef MSVC
__asm int 3;
#elif defined(GCC)
asm("int 3");
#else
#pragma error Well, you'll have to figure out how to do inline assembly
in your compiler
#endif
}
MSVC also supports __debugbreak() which is a hardware break in unmanaged code and an MSIL "break" in managed code.
I have seen a strange behavior with "strndup" call on AIX 5.3 and 6.1.
If I call strndup with size more than the size of actual source string length, then there is a stack corruption after that call.
Following is the sample code where this issue can come:
int main ()
{
char *dst_str = NULL;
char src_str[1023] = "sample string";
dst_str = strndup(src_str, sizeof(src_str));
free(dst_str);
return 0;
}
Does anybody have experienced this behavior?
If yes please let me know.
As per my observation, there must be a patch from OS where this issue got fixed. but i could not get that patch if at all there is any. Please throw some light.
Thanks & Regards,
Thumbeti
You are missing a #include <string.h> in your code. Please try that—I am fairly sure it will work. The reason is that without the #include <string.h>, there is no prototype for strndup() in scope, so the compiler assumes that strndup() returns an int, and takes an unspecified number of parameters. That is obviously wrong. (I am assuming you're compiling in POSIX compliant mode, so strndup() is available to you.)
For this reason, it is always useful to compile code with warnings enabled.
If your problem persists even after the change, there might be a bug.
Edit: Looks like there might be a problem with strndup() on AIX: the problem seems to be in a broken strnlen() function on AIX. If, even after #include <string.h> you see the problem, it is likely you're seeing the bug. A google search shows a long list of results about it.
Edit 2:
Can you please try the following program and post the results?
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
char *test1 = "abcdefghijabcdefghijabcdefghijk";
char *test2 = "012345678901234567890123456789";
char *control = "01234567890123456789012345678";
char *verify;
free(strndup(test1, 30));
verify = strndup(test2, 29); /* shorter then first strndup !!! */
fprintf(stderr,">%s<\n",verify);
if (strcmp(control, verify))
printf("strndup is broken\n");
}
(Taken from https://bugzilla.samba.org/show_bug.cgi?id=1097#c10.)
Edit 3: After seeing your output, which is >01234567890123456789012345678<, and with no strndup is broken, I don't think your version of AIX has the strndup bug.
Most likely you are corrupting memory somewhere (given the fact that the problem only appears in a large program, under certain conditions). Can you make a small, complete, compilable example that exhibits the stack corruption problem? Otherwise, you will have to debug your memory allocation/deallocation in your program. There are many programs to help you do that, such as valgrind, glibc mcheck, dmalloc, electricfence, etc.
Old topic, but I have experienced this issue as well. A simple test program on AIX 6.1, in conjunction with AIX's MALLOCDEBUG confirms the issue.
#include <string.h>
int main(void)
{
char test[32] = "1234";
char *newbuf = NULL;
newbuf = strndup(test, sizeof(test)-1);
}
Compile and run the program with buffer overflow detection:
~$ gcc -g test_strndup2.c
~$ MALLOCDEBUG=catch_overflow ./a.out
Segmentation fault (core dumped)
Now run dbx to analyze the core:
~$ dbx ./a.out /var/Corefiles/core.6225952.22190412
Type 'help' for help.
[using memory image in /var/Corefiles/core.6225952.22190412]
reading symbolic information ...
Segmentation fault in strncpy at 0xd0139efc
0xd0139efc (strncpy+0xdc) 9cc50001 stbu r6,0x1(r5)
(dbx) where
strncpy() at 0xd0139efc
strndup#AF5_3(??, ??) at 0xd03f3f34
main(), line 8 in "test_strndup2.c"
Tracing through the instructions in strndup, it appears that it mallocs a buffer that is just large enough to handle the string in s plus a NULL terminator. However, it will always copy n characters to the new buffer, padding with zeros if necessary, causing a buffer overflow if strlen(s) < n.
char* strndup(const char*s, size_t n)
{
char* newbuf = (char*)malloc(strnlen(s, n) + 1);
strncpy(newbuf, s, n-1);
return newbuf;
}
Alok is right. and with the gcc toolchain under glibc, you would need to define _GNU_SOURCE to get the decl of strndup, otherwise it's not decl'd, e.g.:
#include <string.h>
...
compilo:
gcc -D_GNU_SOURCE a.c
Thanks a lot for your prompt responses.
I have tried the given program.
following is the result:
bash-2.05b# ./mystrndup3
>01234567890123456789012345678<
In my program I have included , still problem is persistent.
Following is the strndup declaration in prepossessed code.
extern char * strndup(const char *, size_t);
I would like to clarify one thing, with small program I don't get effect of stack corruption. It is consistently appearing in my product which has huge amount of function calls.
Using strndup in the following way solved the problem:
dst_str = strndup(src_str, srtlen(src_str));
Please note: used strlen instead of sizeof as i need only the valid string.
I am trying to understand why it is happening.
Behavior i am seeing with my product when i use strndup with large size:
At the "exit" of main, execution is coring with "illegal instruction"
intermittently "Illegal Instruction" in the middle of execution (after strndup call).
Corrupt of some allocated memory, which is no where related to strndup.
All these issues are resolved by just modifying the usage of strndup with actual size of source string.
Thanks & Regards,
Thumbeti