Hi,
Thanks for reporting this issue.

It seems like I haven't handled the case where the function that parses the first record of the $MFT returns an empty list.
I never encounter this bug when testing on my VMs, so I don't know to reproduce the bug.

Could you tell me a bit more about your VM specification ? Do you have Bitlocker activated ? Because that's a scenario I've never tested.

EDIT: By reading my code again I found out that the only scenario where get_data_runs returns an empty list is if, the first fragment of the $MFT file record, in the $DATA attribute, contains an unexpected size. For now, I handle 0x31, 0x32, 0x33 and 0x42.

Alright I did bit more research about parsing the MFT data runs and I figured how to handle every data run size.

Instead of trying to manually handle every possible sizes without even know to it means, I'll implement it this way :

I have other priorities to work on but I will fix this as soon as I can.

I saw that your code always assumes that 1 cluster is 8 sectors but this might not be the case everywhere as NotPetya kernel reads SectorsPerCluster field from NTFS Boot Sector and uses it to calculate MFT Starting Position.
Also I don't have Bitlocker activated and my VM Specification is Windows 8.1 x64 UEFI on VMware.
By the way when NotPetya MBR kernel encrypts MFT it also saves counter of encrypted MFT file records in sector 35 so it knows how much to decrypt if victim aborts the CHKDSK.

Also I think this might be helpful for you: https://shasaurabh.blogspot.com/2017/07/technical-analysis-notpetypetya-mbr.html
This is analysis of NotPetya 16 bit kernel about how it calculates MFTStartingPosition and how it calculates how much of MFT sectors to encrypt.

I saw that your code always assumes that 1 cluster is 8 sectors but this might not be the case everywhere as NotPetya kernel reads SectorsPerCluster field from NTFS Boot Sector and uses it to calculate MFT Starting Position.

You're right, I'm aware that the size of cluster isn't of 8 sectors but I coded it that way because I wanted to do it fast.
Thanks for reminding me that I have to fix this too.

By the way when NotPetya MBR kernel encrypts MFT it also saves counter of encrypted MFT file records in sector 35 so it knows how much to decrypt if victim aborts the CHKDSK.

That's cool feature I didn't know about, I may implement that later but it's gonna be to much trouble for me to do it before the deliverable of my school project.

Also I think this might be helpful for you: shasaurabh.blogspot.com/2017/07/technical-analysis-notpetypetya-mbr.html This is analysis of NotPetya 16 bit kernel about how it calculates MFTStartingPosition and how it calculates how much of MFT sectors to encrypt.

What a shame I didn't encounter that article before, It's a gold mine of information. Thanks again !

Could you make your UEFI bootloader encrypt the MFT the same way that NotPetya does and display number of MFT sectors during encryption?

display number of MFT sectors during encryption?

I can myself adding that feature without too much trouble.
I still have some school work going on, I may be working on this next week.

@sven-eliasen NotPetya determines the total number of MFT Sectors by reading the first MFT Record which belongs to $MFT itself and from this record with 0x80 attribute determines the total number of sectors to be encrypted and the absolute sector from which to start and skips the first 32 MFT sectors.

@sven-eliasen NotPetya determines the total number of MFT Sectors by reading the first MFT Record which belongs to $MFT itself and from this record with 0x80 attribute determines the total number of sectors to be encrypted and the absolute sector from which to start and skips the first 32 MFT sectors.

Didn't know about that, what's the benefits of skipping the first 32 MFT sectors ?
I know the first 16 MFT records belongs to NTFS special system files.

If that's about encryption time it's pretty worthless.

It seems that the first 32 MFT Sectors store information about system files and when you said the first 16 MFT records, because one MFT Record is 1024 bytes(2 sectors) and one sector is 512 bytes 32 / 2 = 16 MFT Records , and notpetya kernel skips it, while Red Petya kernel encrypts full MFT but skips first 2 MFT sectors, also how does your ransomware knows if entered key is correct or not?

Also how can I contact you if possible?

@sven-eliasen I have tried your improved ntfs.rs on my VM and it shows this: https://imgur.com/a/gFrSRQX

@sven-eliasen I have tried your improved ntfs.rs on my VM and it shows this: imgur.com/a/gFrSRQX

I didn't have time to test it, I just pushed the branch to save it.
I'll will let you know when I'm sure it's working.

Also how can I contact you if possible?

You can find my email address on my Github profile where I'll be pleased to answer your questions.

@sven-eliasen Thanks, also btw could you tell me how does your NotPetyaAgain knows if the key entered by the user is correct or not?

@sven-eliasen Thanks, also btw could you tell me how does your NotPetyaAgain knows if the key entered by the user is correct or not?

After the key generation process, the program writes in the EFI variable "NotPetyaAgainProof" a static string encrypted with the newly generated key.

In the ransom note prompt, the input is taken as a key and is decrypting what's inside the EFI variable, if the result is not equal to the static string than it's not the right key.

In the code, the static string is "slava ukraini " but it could be anything.

@sven-eliasen okay thanks, btw did you know that original Petya 2016 used secp192k1 curve?

Hi,

So I tried to work back on this yesterday but I went into to much trouble. And frankly I forgot I much it was a pain in the a** to debug a UEFI bootloader.

I tried to fix this in the other branch but there seems to be a problem getting the right ranges of the $MFT.

I don't want to put any more efforts and I'm closing this issue as well as I'm archiving this repos because I won't work on this project anymore.