HomeForumsWhat's newResources 
 
 
Need some more help with CompSec HW
slinga - Oct 24, 2003
  slinga Oct 24, 2003
Hey guys,

I'm working on a File Encryption and Authentication Utility for my computer security class. I have a struct defined which holds the user's name, and a hash of their password. I decrypt the file containing this information to memory. I then create a pointer pointing to this location in memory, and of course it doesn't work. Things aren't lined up like I hoped they would be, ie fields just keep going until they reach their limit.

Is there a quick way to take this data in memory and create an array? If not it's going to be a pain to parse this...thanks in advance.

 antime Oct 25, 2003
In C, pointers and arrays are pretty much interchangeable. An array is a pointer to the first member of the array, subscribing the array is taking the address of the first element and adding n*sizeof(element) to it. Now I didn't quite understand the nature of your problem from your message (and you present no code), but if you're trying to parse structures by hand from just a bare pointer, don't do it. The structure may contain padding to align the elements and the layout will vary from compiler to compiler (not to mention CPU architectures). Instead, cast your pointer to a pointer-to-struct and then use the -> syntax to access each member.

 slinga Oct 25, 2003
Thanks for your quick response, let me try to clarify my problem.

I have a struct defined as:

Code: 
  
struct FEAU_User{

  char login[33];

  char hashedPassword[33];

};

I have a text file containing user information in the following way:


  
	
	

		
		

			User1 hashedpass1



User2 hashedpass2



User3 hashedpass3



...


When I use fscanf on the users file everything works fine. The problem is I want to encrypt the users file, and decrypt it to memory when I launch my program. There should be no unencrypted file on the hard disk. I've been able to decrypt to memory, and now I have a region in memory looking like this:


  
	
	

		
		

			"User hashedpas1 User2 hashedpass2 User3 hashedPass3..."


I then tried to create a FEAU_User* pointer to that memory address, but it didn't work, and I sort of understand why.

Now my problem is either parsing that memory region (which I haven't figured out how to do yet either) or, is there some sort of function of library call I can make that will correctly format that region in memory to be of type FEAU_User?

 antime Oct 25, 2003
One obvious problem is that the login may be less than 32 chars, so accessing the strings in memory as if they were stored in FEAU_User structs will cause problems. Also, remember that strings are delimited by null bytes, so even if you point to "User2", using the common str*-functions will happily process all of your buffer.

Now, there are several solutions to your problem. One would be to read the strings one at a time into the members of FEAU_User structs. Another would be to keep reading everything into a single string buffer and go through the string buffer with something like strtok, storing the addresses of the strings in the struct instead. Change the struct to something like

Code: 
  
typedef struct {

char *login;

char *hashedPassword;

} FEAU_User;
if you decide to go down that route. Parsing the string (with strtok or one of the other str* functions) and the copying the resulting strings into your struct type is yet another way.

 Mask of Destiny Oct 25, 2003
One problem with strtok is that its not thread-safe. I'd just make a simple function to do it. You could use a while loop to copy the characters from the string in memory to the string defined in the struct with the exit condition being the current character is equal to the delimiter (or if you've exceeded the bounds of the array, we don't want any naughty buffer overflows now do we?).

 antime Oct 25, 2003
The function not being thread-safe is only a problem if you're actually writing a multi-threaded program (also, it's an implementation issue. POSIX says the function doesn't have to be thread-safe, but eg. Microsoft's implementation is). If you want to be extra careful, nothing prevents you from rolling your own version, for instance using strpbrk and manually setting the nulls in the right places.