exfat_header->signature Topic is solved

Using TestDisk to undelete files
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Locked
Message
Author
mesajflaviu
Posts: 37
Joined: 12 Sep 2019, 19:54

exfat_header->signature

#1 Post by mesajflaviu »

Wanting to understand this code, I met something interesting:

Code: Select all

int search_exFAT_backup(unsigned char* buffer, disk_t* disk, partition_t* partition)
{
	if (disk->pread(disk, buffer, DEFAULT_SECTOR_SIZE, partition->part_offset) != DEFAULT_SECTOR_SIZE)
		return -1;
	{
		const struct exfat_super_block* exfat_header = (const struct exfat_super_block *)buffer;
		/* EXFAT recovery using backup sector */
		int a = exfat_header->signature;
		int b = le16(exfat_header->signature);
		int c = 0xAA55;
		int d = le16(exfat_header->signature) == 0xAA55;
// the condition from below is never TRUE at all ... why exfat_header->signature is swaping byte ? (lower/high byte) ?
		if (le16(exfat_header->signature) == 0xAA55 &&
			recover_exFAT(disk, exfat_header, partition) == 0)
		{
			/* part_offset has already been updated if found using backup sector */
			return 1;
		}
	}
	return 0;
}
Result:

Code: Select all

a = 43605; (in hexa: 0xAA55)
b = 21930; (in hexa: 0x55AA)
c = 43605;
d = 0;
of course, the condition from below is not TRUE:

Code: Select all

if (le16(exfat_header->signature) == 0xAA55)
why is swaping exfat_header->signature lower byte with high byte ?

Thank you for any explaination !
Last edited by mesajflaviu on 24 Sep 2019, 07:11, edited 1 time in total.

recuperation
Posts: 2720
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: exfat_header->signature

#2 Post by recuperation »

Hello,

just an idea (I am not able to program in C and did not look at the rest of the code):

The software runs on different platforms where the byte order may differ. See:
https://en.wikipedia.org/wiki/Endianness

mesajflaviu
Posts: 37
Joined: 12 Sep 2019, 19:54

Re: exfat_header->signature

#3 Post by mesajflaviu »

Hello. Yes, I think that could be the reason why that value is swapped ... but I wonder whether is ok to modify that condition in order to made that condition TRUE ?

recuperation
Posts: 2720
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: exfat_header->signature

#4 Post by recuperation »

As I said above:

It is the processor platform that should make that condition become true - I guess.
Last edited by recuperation on 24 Sep 2019, 17:27, edited 1 time in total.

mesajflaviu
Posts: 37
Joined: 12 Sep 2019, 19:54

Re: exfat_header->signature

#5 Post by mesajflaviu »

@recuperation: I owe you. Thank you. I'll try to write to Grenier this part of code, when I modified by my hunch, seem to work that part of code, but I am thinking where these situation could come up later ?

recuperation
Posts: 2720
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: exfat_header->signature

#6 Post by recuperation »

recuperation wrote: 24 Sep 2019, 10:34 As I said above:

It is the processor platform that should make that condition become true - I guess.

User avatar
cgrenier
Site Admin
Posts: 5432
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: exfat_header->signature

#7 Post by cgrenier »

On a little endian plateform (ie. Intel), le16() is defined as

Code: Select all

#define le16(x)  (x)
It has no effect.

mesajflaviu
Posts: 37
Joined: 12 Sep 2019, 19:54

Re: exfat_header->signature

#8 Post by mesajflaviu »

Thank you, I have understood.

Locked