cgsecurity.org

26.10.2025 12:32 MEZ recuperation: changed title of thread

I have erroneously resized a partition and want to find out the original size, exactly the number of the first and last sector of the original partition. I know that Testdisk can report these numbers for established partitions, but can it also find out the last sector for the original partition size?

wuezwuez wrote: 19 Oct 2025, 13:41 I have erroneously resized a partition and want to find out the original size, exactly the number of the first and last sector of the original partition. I know that Testdisk can report these numbers for established partitions, but can it also find out the last sector for the original partition size?

TestDisk finds partitions that may have been lost and lists them for you. This list can as well include false positives. You will have to check each partition proposal. For partitions that come with a file system TestDisk understands you have the function "list files".

Resize operations are a different issue.
As you can resize a partition in a way that erases all evidence of an older partition there is no general answer to your question.
Furthermore, your implied statement "but can it also find out the last sector for the original partition size?" is wrong as the word "also" implies that the first sector of the partition of the partition can always be found. That is not the case.

Thank you for your answer.

I have a working Windows system partition C: and a lost data partition D:, so I thought that startsector of D: = last sector of C: plus one, and I only have to find out the last sector of the previous size of D:
I expected that resizing partition D to a higher size does not destroy any data except overwrite those in the partition table.
Recognizing files will not help me because I encypted D: using VeraCrypt, so there are no files in partition D: to find.

So my next question is:
Can TestDisk help me at all finding the (previous) number of first and last sector (of this lost/resizied partition)?

No.

By the way, "I resized my partition" is not what matches the forum rule " Include as many details as you can" (see red writings above).

> By the way, "I resized my partition" is not what matches the forum rule " Include as many details as you can" (see red writings above).

Thanks for your answer, but there are no more details, resizing means changing the size only, and as long as not otherwise stated executed by Windows' built in partition manager, and the size amount should affect partition table entry only.

The original size was 200 GB and it was resized to 300 GB.

wuezwuez wrote: 23 Oct 2025, 14:58 > By the way, "I resized my partition" is not what matches the forum rule " Include as many details as you can" (see red writings above).

Thanks for your answer, but there are no more details, resizing means changing the size only, and as long as not otherwise stated executed by Windows' built in partition manager, and the size amount should affect partition table entry only.

If you use a partition as a container for Truecrypt/Veracrypt, both Truecrypt and Veracrypt use the information in the partition table to determine where to look for the so-called header and backup header. Depending on the various possibilities in resizing that you do not consider you either make one or both headers unusable by loosing their location.

And all this happens without any change within the encrypted partition.

Thank you for answering, but I don't know which details I could provide additionally.

The D: partition was resized using built in Windows 8.1 disk manager which accepted new size of 300 GB, as far as I know interpretedas GiB, and this software does not return neither created partition size in kb or byte exactly nor does it create the exactly size for 300 GB or even GiB. So all info I have is the original reported size of 200 GB temporarily receiced to 300 GB. Of course I tried to resize to 200 GB.

ChatGPT stated that an encrypted VC partition would have its header on the first partition's sector and an identical backup header on the last one, but for several reasons I cannot believe this because an exactly copy of the first sector marking the last one would work against the goal of encrypting, but I might be wrong.

As I don't know the size of such a VC header I could not try to copy a possibly unchanged backup header (or its sector(s)) onto top of the partition. There were a lot of leading bytes identical in both sectors, but not the complete sector. Fortheron, I found multiple sectors beginning with the same byte sequence as the first sector, the fist three(?) ones beginning exactly at byte 0 of a sector and behind them some more beginning with an offset of some bytes. This might come from earlier playing around with creating additionally partitions E: and F: behind the data partition D:.

Further on I suppose resizing a partition is only changing the disk's partition table. A resizer might fill up the expanded area with nulls, but why should it do so? Does Microsofts disk manager do so? And making a partition smaller may also overwrite the lost part with nulls, but why should it do so? Both actions would take a considerable amount of time on a magnetic hard disk which it doesn't.

Therefore, with my poor knowledge, I see no reason why any data should be overwritten in the partition's area. Correct me, if I am wrong, and I can erase my disk finally.

wuezwuez wrote: 25 Oct 2025, 08:40 Thank you for answering, but I don't know which details I could provide additionally.

The D: partition was resized using built in Windows 8.1

Different Windows version behave differently when partitioning. Naming the windows version is part of providing the bare minimum of information of a case. Thank you!

disk manager which accepted new size of 300 GB, as far as I know interpretedas GiB, and this software does not return neither created partition size in kb or byte exactly nor does it create the exactly size for 300 GB or even GiB. So all info I have is the original reported size of 200 GB temporarily receiced to 300 GB. Of course I tried to resize to 200 GB.

You are lacking a bit of fantasy. When resizing your partition you could have shifted its first sector to the left, using up free space in front of your partition. Doing this you are loosing the position of your first header unless your partitioning tool would as well move the content of the raw looking partition by the amount of extended sectors to the left.

If you extend the size of partition to the right, into free space behind your affected partition, Truecrypt/Veracrypt would try read the header from within the free space that has become part of your partition. Truecrypt/Veracrypt would not recognize the sectors from the free space as header and what's even worse would not find a valid decryption key.

To mount a container, the information of one header only is sufficient.

ChatGPT stated that an encrypted VC partition would have its header on the first partition's sector and an identical backup header on the last one, but for several reasons I cannot believe this because an exactly copy of the first sector marking the last one would work against the goal of encrypting, but I might be wrong.

Asking a large language model like ChatGPT for facts is useless. Your doubt based upon your reasoning is absolutely correct!

As I don't know the size of such a VC header

There are three types of information
1. primary information (from the source)
2. secondary information (from a human commenting on a primary source)
3. AI garbage

Always try to use type 1 information. Want to learn about NTFS? Type 1 isn't available for NTFS so type 2 is your best bet. Want to learn about exFat? Use type 1 as Microsoft disclosed its specification.
How about reading type 1 information about Veracrypt instead?

I could not try to copy a possibly unchanged backup header (or its sector(s)) onto top of the partition.

"onto top of the partition" is not a specific location.

There were a lot of leading bytes identical in both sectors,

I don't know what "both sectors" are.

but not the complete sector.

Incomprehensible.

Fortheron, I found multiple sectors beginning with the same byte sequence as the first sector, the fist three(?) ones beginning exactly at byte 0 of a sector and behind them some more beginning with an offset of some bytes. This might come from earlier playing around with creating additionally partitions E: and F: behind the data partition D:.

Further on I suppose resizing a partition is only changing the disk's partition table. A resizer might fill up the expanded area with nulls, but why should it do so? Does Microsofts disk manager do so?

I don't know. Furthermore that is not written in stone, anyway.

And making a partition smaller may also overwrite the lost part with nulls, but why should it do so? Both actions would take a considerable amount of time on a magnetic hard disk which it doesn't.

Therefore, with my poor knowledge, I see no reason why any data should be overwritten in the partition's area. Correct me, if I am wrong, and I can erase my disk finally.

Did you read my last answer?
I explained to you why you can loose access to your encrypted partition without even changing it!

Do not use partition managing software with encrypted Truecrypt/Veracrypt partitions. Instead duplicate the encrypted partition into a file or duplicate its content somewhere.
Then rebuild the affected partition according your needs. Create the partition container and copy your data into it using either the unencrypted duplicates or the content from the duplicated file container.

There is a free software called "testcrypt" which might help you. You have a logical recovery issue which can be solved by knowledgable users. But based upon the communication above, I would rather recommend you to consult a professional recovery lab. They would need your key to your partition container, though!