I have a problem compiling the following exploit code:
http://downloads.securityfocus.com/vulnerabilities/exploits/59846-1.c
I am using "gcc file.c" and "gcc -O2 file.c", but both of them results in the following errors:
sorbolinux-exec.c: In function ‘sc’:
sorbolinux-exec.c:76: error: stray ‘\302’ in program
sorbolinux-exec.c:76: error: stray ‘\244’ in program
sorbolinux-exec.c:76: error: ‘t’ undeclared (first use in this function)
sorbolinux-exec.c:76: error: (Each undeclared identifier is reported only once
sorbolinux-exec.c:76: error: for each function it appears in.)
I tried compiling them on both Kali Linux and Ubuntu 10.04 (Lucid Lynx) and got the same result.
You have an invalid character on that line. This is what I saw:
You have invalid characters in your source. If you don't have any valid non-ASCII characters in your source, maybe in a double quoted string literal, you can simply convert your file back to ASCII with:
tr -cd '\11\12\15\40-\176' < old.c > new.c
The method with iconv will stop at wrong characters which makes no sense. The above command line is working with the example file.
Sure, convert the file to ASCII and blast all Unicode characters away.
It will probably work... But...
You won't know what you fixed.
It will also destroy any Unicode comments. Example: //: A²+B²=C²
It could potentially damage obvious logic and the code will still be broken,
but the solution less obvious.
For example: A string with "Smart-Quotes" (“ & ”) or a pointer with a full-width asterisk (＊). Now “SOME_THING” looks like a #define (SOME_THING) and ＊SomeType is the wrong type (SomeType).
Two more surgical approaches to fixing the problem:
Switch fonts to see the character. (It might be invisible in your current font)
Regular expression search all Unicode characters not part of non-extended ASCII.
In Notepad++ I can search up to FFFF, which hasn't failed me yet.
[\x{80}-\x{FFFF}]
80 is hex for 128, the first extended ASCII character.
After hitting "find next" and highlighting what appears to be empty space, you can close your search dialog and press Ctrl + C to copy to clipboard.
Then paste the character into a Unicode search tool.
I usually use an online one.
http://unicode.scarfboy.com/
Example:
I had a bullet point (•) in my code somehow.
The Unicode value is 2022 (hex), but when read as ASCII by the compiler
you get \342 \200 \242 (3 octal values). It's not as simple as converting each octal values to hex and smashing them together. So "E2 80 A2" is not the hexadecimal Unicode point in your code.
I got the same with a character that visibly appeared as an asterisk, but it was a UTF-8 sequence instead:
Encoder * st;
When compiled, it returned:
g.c:2:1: error: stray ‘\342’ in program
g.c:2:1: error: stray ‘\210’ in program
g.c:2:1: error: stray ‘\227’ in program
342 210 227 turns out to be UTF-8 for ASTERISK OPERATOR (Unicode code point U+2217).
Deleting the '*' and typing it again fixed the problem.
Whenever the compiler found a special character, it gives these kind of compile errors. The error I found is as follows:
error: stray '\302' in program and error: stray '\240' in program
....
It is some piece of code I copied from a chat messenger. In Facebook Messenger, it was a special character only. After copying into the Vim editor it changed to the correct character only. But the compiler was giving the above error .. then .. that statement I wrote manually after .. it got resolved... :)
It's perhaps because you copied code from the Internet (from a site which has perhaps not an ASCII encoded page, but a UTF-8 encoded page), so you can convert the code to ASCII from this site:
"http://www.percederberg.net/tools/text_converter.html"
There you can either detect errors manually by converting it back to UTF-8, or you can automatically convert it to ASCII and remove all the stray characters.
This problem comes when you have copied some text from an HTML page or you have done modification in a Windows environment and are trying to compile in a Unix/Solaris environment.
Please do "dos2unix" to remove the special characters from the file:
dos2unix fileName.ext fileName.ext
Invalid character in your code.
It is a common copy-paste error, especially when code is copied from Microsoft Word documents or PDF files.
I noticed an issue in using the above tr command. The tr command COMPLETELY removes the "smart quotes". It would be better to replace the "smart quotes" with something like this.
This will give you a quick preview of what will be replaced.
sed s/[”“]/'"'/g File.txt
This will do the replacements and put the replacement in a new file called WithoutSmartQuotes.txt.
sed s/[”“]/'"'/g File.txt > WithoutSmartQuotes.txt
This will overwrite the original file.
sed -i ".bk" s/[”“]/'"'/g File.txt
http://developmentality.wordpress.com/2010/10/11/how-to-remove-smart-quotes-from-a-text-file/
Codo was exactly right on Oct. 5 that ¤t[i] is the intended text (with the currency symbol inadvertently introduced when the source was put into HTML (see original):
http://downloads.securityfocus.com/vulnerabilities/exploits/59846-1.c
Codo's change makes this exploit code compile without error. I did that and was able to use the exploit on Ubuntu 12.04 (Precise Pangolin) to escalate to root privilege.
The explanations given here are correct. I just wanted to add that this problem might be because you copied the code from somewhere, from a website or a PDF file due to which there are some invalid characters in the code.
Try to find those invalid characters, or just retype the code if you can't. It will definitely compile then.
Source: stray error reason
With me, this error occurred when I copied and pasted code in text format to my editor (gedit).
The code was in a text document (.odt). I copied it and pasted it into gedit.
If you did the same, you have manually rewrite the code.
Sometimes I will get incorrect error-highlighting on a closing parenthesis or brace. Here is a good example using a function pointer:
Now, unless I have a syntax error that I'm not seeing (please point it out if so!), how would I get rid of this formatting? Is there a particular setting or perhaps syntax file where this can be fixed?
So I am trying to use bison's semantic predicate feature, but I've been running into a few issues trying to have it work.
The problem comes when I try to compile the generated .tab.c file with gcc. I am using gcc 7.1.0 and bison 3.0.4. Here's a snippet of the compile error:
test2.tab.c: In function ‘yyuserAction’:
test2.tab.c:811:12: error: stray ‘#’ in program
if (! (#line 19 "test2.y" /* glr.c:816 */
^
test2.tab.c:811:13: error: ‘line’ undeclared (first use in this function); did you mean ‘uint’?
if (! (#line 19 "test2.y" /* glr.c:816 */
^~~~
uint
So I've taken bison's example for semantic predicate, and made it a working example:
%{
int new_syntax = 0;
int yyerror(const char* msg) { /* some error handling */ }
%}
%token id
%glr-parser
%%
prog: %empty
| prog widget
| prog flip
;
widget: %?{ new_syntax } "widget" id old_arg
| %?{ !new_syntax } "widget" id new_arg
;
flip: "flip" { new_syntax = !new_syntax; }
;
old_arg: /* something here */
;
new_arg: /* something else here */
;
%%
After playing around with the tab file, I realized that adding a newline before the #line directives resolves the syntax error, (but it feels kinda hacky directly modifying the generated file. Plus, you would have to align with some spaces in order for gcc to compute the right column position of the code).
I wonder if is this a bug with bison itself, or is it that I'm using semantic predicates wrong, or if this syntax was correct in an earlier version of gcc, or something else.
I've also tried searching the web for this issue, or for a bug already filed with bison, but I found none. (The latest bison version seems to be 3-ish years old. I would be surprised if this issue has not been addressed anywhere at all). Can someone enlighten me about this issue? Thanks.
If necessary, I could try filing a bug with bison (need to figure out how to do that), but I'm not sure if it's my own issue or what not.
As far as I can see, this bug has been present for some time (possibly since the semantic predicate feature was introduced, although it seems like someone should have tested it at some point with some version of bison.)
The simplest workaround is to turn off the generation of #line directives, which you can do by simply adding -l (or --no-lines) to the bison command line. However, that will make it harder to interpret error messages which would otherwise refer to line numbers in your bison grammar file.
As a second workaround, you could find the file c.m4, which is probably in /usr/share/bison/c.m4 (of course, that depends on your distribution). Line 462 of that file (in bison 3.0.4) reads:
if (! ($2)) YYERROR;
If you add a newline just before $2, so that it reads
if (! (
$2)) YYERROR;
then everything should work out fine. (At least, it did when I tested it.)
I am getting the following compiler warning when I use the following to skip a line when reading a file with fscanf with C:
warning: too many arguments for format [-Wformat-extra-args]
fscanf(myFile, "%*[^\n]\n", NULL);
The program works perfectly fine. However, I wonder if there is an approach to skip a line in a file that is as minimalistic as the above and does not give compiler warnings (or a simple edit to the above would be ideal)? This approach to skipping a line was taken from How to skip the first line when fscanning a .txt file? where there is no mention of any such warning. Other methods of skipping a line are presented in this previous question; however, none are as minimalistic as the above.
Remove the NULL. The warning is because the compiler understood from the * that you dont want to store the result anywhere (but just advance the file with the specified pattern). But then it gets somehow "surprised" that you specify a location (be it NULL).
I couldn't find anything on this, but probably its just because I don't know how to search, because i don't know how to call it.
I tried to compile some C-Code and got the following error:
/path/to/file.h:55:32: error: path/to/include.h: No such file or directory
I know the error and i know that the problem is in file.h at line 55 - where's an include, which doesn't exist.
But what does the 32 stand for?
Marty
It's the number of the character within line 55.
This might also be referred to as "column number" (see comment) but I find that slightly misleading, as e.g. a tab character will generally take up more than one column in your editor, but still count as only one character for the compiler.