Writeup for Greasepaint - VolgaCTF 2024 Quals Task

The contestants are given an image of an HDD with bad sectors. The bad sectors cause some of ext4 clusters to be marked as bad, while not all the sectors within each bad cluster are actually bad.

These pseudo-bad sectors are used to hide data.

The solution is fairly straightforward:

The data extraction can be done using extract.py:

We’re given an archive greasepaint.zip which contains three files: image.dd, image.log, and image.sha256deep.

The content of image.log tells us that for some reason dd was used instead of a more suitable software (e.g. dcfldd). This might be significant.

In image.log we see a number of I/O errors:

Probably, there were some bad blocks on the HDD, so dd with iflag=direct was used.

Mapping the image we see GPT and two partitions: ESP and a Linux partition with ext4 file system

We won’t discuss all the possible routes this investigation could have led us along, and will only briefly mention those leading to interesting findings.

Examining the FS metadata we find that it lists several bad clusters:

So the HDD indeed had bad sectors, which, apparently, were taken into account during the FS creation.

We also see that FS block (cluster) size is 4096, while there were

2097152 blocks of data written to image.dd. The size of image.dd is 1073741824 bytes, so we can assume that the sector size of the HDD was 1073741824 / 2097152 = 512 bytes.

Since a file system allocates disk space in clusters, any bad sector that falls within a cluster turns this cluster into a bad FS block.

However, in our case an FS cluster contains 8 disk sectors, and it is marked bad if at least one of these sectors is bad, while the others might still be operational.

This can be visualized as follows:

Therefore, within any bad FS cluster there may be up to 7 good disk sectors. These good sectors are ignored by the file system, hence FS operations won’t overwrite data stored there. Let’s call these sectors "pseudo-bad".

The bad sectors can be found by analyzing the error messages in image.log:

Numbers that are followed by +0 records out are precisely the bad clusters of the HDD.

We see that dd failed to read sectors 2066994, 2067607 (and many more not shown above). To keep the offsets dd most certainly was called with conv=noerror,sync, thus these sectors must be all zeros - let’s check:

Also note that, as we saw earlier, the FS starts at sector 329728, while the first bad sector number is 2066994, which means all the bad sectors fall within the FS partition.

Parsing image.log we get a list of the bad HDD sectors. A list of the bad FS clusters can be saved using dumpe2fs with -b switch:

To recap, so far we’ve found that:

Identifying the sectors that make up a particular FS cluster is easy. FS clusters are numbered from the beginning of the partition (sector number 329728), let’s call it partition_start. Then the sector numbers are given by this expression:

For example, recall that the first bad cluster number is 217158 and the first bad sector number is 2066994. The first of these 8 sectors is sector number 2066992 = 329728 + 217158 * 8, and the cluster is made up of sectors 2066992 through 2066999.

Let’s examine these 8 sectors:

We see that all the pseudo-bad sectors store the same data. Repeating this for other FS clusters will give similar results (omitted here for brevity).

It appears that the data being hidden is split into 512-byte blocks, each stored in every pseudo-bad sector of respective bad FS cluster.

That data duplication kind of makes sense, since the pseudo-bad clusters are close to the actually bad once, therefore, with high probability may turn bad as well.

Finally, let’s extract the hidden data.

Essentially, we need to do the following:

That’s implemented in extract.py.

Extracting the data we see that it appears to be just a binary data:

However, if we examine it closely, we notice that is starts with bytes 387a bcaf:

which is 7z magic number ('7', 'z', 0xBC, 0xAF, 0x27, 0x1C), except the first byte. Possibly, it was changed to hide the archive from signature-based searching.

Rewriting the first byte we check that the extracted file is indeed a 7z archive:

Trying to open we see it’s also password-protected, so one more dictionary-based attack gives the password: jarvis.

Now we can extract flag.png from the archive and get the flag: VolgaCTF{S0me_bad_b1ocks_ar3_not_th@t_bad}.