Cant access a specific memory address. on C program











up vote
2
down vote

favorite












I am working on the book "HACKING Art Of Exploitation " exercise Convert2.c page 61.



Here's my code. Below is my question.



#include <stdio.h>

void usage(char *program_name) {
printf("Usage: %s <message> <# of times to repeat>n", program_name);
exit(1);
}

int main(int argc, char *argv) {
int i, count;

// if(argc < 3) //if fewer than 3 arguments is used
// usage(argv[0]); // display usage message and exit

count = atoi(argv[2]); //convert the second arg into an interger
printf("Repeating %d timesn", count);

for(i=0; i < count; i++)
printf("%3d - %sn", i, argv[1]); // print the first arg

}


GDB OUTPUT...



    ➜ git:(master) ✗ 👽 gdb -q a.out
Reading symbols from a.out...done.
(gdb) run test
Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

Program received signal SIGSEGV, Segmentation fault.
__GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
292 ../stdlib/strtol_l.c: No such file or directory.
(gdb) break main
Breakpoint 1 at 0x555555554707: file convert.c, line 14.
(gdb) where
#0 __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
#1 0x00007ffff7a29122 in __strtol (nptr=<optimized out>, endptr=endptr@entry=0x0, base=base@entry=10)
at ../stdlib/strtol.c:106
#2 0x00007ffff7a24690 in atoi (nptr=<optimized out>) at atoi.c:27
#3 0x000055555555471f in main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
(gdb) run test
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

Breakpoint 1, main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
14 count = atoi(argv[2]); //convert the second arg into an interger
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
__GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
292 ../stdlib/strtol_l.c: No such file or directory.
(gdb) x/3xw 0x7fffffffdeb8
0x7fffffffdeb8: 0xffffe220 0x00007fff 0xffffe250
(gdb) x/s 0xffffe220
0xffffe220: <error: Cannot access memory at address 0xffffe220>
(gdb) x/s 0xffffe250
0xffffe250: <error: Cannot access memory at address 0xffffe250>
(gdb) x/sw 0xffffe250
0xffffe250: <error: Cannot access memory at address 0xffffe250>
(gdb)


I posted all of gdb output because i wasn't sure how much of it you would need. My problem lies at the bottom of my GDB output when i run "x/s" on gdb and get the <error: Cannot access memory at address 0xffffe250> error.



On the book Jon Erickson is able to access 0xffffe220 and 0x00007fff and then he has an error on 0xffffe250 this part of memory.



What am i missing?



Why can't i access any of the three addresses in 0x7fffffffdeb8?










share|improve this question




























    up vote
    2
    down vote

    favorite












    I am working on the book "HACKING Art Of Exploitation " exercise Convert2.c page 61.



    Here's my code. Below is my question.



    #include <stdio.h>

    void usage(char *program_name) {
    printf("Usage: %s <message> <# of times to repeat>n", program_name);
    exit(1);
    }

    int main(int argc, char *argv) {
    int i, count;

    // if(argc < 3) //if fewer than 3 arguments is used
    // usage(argv[0]); // display usage message and exit

    count = atoi(argv[2]); //convert the second arg into an interger
    printf("Repeating %d timesn", count);

    for(i=0; i < count; i++)
    printf("%3d - %sn", i, argv[1]); // print the first arg

    }


    GDB OUTPUT...



        ➜ git:(master) ✗ 👽 gdb -q a.out
    Reading symbols from a.out...done.
    (gdb) run test
    Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

    Program received signal SIGSEGV, Segmentation fault.
    __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
    loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
    292 ../stdlib/strtol_l.c: No such file or directory.
    (gdb) break main
    Breakpoint 1 at 0x555555554707: file convert.c, line 14.
    (gdb) where
    #0 __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
    loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
    #1 0x00007ffff7a29122 in __strtol (nptr=<optimized out>, endptr=endptr@entry=0x0, base=base@entry=10)
    at ../stdlib/strtol.c:106
    #2 0x00007ffff7a24690 in atoi (nptr=<optimized out>) at atoi.c:27
    #3 0x000055555555471f in main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
    (gdb) run test
    The program being debugged has been started already.
    Start it from the beginning? (y or n) y
    Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

    Breakpoint 1, main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
    14 count = atoi(argv[2]); //convert the second arg into an interger
    (gdb) cont
    Continuing.

    Program received signal SIGSEGV, Segmentation fault.
    __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
    loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
    292 ../stdlib/strtol_l.c: No such file or directory.
    (gdb) x/3xw 0x7fffffffdeb8
    0x7fffffffdeb8: 0xffffe220 0x00007fff 0xffffe250
    (gdb) x/s 0xffffe220
    0xffffe220: <error: Cannot access memory at address 0xffffe220>
    (gdb) x/s 0xffffe250
    0xffffe250: <error: Cannot access memory at address 0xffffe250>
    (gdb) x/sw 0xffffe250
    0xffffe250: <error: Cannot access memory at address 0xffffe250>
    (gdb)


    I posted all of gdb output because i wasn't sure how much of it you would need. My problem lies at the bottom of my GDB output when i run "x/s" on gdb and get the <error: Cannot access memory at address 0xffffe250> error.



    On the book Jon Erickson is able to access 0xffffe220 and 0x00007fff and then he has an error on 0xffffe250 this part of memory.



    What am i missing?



    Why can't i access any of the three addresses in 0x7fffffffdeb8?










    share|improve this question


























      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      I am working on the book "HACKING Art Of Exploitation " exercise Convert2.c page 61.



      Here's my code. Below is my question.



      #include <stdio.h>

      void usage(char *program_name) {
      printf("Usage: %s <message> <# of times to repeat>n", program_name);
      exit(1);
      }

      int main(int argc, char *argv) {
      int i, count;

      // if(argc < 3) //if fewer than 3 arguments is used
      // usage(argv[0]); // display usage message and exit

      count = atoi(argv[2]); //convert the second arg into an interger
      printf("Repeating %d timesn", count);

      for(i=0; i < count; i++)
      printf("%3d - %sn", i, argv[1]); // print the first arg

      }


      GDB OUTPUT...



          ➜ git:(master) ✗ 👽 gdb -q a.out
      Reading symbols from a.out...done.
      (gdb) run test
      Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

      Program received signal SIGSEGV, Segmentation fault.
      __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
      loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
      292 ../stdlib/strtol_l.c: No such file or directory.
      (gdb) break main
      Breakpoint 1 at 0x555555554707: file convert.c, line 14.
      (gdb) where
      #0 __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
      loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
      #1 0x00007ffff7a29122 in __strtol (nptr=<optimized out>, endptr=endptr@entry=0x0, base=base@entry=10)
      at ../stdlib/strtol.c:106
      #2 0x00007ffff7a24690 in atoi (nptr=<optimized out>) at atoi.c:27
      #3 0x000055555555471f in main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
      (gdb) run test
      The program being debugged has been started already.
      Start it from the beginning? (y or n) y
      Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

      Breakpoint 1, main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
      14 count = atoi(argv[2]); //convert the second arg into an interger
      (gdb) cont
      Continuing.

      Program received signal SIGSEGV, Segmentation fault.
      __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
      loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
      292 ../stdlib/strtol_l.c: No such file or directory.
      (gdb) x/3xw 0x7fffffffdeb8
      0x7fffffffdeb8: 0xffffe220 0x00007fff 0xffffe250
      (gdb) x/s 0xffffe220
      0xffffe220: <error: Cannot access memory at address 0xffffe220>
      (gdb) x/s 0xffffe250
      0xffffe250: <error: Cannot access memory at address 0xffffe250>
      (gdb) x/sw 0xffffe250
      0xffffe250: <error: Cannot access memory at address 0xffffe250>
      (gdb)


      I posted all of gdb output because i wasn't sure how much of it you would need. My problem lies at the bottom of my GDB output when i run "x/s" on gdb and get the <error: Cannot access memory at address 0xffffe250> error.



      On the book Jon Erickson is able to access 0xffffe220 and 0x00007fff and then he has an error on 0xffffe250 this part of memory.



      What am i missing?



      Why can't i access any of the three addresses in 0x7fffffffdeb8?










      share|improve this question















      I am working on the book "HACKING Art Of Exploitation " exercise Convert2.c page 61.



      Here's my code. Below is my question.



      #include <stdio.h>

      void usage(char *program_name) {
      printf("Usage: %s <message> <# of times to repeat>n", program_name);
      exit(1);
      }

      int main(int argc, char *argv) {
      int i, count;

      // if(argc < 3) //if fewer than 3 arguments is used
      // usage(argv[0]); // display usage message and exit

      count = atoi(argv[2]); //convert the second arg into an interger
      printf("Repeating %d timesn", count);

      for(i=0; i < count; i++)
      printf("%3d - %sn", i, argv[1]); // print the first arg

      }


      GDB OUTPUT...



          ➜ git:(master) ✗ 👽 gdb -q a.out
      Reading symbols from a.out...done.
      (gdb) run test
      Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

      Program received signal SIGSEGV, Segmentation fault.
      __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
      loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
      292 ../stdlib/strtol_l.c: No such file or directory.
      (gdb) break main
      Breakpoint 1 at 0x555555554707: file convert.c, line 14.
      (gdb) where
      #0 __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
      loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
      #1 0x00007ffff7a29122 in __strtol (nptr=<optimized out>, endptr=endptr@entry=0x0, base=base@entry=10)
      at ../stdlib/strtol.c:106
      #2 0x00007ffff7a24690 in atoi (nptr=<optimized out>) at atoi.c:27
      #3 0x000055555555471f in main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
      (gdb) run test
      The program being debugged has been started already.
      Start it from the beginning? (y or n) y
      Starting program: /home/fruitdealer/clones/C_zombie/hacking/a.out test

      Breakpoint 1, main (argc=2, argv=0x7fffffffdeb8) at convert.c:14
      14 count = atoi(argv[2]); //convert the second arg into an interger
      (gdb) cont
      Continuing.

      Program received signal SIGSEGV, Segmentation fault.
      __GI_____strtol_l_internal (nptr=0x0, endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
      loc=0x7ffff7dd0560 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
      292 ../stdlib/strtol_l.c: No such file or directory.
      (gdb) x/3xw 0x7fffffffdeb8
      0x7fffffffdeb8: 0xffffe220 0x00007fff 0xffffe250
      (gdb) x/s 0xffffe220
      0xffffe220: <error: Cannot access memory at address 0xffffe220>
      (gdb) x/s 0xffffe250
      0xffffe250: <error: Cannot access memory at address 0xffffe250>
      (gdb) x/sw 0xffffe250
      0xffffe250: <error: Cannot access memory at address 0xffffe250>
      (gdb)


      I posted all of gdb output because i wasn't sure how much of it you would need. My problem lies at the bottom of my GDB output when i run "x/s" on gdb and get the <error: Cannot access memory at address 0xffffe250> error.



      On the book Jon Erickson is able to access 0xffffe220 and 0x00007fff and then he has an error on 0xffffe250 this part of memory.



      What am i missing?



      Why can't i access any of the three addresses in 0x7fffffffdeb8?







      c linux gcc memory gdb






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 10 at 1:01

























      asked Nov 10 at 0:46









      Joel alexis

      154




      154
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          3
          down vote













          The first half of the address is cut off. If you notice, it takes 8 bytes to store the addresses because you are on a 64 bit machine, not 32. You are trying to access a truncated address.



          Rather than three addresses at 0x7fffffffdeb8, you are looking at one and a half. Try accessing a byte that starts with 0x00007fff...






          share|improve this answer



















          • 2




            In other words, don't use x/3xw, use x/3gx instead.
            – Employed Russian
            Nov 10 at 1:16










          • Ok i see. Thank you. I will use x/3gx the "g" for giant. Can you tell me how you are able to tell this is a 64-bit system just by looking at my gdb output? Blessings.
            – Joel alexis
            Nov 10 at 15:01








          • 1




            @Joelalexis you can tell by looking at the addresses the GDB outputs. On a 32-bit system, the memory address range is [0 to ((2^32)-1)] which is equal to [0x00000000 - 0xffffffff]. If you see an address that is outside this range in the GDB output (such as "loc=0x7ffff7dd0560"), that indicates you are on a 64-bit system. Alternatively you can examine the stack, as you are already doing.
            – jahneff
            Nov 10 at 19:38











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53235027%2fcant-access-a-specific-memory-address-on-c-program%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          3
          down vote













          The first half of the address is cut off. If you notice, it takes 8 bytes to store the addresses because you are on a 64 bit machine, not 32. You are trying to access a truncated address.



          Rather than three addresses at 0x7fffffffdeb8, you are looking at one and a half. Try accessing a byte that starts with 0x00007fff...






          share|improve this answer



















          • 2




            In other words, don't use x/3xw, use x/3gx instead.
            – Employed Russian
            Nov 10 at 1:16










          • Ok i see. Thank you. I will use x/3gx the "g" for giant. Can you tell me how you are able to tell this is a 64-bit system just by looking at my gdb output? Blessings.
            – Joel alexis
            Nov 10 at 15:01








          • 1




            @Joelalexis you can tell by looking at the addresses the GDB outputs. On a 32-bit system, the memory address range is [0 to ((2^32)-1)] which is equal to [0x00000000 - 0xffffffff]. If you see an address that is outside this range in the GDB output (such as "loc=0x7ffff7dd0560"), that indicates you are on a 64-bit system. Alternatively you can examine the stack, as you are already doing.
            – jahneff
            Nov 10 at 19:38















          up vote
          3
          down vote













          The first half of the address is cut off. If you notice, it takes 8 bytes to store the addresses because you are on a 64 bit machine, not 32. You are trying to access a truncated address.



          Rather than three addresses at 0x7fffffffdeb8, you are looking at one and a half. Try accessing a byte that starts with 0x00007fff...






          share|improve this answer



















          • 2




            In other words, don't use x/3xw, use x/3gx instead.
            – Employed Russian
            Nov 10 at 1:16










          • Ok i see. Thank you. I will use x/3gx the "g" for giant. Can you tell me how you are able to tell this is a 64-bit system just by looking at my gdb output? Blessings.
            – Joel alexis
            Nov 10 at 15:01








          • 1




            @Joelalexis you can tell by looking at the addresses the GDB outputs. On a 32-bit system, the memory address range is [0 to ((2^32)-1)] which is equal to [0x00000000 - 0xffffffff]. If you see an address that is outside this range in the GDB output (such as "loc=0x7ffff7dd0560"), that indicates you are on a 64-bit system. Alternatively you can examine the stack, as you are already doing.
            – jahneff
            Nov 10 at 19:38













          up vote
          3
          down vote










          up vote
          3
          down vote









          The first half of the address is cut off. If you notice, it takes 8 bytes to store the addresses because you are on a 64 bit machine, not 32. You are trying to access a truncated address.



          Rather than three addresses at 0x7fffffffdeb8, you are looking at one and a half. Try accessing a byte that starts with 0x00007fff...






          share|improve this answer














          The first half of the address is cut off. If you notice, it takes 8 bytes to store the addresses because you are on a 64 bit machine, not 32. You are trying to access a truncated address.



          Rather than three addresses at 0x7fffffffdeb8, you are looking at one and a half. Try accessing a byte that starts with 0x00007fff...







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 10 at 1:18

























          answered Nov 10 at 1:07









          jahneff

          433




          433








          • 2




            In other words, don't use x/3xw, use x/3gx instead.
            – Employed Russian
            Nov 10 at 1:16










          • Ok i see. Thank you. I will use x/3gx the "g" for giant. Can you tell me how you are able to tell this is a 64-bit system just by looking at my gdb output? Blessings.
            – Joel alexis
            Nov 10 at 15:01








          • 1




            @Joelalexis you can tell by looking at the addresses the GDB outputs. On a 32-bit system, the memory address range is [0 to ((2^32)-1)] which is equal to [0x00000000 - 0xffffffff]. If you see an address that is outside this range in the GDB output (such as "loc=0x7ffff7dd0560"), that indicates you are on a 64-bit system. Alternatively you can examine the stack, as you are already doing.
            – jahneff
            Nov 10 at 19:38














          • 2




            In other words, don't use x/3xw, use x/3gx instead.
            – Employed Russian
            Nov 10 at 1:16










          • Ok i see. Thank you. I will use x/3gx the "g" for giant. Can you tell me how you are able to tell this is a 64-bit system just by looking at my gdb output? Blessings.
            – Joel alexis
            Nov 10 at 15:01








          • 1




            @Joelalexis you can tell by looking at the addresses the GDB outputs. On a 32-bit system, the memory address range is [0 to ((2^32)-1)] which is equal to [0x00000000 - 0xffffffff]. If you see an address that is outside this range in the GDB output (such as "loc=0x7ffff7dd0560"), that indicates you are on a 64-bit system. Alternatively you can examine the stack, as you are already doing.
            – jahneff
            Nov 10 at 19:38








          2




          2




          In other words, don't use x/3xw, use x/3gx instead.
          – Employed Russian
          Nov 10 at 1:16




          In other words, don't use x/3xw, use x/3gx instead.
          – Employed Russian
          Nov 10 at 1:16












          Ok i see. Thank you. I will use x/3gx the "g" for giant. Can you tell me how you are able to tell this is a 64-bit system just by looking at my gdb output? Blessings.
          – Joel alexis
          Nov 10 at 15:01






          Ok i see. Thank you. I will use x/3gx the "g" for giant. Can you tell me how you are able to tell this is a 64-bit system just by looking at my gdb output? Blessings.
          – Joel alexis
          Nov 10 at 15:01






          1




          1




          @Joelalexis you can tell by looking at the addresses the GDB outputs. On a 32-bit system, the memory address range is [0 to ((2^32)-1)] which is equal to [0x00000000 - 0xffffffff]. If you see an address that is outside this range in the GDB output (such as "loc=0x7ffff7dd0560"), that indicates you are on a 64-bit system. Alternatively you can examine the stack, as you are already doing.
          – jahneff
          Nov 10 at 19:38




          @Joelalexis you can tell by looking at the addresses the GDB outputs. On a 32-bit system, the memory address range is [0 to ((2^32)-1)] which is equal to [0x00000000 - 0xffffffff]. If you see an address that is outside this range in the GDB output (such as "loc=0x7ffff7dd0560"), that indicates you are on a 64-bit system. Alternatively you can examine the stack, as you are already doing.
          – jahneff
          Nov 10 at 19:38


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53235027%2fcant-access-a-specific-memory-address-on-c-program%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Schultheiß

          Verwaltungsgliederung Dänemarks

          Liste der Kulturdenkmale in Wilsdruff