Lil help on understanding the concept behind the filesystem

That’s how I prefer things as well. :)

Feel free to message me.

lol I love your way of tackling things, I wish you all the luck.. I’m sure you’ll be able to do this one.

Well you can use a method to extract data from the img file.

[quote=tl0tr]Well you can use a method to extract data from the img file.[/quote]
mind blown

Well I don’t want to give a way the method to extract the data from the img file and shouldn’t it be mind blowing ??

Why don’t using tool first then do it manually ? Do what you have to do with the tool then look at the tool source code if there is one

You could manually recover each individual file with something as simple as a hex editor, if you want to make it harder on yourself.

I have used a tool to extract them already. The tool work. as i presume, it scan for data block and extract them.

What I would like to do, is what Rex_mundi suggested but also extracting their proper filename. The main issue I currently have, is i cant seem to visualize how to transpose the filesystem concept on the img file and figure out how to pick the correct hex data from the img file.

I know this is not the the main challenge of this level, but its a good situation to push my limit with this level.

I think I’m starting to get it…

before 0x0400 its the padding of 1024 byte for mostly boot sector
at 0x0400 the inode count which seems to suggest there is 25 files
at 0x0404 it suggest the files are spreaded in 100 blocks of data
etc […]
Super block information is from 0x400 to 0x7ff.

Correct me If i’m wrong so far.

Anyway; Il start with that and try to figure out how to get the information on the inode to get the correct files and data location spreaded within the img file!

I’ll drop you a PM man.

Lil update;
After playing alot in the img file, I made; from my point of view, lots of progress figuring how to point exactly where that data is… Still not there, yet closer.

staying in the story context of the challenge :P
I found 6 super block ; block 1, 8193, 16388, 16394, 16428 and 24577
where 3 are correctly placed: 1, 8193, 24577 having respectivly their block group 0, 1 and 3

All of these superblock contain different itation of the Superblock 1;
1 is very similar to 16388 and 16394
8193 is indentical to 24577
and 16428 is quite a loner

I dont get yet how the missing superblock of group block 2(since its not at 16385; yet it should be, right?) affect the overall filesystem…
Also all of the superblock seems to have half of their data erased; from x57A to x7ff overwritten with 0 unless its normal they have no information.

The earliest time the file system was created; was 21 Sep 2014 20:08:16 GMT
last mount time from earliest super block: 21 Sep 2014 20:08:30 GMT same as written time
Most recent mount: Mon, 22 Sep 2014 18:06:13 GMT
and write: Mon, 22 Sep 2014 18:06:39 GMT

All Super blocks indicate 3 different values for free blocks and inodes:
Blocks: 23462, 23450 and 10416
inode: 6390. 6389 and 6372

Seeing HOW much data there is in those ~25k block (non-zero);
Super block 16388 make more sense stating there should be 10416 blocks free.
Also tried swapping the superblock 1 with Superblock 16388 in case it was wrong; it didint changed anything except tools seeing the free inode and blocks value from the new super block.
So I presume the Inode table must be affected or Data got moved around which doesnt mach the inode table registration.

Various fact I found:
- Incompatibility feature is slightly different between these two(1 and 16388); adding 0x4 to superblock 16388.
- Along with 3 different mount path trought all super blocks; 1 is empty.. either on purpose or was the first superblock creation.
- Half of the Super block state it has written 26927kb over their lifetime, while the other half state 1212kb
- block per group is set to 8192, cluster per group is also set to 8192. The odd thing is, the block size is set to 1024 byte, while the cluster size is set to 1byte; is it common the size is set differently?

So far I understand the superblock and group descriptor position in the block list along with their size. But Yet I have to figure out to get the exact position of the inode and block bitmap location to get closer. They state a Hi and Lo 32 bit value. Do I Sum them like this?:
+10100101

10100101

111101111

So I presume:
The Superblock Might be broken, more information from the inode table should help me point out the most matching superblock. And from there figure out how much data there is supposed to on the drive.

My aim? Still to get those files manually, but I want to understand why the file system doesn’t work anymore and repair if possible; and if I cant repair it, why. It might be impossible but hell I’m learning with this, along with all the mind puzzling stuff that I’m trying to understand by my self.

Repairing the file system should be a challenge by itself… xD

On a side note, I’m still trying to find a way to crack that rar file. From the wav file name I know where to look after lol.
Looking at the rar file mechanic, I understand:
- i cant get the file directly via hex extracting, its encrypted in 128-bit aes; well i could get it, but it would be encrypted
- that leave 2 possible way to find the password, its either written somewhere on the img since these code should be given to someone; so giving the jump drive along with the code hidden somewhere would make sense, or brute force this. From what I understand a password over 5 digits could take more than a week to brute force for that kind of encryption.
[/spoiler]

Later on I found a linux command to give me most of that info I extracted manually from the img file….
[spoiler]
Thank you dumpe2fs

Hhahah Still I’m having lots of Fun from this!

Thanks for reading and helping! :)