Gamestudio Links
Zorro Links
Newest Posts
Newbie Questions
by fairtrader. 12/06/23 11:29
Zorro Trader GPT
by TipmyPip. 12/04/23 11:34
Square root rule
by Smallz. 12/02/23 09:15
RTest not found error
by TipmyPip. 12/01/23 21:43
neural function for Python to [Train]
by TipmyPip. 12/01/23 14:47
Xor Memory Problem.
by TipmyPip. 11/28/23 14:23
Training with command line parameters
by TipmyPip. 11/26/23 08:42
Combine USD & BTC Pairs In Asset Loop
by TipmyPip. 11/26/23 08:30
AUM Magazine
Latest Screens
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Tactics of World War I
Who's Online Now
7 registered members (3run, miwok, AndrewAMD, Quad, TipmyPip, fairtrader, 1 invisible), 637 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
Newest Members
fairtrader, hus, Vurtis, Harry5, KelvinC
19019 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 2 of 2 1 2
Re: detecting wrong file types [Re: Germanunkol] #290751
09/21/09 04:48
09/21/09 04:48
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Quote:
file_load returns a "buffer" (manual doesn't even define that), meaning a space in memory, if I understand it right. you're assigning the char pointer "pImage" to point at that memory space.
Exactly correct. The FIRST BYTE or CHAR of that space, also known as pimage[0].


Quote:
...But apparently, _str() doesn't know what to do with that...
Yes it does, it is using it as an array of CHAR bytes, and the array has 'size' entries/elements. (size = the EXACT file length in bytes)
(Think of it being the same as _str("the-contents-of-pimage") if that helps)

So by putting the pimage inside the '_str()' function, you have turned the whole of pimage into a huge temporary string, of length 'size'.
Now any other (lite-c) str_xxx functions can 'handle' it without (too many) problems.


Quote:
I also don't understand why you use pImage like an array afterwards. size-30 ? is pImage now an array with each element being... what? a bit? a byte? help?
As you should now know, from higher in this post, 'pimage' IS an array of bytes or chars.
I always say both when talking about 'byte's or 'char's because,for the most part, they are largely interchangable.
The reason I used "size-30" is because I wanted to start searching(str_stri) for the important text("TRUEVISION-XFILE."),
from 30 bytes BEFORE the end of the file. (this was a bad choice I believe, see later comment)

Now do you see why your code str(pImage[size]) is bad?
Because you are setting the FIRST character of the temporary string to the LAST byte of the file. So you'll only read junk.

As I said earlier, I made a bad choice by suggesting "size-30". I did this so the important text("TRUEVISION-XFILE.") would be
safely 'captured as a substring(being the last 30 characters) for the str_stri() function.
That was a bad idea, because that left 'junk' data at the start of that compared sub-string, and if that junk contains any NULLs,
then the str_stri() will give a "not found" result. That sucks.

So it needs to set the START of the sub-string to be the EXPECTED first character of the test we are looking for.
To me, as I said in my original post, that APPEARS to be "TRUEVISION-XFILE." starting 19 bytes in from the end of the file.
So we SHOULD be looking at the sub-string "pimage[size-19]".
(or maybe 18 depending on if the NULL end-byte counts, you'll need to test that to see)


Thats all I can think of for now, but if youve got more questions, OR Ive made things MORE confusing,
just let me know and I'll try to help....


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: detecting wrong file types [Re: EvilSOB] #290825
09/21/09 16:39
09/21/09 16:39
Joined: Jun 2006
Posts: 2,640
Earth
Germanunkol Offline OP
Expert
Germanunkol  Offline OP
Expert

Joined: Jun 2006
Posts: 2,640
Earth
Hm. It clears up a lot, but I still can't get it to work.

I didn't know that accessing pImage[NUMBER] returns the char array to the end of the array, from that position onwards. If I have an array of integers, calling intArray[10] only returns the value of that element, not a whole line of numbers... but with this char array, it returns all the following characters? why?

Ok, that being said, this works:

Code:
long size;
char* pImage = "TRUEVISION-XFILE.";
	str_cpy((checkFileText.pstring)[0],_str(pImage[0]));
	str_cat((checkFileText.pstring)[0],"something else");
	
	if(str_stri(_str(pImage[0]), "TRUEVISION-XFILE."))
	{
		   //its a TGA
		   beep();
		          }
	else
	{  
		
	 //its NOT a TGA
	    }




but why doesn't this following code work? I can try [size-30], [size-19], [0]... nothing even copies any value into the string, besides "something else".
Code:
long size;
	char* pImage = file_load("tga2.tga",NULL,&size);
	
	str_cpy((checkFileText.pstring)[0],_str(pImage[0]));
	str_cat((checkFileText.pstring)[0],"something else");
	
	if(str_stri(_str(pImage[0]), "TRUEVISION-XFILE."))
	{
		   //its a TGA
		   beep();
		          }
	else
	{  
		
	 //its NOT a TGA
	    }
	    
	file_load(NULL,pImage,NULL);  //assuming youve finished with it



if I replace the line:
str_cpy((checkFileText.pstring)[0],_str(pImage[0]));
with:
str_for_num((checkFileText.pstring)[0],size);
I get:
306613something else
As the output...
so "size" is set... right?


~"I never let school interfere with my education"~
-Mark Twain
Re: detecting wrong file types [Re: Germanunkol] #290869
09/22/09 01:23
09/22/09 01:23
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Quote:
I didn't know that accessing pImage[NUMBER] returns the char array to the end of the array, from that position onwards. If I have an array of integers, calling intArray[10] only returns the value of that element, not a whole line of numbers... but with this char array, it returns all the following characters? why?
I seem to have confused you a bit here,I must be explaining badly, , or Im misunderstanding this quote, so I'll try again.

Firstly, char arrays dont really return "all the following characters", its just because we are using the _str() function, and IT is what
takes the single character we give it, and uses it as the first character of a temporary string.
The temporary string is then going to start at your supplied position, and ending at the first NULL character.
Most of the other built-in lite-c str_xxx functions do this too, as far as I can tell.

So accessing pImage[NUMBER] returns the char array STARTING at char position NUMBER, and ending at the first NULL,
regardless of the actual length of the array. I call this a "sub-string" for ease of understanding.

So try your second code block with these values. [size-16], [size-17], [size-18], [size-19], and [size-20].
ONE of them will be correct...

Quote:
if I replace the line:
str_cpy((checkFileText.pstring)[0],_str(pImage[0]));
with:
str_for_num((checkFileText.pstring)[0],size);
I get:
306613something else
As the output...
so "size" is set... right?
Right.
A quicker way to "figure out" the correct minus number to use would be this...

str_cpy((checkFileText.pstring)[0], "pos-16=");
str_cat((checkFileText.pstring)[0],_str(pImage[size-16]));
str_cat((checkFileText.pstring)[0], " pos-17=");
str_cat((checkFileText.pstring)[0],_str(pImage[size-17]));
str_cat((checkFileText.pstring)[0], " pos-18=");
str_cat((checkFileText.pstring)[0],_str(pImage[size-18]));
str_cat((checkFileText.pstring)[0], " pos-19=");
str_cat((checkFileText.pstring)[0],_str(pImage[size-19]));
str_cat((checkFileText.pstring)[0], " pos-20=");
str_cat((checkFileText.pstring)[0],_str(pImage[size-20]));

And see which one shows the whole sub-string...


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: detecting wrong file types [Re: EvilSOB] #290991
09/22/09 19:02
09/22/09 19:02
Joined: Jun 2006
Posts: 2,640
Earth
Germanunkol Offline OP
Expert
Germanunkol  Offline OP
Expert

Joined: Jun 2006
Posts: 2,640
Earth
It was size-18. Great!! It's working now:
Code:
if(str_stri(_str(pImage[size-18]), "TRUEVISION-XFILE."))
	{
		//its a TGA
		beep();
	}
	else
	{  
		
		//its NOT a TGA
	}



How secure is this? Can someone change his .exe file to contain this string?

Also, what I still don't understand:
I see how _str() reads everything starting at that element of the array (the manual only mentiones the _str("hi there") version, how was I supposed to know? Stupid manual. maybe I just misread as well...), but I don't see why, if I str_cpy(..., _str(pImage[size-145]); or using any higher number than 18 will only return an empty string?

thank you very much for your clear answers!!


~"I never let school interfere with my education"~
-Mark Twain
Re: detecting wrong file types [Re: Germanunkol] #291035
09/23/09 05:31
09/23/09 05:31
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Its working, excellent.

Q1> How secure is it?.... How secure is anything?
Nothing is ever truly secure, there are only "strengths" to a security system. Its not impossible that
an exe that is 'designed' to have "dead space" on the end that could contain the TGA marker string,
but how likely is it? I think quite unlikely. But is that enough for you? Thats up to you...

Q2> The manual doesnt go into this sort of depth with its descriptions of the _str() function, because this
is really advanced string handling, and is IMHO a bit beyond the scope of the manual.
The manual is there to teach you lite-c, not advanced C++ programming.

Q3> The reason the str_cpy fails if you go too far minus, I would say, is this.
Remember that _str() creates a temporary string from the chosen character to the next NULL character.
So if a large part of the tail-end of the TGA (except for our search-string) is full of NULLs,
chances are we will end up up with an empty temporary string.
AND, if the last byte BEFORE our search-string is a NULL (which may be STANDARD) then if we start
our string before [size-18] then the temporary string WILL end BEFORE the string we want.

Does that help?


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: detecting wrong file types [Re: EvilSOB] #291045
09/23/09 06:28
09/23/09 06:28
Joined: Jun 2006
Posts: 2,640
Earth
Germanunkol Offline OP
Expert
Germanunkol  Offline OP
Expert

Joined: Jun 2006
Posts: 2,640
Earth
I think it would be enough if the manual said "there's more to _str, see "_str" in any c++ manual"... but that's just my opinion.

And I thought the same about question 3, it was just weird that I could try so many different numbers, and all of them returned an empty string; there must be lots of NULLs in Tgas...

Yes, all of that helps, thank you, again, very much.


~"I never let school interfere with my education"~
-Mark Twain
Re: detecting wrong file types [Re: Germanunkol] #291073
09/23/09 10:53
09/23/09 10:53
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
No problems. Anytime.

And if you really would like the manual to mention
"... there is more detailled information on XXX, see a C++ reference manual..."
then just imagine there is one at the bottom of EVERY page of the manual.

Because there is so much more that the manual COULD contain, but doesnt,
bacause it is advanced stuff, and beyond the manuals limitations as a USER manual.

As for all he space at the end of the TGA file...
HERE is a link that may help, if its not too technical for you.
Look 3/4 of the way down for the "File Footer" section.
I now long know if tis test for TRUEVISION is correct, that may only be TGA version 2.0 files....
REALLY old TGA files may fail...


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Page 2 of 2 1 2

Moderated by  HeelX, Lukas, rayp, Rei_Ayanami, Superku, Tobias, TWO, VeT 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1