Application Reading Itself

[ReaperUnreal]

I'm writing an application that will store some hidden and encrypted
data at the end of the file, however, I'm having trouble getting the
application to read itself. Here's the code I have:

FILE *myself = NULL;
if(!(myself = fopen("AppReader.exe", "rb")))
{
fprintf(stderr, "Cannot open file to read.");
}
fseek(myself, -8, SEEK_END);
char buffer[10];
fread(buffer, 1, 8, myself);
buffer[8] = '\0';
printf("String: %s\n", buffer);
fclose(myself);

I realize that this isn't exactly the safest application, and that I
have no real error measures in place, however this is just a test to
see if it will work.

So the question is, does anyone know how to get it to work?

 

[Ed Prochak]

I'm writing an application that will store some hidden and encrypted
data at the end of the file, however, I'm having trouble getting the
application to read itself. Here's the code I have:

FILE *myself = NULL;
if(!(myself = fopen("AppReader.exe", "rb")))
{
fprintf(stderr, "Cannot open file to read.");
}
fseek(myself, -8, SEEK_END);
char buffer[10];
fread(buffer, 1, 8, myself);
buffer[8] = '\0';
printf("String: %s\n", buffer);
fclose(myself);

I realize that this isn't exactly the safest application, and that I
have no real error measures in place, however this is just a test to
see if it will work.

So the question is, does anyone know how to get it to work?

so what do you mean by:

having trouble getting the
application to read itself ? or by:
get it to work?

What errors do you get? what data do you get that you do not expect?
(how are you building the exe to guarantee the value you want is at the
end???)

We aren't mind readers. Explain the problem.
Ed

 

[Malcolm]

I'm writing an application that will store some hidden and encrypted
data at the end of the file, however, I'm having trouble getting the
application to read itself. Here's the code I have:

FILE *myself = NULL;
if(!(myself = fopen("AppReader.exe", "rb")))
{
fprintf(stderr, "Cannot open file to read.");
}
fseek(myself, -8, SEEK_END);
char buffer[10];
fread(buffer, 1, 8, myself);
buffer[8] = '\0';
printf("String: %s\n", buffer);
fclose(myself);

I realize that this isn't exactly the safest application, and that I
have no real error measures in place, however this is just a test to
see if it will work.

So the question is, does anyone know how to get it to work?

argv[0] normally contains the name of the executable, often a path to it.

The OS may allow you to open this as a regular binary file. However a lot
won't because of the obvious security hazards.
The portable way to include data in your executable is to include it as a C
array. However you cannot guarantee being able to edit this data after
compilation - some systems will let you do so, others won't.

There are also many platform specific ways of including data objects in C
programs.

 

[Barry Schwarz]

I'm writing an application that will store some hidden and encrypted
data at the end of the file, however, I'm having trouble getting the
application to read itself. Here's the code I have:

FILE *myself = NULL;
if(!(myself = fopen("AppReader.exe", "rb")))
{
fprintf(stderr, "Cannot open file to read.");
}
fseek(myself, -8, SEEK_END);
char buffer[10];
fread(buffer, 1, 8, myself);
buffer[8] = '\0';
printf("String: %s\n", buffer);
fclose(myself);

I realize that this isn't exactly the safest application, and that I
have no real error measures in place, however this is just a test to
see if it will work.

So the question is, does anyone know how to get it to work?

Unless the last 8 characters in your file are guaranteed to be
printable and not contain '\0', your printf will produce
unrecognizable output. You may want to print each buffer (i going
from 0 to 7) as an unsigned char with %x.


Remove del for email

 

[ReaperUnreal]

Actually, I found the problem myself, and you were all way off. You'll
carefully notice that I fseek to the end of the file with a -8 offset.
Apparently, the offset is ignored if I use the SEEK_END flag. So an
additional fseek solved the problem.

 

[Keith Thompson]

Actually, I found the problem myself, and you were all way off. You'll
carefully notice that I fseek to the end of the file with a -8 offset.
Apparently, the offset is ignored if I use the SEEK_END flag. So an
additional fseek solved the problem.

Please provide some context when you post a followup.

According to the C standard:

For a binary stream, the new position, measured in characters from
the beginning of the file, is obtained by adding offset to the
position specified by whence. The specified position is the
beginning of the file if whence is SEEK_SET, the current value of
the file position indicator if SEEK_CUR, or end-of-file if
SEEK_END. A binary stream need not meaningfully support fseek
calls with a whence value of SEEK_END.

The last sentence is intended to cover systems that don't store the
exact size in bytes of a binary file; for example, a binary file can
legally be implicitly padded with null bytes up to a multiple of some
block size. As far as I know, it's unlikely that any system you're
likely to be using is affected by this.

In other words, I'd be very surprised if fseek() with the SEEK_END
flag actually did ignore the offset (though it's allowed by the
standard). Though you may be correct, my guess is that you've somehow
misunderstood what's really going on, and your fix works only by
accident.

 

[Barry Schwarz]

Actually, I found the problem myself, and you were all way off. You'll
carefully notice that I fseek to the end of the file with a -8 offset.
Apparently, the offset is ignored if I use the SEEK_END flag. So an
additional fseek solved the problem.

Not likely. Chances are you have camouflaged another problem.

There is nothing in n1124 that allows fseek to ignore the offset
value. SEEK_END need not be meaningfully supported for a binary, but
then the result should be the same regardless of how many fseek calls
you make.


Remove del for email

 

[Keith Thompson]

Not likely. Chances are you have camouflaged another problem.

There is nothing in n1124 that allows fseek to ignore the offset
value.

Actually, I think there is. I interpret the phrase "need not
meaningfully support" to denote undefined behavior. (Since the
behavior isn't defined, I don't see how else to interpret it.)

SEEK_END need not be meaningfully supported for a binary, but
then the result should be the same regardless of how many fseek calls
you make.

Yes, I agree that it should be, and that this is not likely to be the
cause of the OP's problem.

 

[ReaperUnreal]

Well, I just noticed that in fact that wasn't my problem. My real
problem was that the file I was searching for isn't in the root
directory. I forgot to stick a return statement in the null check, and
so it was continuing.

 

[Kenny McCormack]

Well, I just noticed that in fact that wasn't my problem. My real
problem was that the file I was searching for isn't in the root
directory. I forgot to stick a return statement in the null check, and
so it was continuing.

Well. That's a relief.