By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,326 Members | 2,726 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,326 IT Pros & Developers. It's quick & easy.

(char *) type vars and .rdata section

P: n/a
Ws
Ok, so I have a question reguarding compilers and placing strings into
the .rdata section of the PE.

I was working on a program and couldn't figure out why I was getting a
0xc0000005 error message (memory access violation) while trying to
alter a (char *) data type'd variable. Proper size, pointers all
accurate and verified. I finally got frustrated enough and tried
something else, built it as a Release application (using Microsoft
Visual Studio 2005 Professional -- it is a legitimate copy, believe it
or not), and took it into OllyDbg.

My finding in OllyDbg was that it was storing the string in the .rdata
section of the PE, and that this section of the file was Read-Only
access. Ok, that answers why it was erroring.

== But more to the point, why did the compiler place the string in
the .rdata section?! I have prepared a short sample code that
duplicates the same problem. (merged stdafx.h into the source inline
to show the concept.)

Expand|Select|Wrap|Line Numbers
  1. #ifndef _WIN32_WINNT
  2. #define _WIN32_WINNT 0x0501
  3. #endif
  4.  
  5. #include <stdio.h>
  6. #include <stdlib.h>
  7. #include <conio.h>
  8.  
  9. void alter_data( char * data )
  10. {
  11. // simply sets the first byte to be 'b' instead
  12. data[0] ^= 'b';
  13. }
  14.  
  15. int main ( int argc, char ** argv )
  16. {
  17. char *my_data = "Hello, world!";
  18.  
  19. printf( "%s\n", my_data );
  20. alter_data( my_data );
  21. printf( "%s\n", my_data );
  22.  
  23. // pause
  24. _getch();
  25.  
  26. return 0;
  27. }
  28.  
Anyone have any pointers as to why VC++ placed the my_data string into
the .rdata section of the file?

Thanks in advance for any pointers on this query :)

-Wes

Aug 6 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On Mon, 06 Aug 2007 15:42:40 -0000, Ws <no***************@gmail.com>
wrote:
>Ok, so I have a question reguarding compilers and placing strings into
the .rdata section of the PE.

I was working on a program and couldn't figure out why I was getting a
0xc0000005 error message (memory access violation) while trying to
alter a (char *) data type'd variable. Proper size, pointers all
accurate and verified. I finally got frustrated enough and tried
something else, built it as a Release application (using Microsoft
Visual Studio 2005 Professional -- it is a legitimate copy, believe it
or not), and took it into OllyDbg.

My finding in OllyDbg was that it was storing the string in the .rdata
section of the PE, and that this section of the file was Read-Only
access. Ok, that answers why it was erroring.

== But more to the point, why did the compiler place the string in
the .rdata section?! I have prepared a short sample code that
duplicates the same problem. (merged stdafx.h into the source inline
to show the concept.)

Expand|Select|Wrap|Line Numbers
  1. #ifndef _WIN32_WINNT
  2. #define _WIN32_WINNT 0x0501
  3. #endif
  4. #include <stdio.h>
  5. #include <stdlib.h>
  6. #include <conio.h>
  7. void alter_data( char * data )
  8. {
  9.     // simply sets the first byte to be 'b' instead
  10.     data[0] ^= 'b';
  11. }
  12. int main ( int argc, char ** argv )
  13. {
  14.     char *my_data = "Hello, world!";
  15.     printf( "%s\n", my_data );
  16.     alter_data( my_data );
  17.     printf( "%s\n", my_data );
  18.     // pause
  19.     _getch();
  20.     return 0;
  21. }

Anyone have any pointers as to why VC++ placed the my_data string into
the .rdata section of the file?
I'll try to save the regulars the trouble...

C FAQs 8.5 & 1.32 and others.

http://c-faq.com/charstring/strlitinit.html

Bill
--
William D Waddington
wi****************@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
Aug 6 '07 #2

P: n/a
Ws wrote, On 06/08/07 16:42:

<snip>
My finding in OllyDbg was that it was storing the string in the .rdata
section of the PE, and that this section of the file was Read-Only
access. Ok, that answers why it was erroring.

== But more to the point, why did the compiler place the string in
the .rdata section?!
Because it is allowed to and it felt like it. Read question 1.32 of the
comp.lang.c FAQ at http://c-faq.com/
I have prepared a short sample code that
duplicates the same problem. (merged stdafx.h into the source inline
to show the concept.)

Expand|Select|Wrap|Line Numbers
  1. #ifndef _WIN32_WINNT
  2. #define _WIN32_WINNT 0x0501
  3. #endif
  4. #include <stdio.h>
  5. #include <stdlib.h>
  6. #include <conio.h>
  7. void alter_data( char * data )
  8. {
  9.     // simply sets the first byte to be 'b' instead
Expand|Select|Wrap|Line Numbers
  1.  
  2. // style comments were only added to the C standard in C99, a standard
  3. that MSVC does not support. It might support it as an extension or you
  4. might be compiling the code as C++ by mistake, in either case you need
  5. to check your compiler options carefully.
  6.  
  7.         
  8.                     data[0] ^= 'b';
  9.  
  10. This line does not attempt to set the first byte to 'b' so either your
  11. comment is wrong or the above line is wrong.
  12.  
  13.         
  14.                 }
  15. int main ( int argc, char ** argv )
  16. {
  17.     char *my_data = "Hello, world!";
  18.  
  19. Although the C standard does not make string literals const qualified it
  20. explicitly says that modifying them invokes "undefined behaviour", i.e.
  21. you are not allowed to do it but the compiler is not required to warn
  22. you about it. One reason for this is so that string literals *can* be
  23. placed in read only memory.
  24.  
  25.         
  26.                     printf( "%s\n", my_data );
  27.     alter_data( my_data );
  28.     printf( "%s\n", my_data );
  29.     // pause
  30.     _getch();
  31.  
  32. I believe you can get MSVC to not close the output window on program
  33. termination and thus avoid the need to pause the program. Even if you
  34. did need to you could use the standard getchar function instead of the
  35. non-standard _getch function. Why make your program non-portable when
  36. you don't need to?
  37.  
  38.         
  39.                     return 0;
  40. }
  41.  
  42.  
>
Anyone have any pointers as to why VC++ placed the my_data string into
the .rdata section of the file?
Because you should not be trying to modify it.
--
Flash Gordon
Aug 6 '07 #3

P: n/a
Ws
On Aug 6, 9:00 am, Bill Waddington <william.wadding...@beezmo.com>
wrote:
C FAQs 8.5 & 1.32 and others.

http://c-faq.com/charstring/strlitinit.html
Heh, sorry, it's been a while since I'd been trying to learn C/++ so I
had forgotten about that lovely resource. Sorry for wasting time with
a frivolous query.

-Wes

Aug 7 '07 #4

P: n/a
Ws
On Aug 6, 8:58 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
This line does not attempt to set the first byte to 'b' so either your
comment is wrong or the above line is wrong.
Comment is wrong. Altered it for an XOR to better tinker with it, and
forgot to update the comment since it is just a demo code block.
Although the C standard does not make string literals const qualified it
explicitly says that modifying them invokes "undefined behaviour", i.e.
you are not allowed to do it but the compiler is not required to warn
you about it. One reason for this is so that string literals *can* be
placed in read only memory.
Thank you for a full elaboration as to why a compiler would/could do
that. Much appreciated taking the time :)
I believe you can get MSVC to not close the output window on program
termination and thus avoid the need to pause the program. Even if you
did need to you could use the standard getchar function instead of the
non-standard _getch function. Why make your program non-portable when
you don't need to?
Eh, don't know, just sort of did it, as I'm just trying to learn C++
by hacking, not by any formalized teaching from a book or such, as
every time I pick up some 800 page (exaggeration, but I digress) I get
distracted very easy, and I've always ended up learning faster by
tinkering over time. :)

But again, thanks for your elaboration! Much appreciated.

Aug 7 '07 #5

P: n/a
Ws wrote:
Bill Waddington <william.wadding...@beezmo.comwrote:
>>
C FAQs 8.5 & 1.32 and others.

http://c-faq.com/charstring/strlitinit.html

Heh, sorry, it's been a while since I'd been trying to learn C/++
so I had forgotten about that lovely resource. Sorry for wasting
time with a frivolous query.
Just a word of caution - this is comp.lang.c, not c++. C++ is
another language, and discussion here is off-topic. So far you
have been discussing C, so no real problem yet.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Aug 7 '07 #6

P: n/a
Ws wrote, On 07/08/07 06:37:

<snip>
Eh, don't know, just sort of did it, as I'm just trying to learn C++
by hacking, not by any formalized teaching from a book or such, as
every time I pick up some 800 page (exaggeration, but I digress) I get
distracted very easy, and I've always ended up learning faster by
tinkering over time. :)
Trying to learn C or C++ (they are very different languages) by
tinkering is not, in my opinion, very good. There is lots of stuff which
might happen to work using your current setup but which is nevertheless
still wrong and would fail if you change optimisation level. For C I
recommend K&R 2nd edition which is nice and short, ask in comp.lang.c++
if you want recommendations for C++.
--
Flash Gordon
Aug 7 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.