Decoders for 7ev3n ransomware

7ev3n is yet another ransomware about which I wrote some time ago (for Malwarebytes – you can read more here). It uses custom cryptography and I managed to decrypt several variants.  In this thread you can find my decryptors (and all the updates about them).

WARNING: 7ev3n ransomware has many variants. Check your ransom note and compare with the examples given below, in order to find what is your variant. Then, download appropriate decryptor. In case of any problems, feel free to contact me.

[Python scripts – PoCs]
[sourcecode of GUI versions – assembler]

A. For sample: 52517f419e78041f8e211428b8820dfb


GUI version: [download executable]
Python version:

This variant comes with NO ransom note.

In order to use this decryptor need to know the original path, where the file was stored when it got attacked by the 7ev3n ransomware. Example:


B. For sample: 08a53eb5d54c6829cf6ea29bd61ea161


GUI version: [download executable]
Python version:

In order  to use this decryptor you need to copy your unique ID from the ransom note – FILES_BACK.txt

Ransom note example:

hello, If you have Standart locker interface (green window) on desktop for decryption follow the instructions.
If you delete it, and want to decrypt your files you need decryptor, you can buy it by contact through email
contact email :
reserve email :
your unique id : 73118178525283953643921210931031
6. If you want try to decrypt your files with software from anti-malware websites please make copies of this files
 once you understand that it's not working, you will still have clear copies of the files that be decrypted after payment

And paste it in the appropriate place in the GUI:


youtube-512  see it in action:

C. For samples: 7e6af09baf19bc03c4a3b9078546a7c1, 5cce8bbe88dd6e95b8a89dd78a6b082e

This variant requires knowing the original path AND the Unique ID.

Ransom note example (FILES_BACK.txt):

hello, if standart cryptolocker interface was blocked or deleted by Antivirus or Firewall
and you want back your files, contact :
your unique id : 49b517551928275244272ca5da1f


GUI version: [download executable]
Python version:


youtube-512  see it in action:

Posted in Malware, Malware Decryptor | Tagged , , | 21 Comments

Anti-Petya live CD (the fastest Stage1 key decoder)

newUPDATE: 17-th July a new version of Petya has been released. At the moment, there is no way to decrypt the disk. Don’t let the infection reach the Stage 2!

Please read first Petya key decoder for more background information.

If you opened some executable downloaded from the Internet and your system crashed, it can be attack of PETYA RANSOMWARE.

Please do not let the system reboot from the hard disk! I will cause infection to progress.

Run your computer from a live CD (i.e. Kali linux)  and make a backup of the full disk. Example:

dd if=/dev/sda of=dump.bin bs=512

If you caught Petya at Stage 1 your files are still untouched and there is a chance to save them.

Petya detector in form of a bootloader:

With the help of this small tool you can easily check if Petya has been detected on your disk. In case of Petya versions 1 and 2 it can also recover the Stage 1 key.

ISO: antipetya.iso
BIN: antipetya.bin

Source code :

In order to use it,  just (from a different computer) download the antipetya.iso, burn on a CD and boot your machine from the CD.

Alternatively, instead of CD you can use a flash disk. In this case you need to dump antipetya.bin on to your disk. Example (using Linux):
1. Log in as root.
2. Check how your flash disk is represented in the system.
If the flash disk is /dev/sdb:

dd if=antipetya.bin of=/dev/sdb bs=512 count=1

The tool will give you a quick info, whether your bootloader has been substituted by the bootloader of Petya.
In case of versions 1 and 2 of Petya -it will give you the Stage 1 key automatically:

Output of Antpetya Live CD (Stage1):


Write down this key. This is the same key, that Petya uses to encrypt/decrypt your data:


If the Petya already erased the key, the bootloader will inform you about this fact. In case of the Red Petya, your disk still can be decrypted at the Stage 2 – you can read about it here: Stage2 decoder. Unfortunately, such recovery procedure does not work for the current Green version.

Posted in Malware, Malware Decryptor, Tools | 5 Comments

Petya key decoder

source code (Red Petya recovery)


[17 July 2016]new
A new (3-rd) version of Petya has been released – the current solutions no longer work. It looks exactly like the previous (green) Petya, but contains fixes in cryptography implementation and different Stage 1 keys. More info here.

[02 June 2016]
Procrash prepared a brutforcer for Green Petya key (using multi-threading and GPU for the high performance). Sourcecode available here: Cracking the key takes about 3 days.

[20 May 2016]
I found a weakness in Green Petya’s Salsa20 implementation (only 8 out of 16 characters of the key matters – read more here). I made a prototype decoder performing random attack on the key.

[ 14 May 2016 ]
I added support for the new (green) version of Petya to the antipetya live CD – again the key can be recovered from Stage 1 – unfortunately, there is no solution for Sage 2 so far.

[ 12 May 2016 ]
A new (green) version of Petya has been released – the current solutions no longer work.

[ 21 April 2016 ]
m0rb packaged my tools into antipetya_multi.iso – now recovering Stage 2 key is simpler and faster (no Kali Linux required). You can see it in action on the video.

[ 18 April 2016 ]
I made much faster way to recover the key from Stage 1. Read more:

[ 17 April 2016 ]
reimplemented leo-stone‘s idea in C++ and integrated with my code. (Thanks!) You can find new version here: petya_recovery (64 bit ELF) – I updated the tutorial to describe the new feature.

[ 8 April 2016 ]
Petya at Stage 2 has been cracked by leo-stone. Read more: and
. Congratulations to the author! I updated my decoder – now if if cannot give you the Stage1 key, it will give you the data necessary to supply to the Leo’s web application: [1] or [2]

[ 31 March 2016 ]
I made a decoder for key of Petya ransomware . It works for Stage 1 of encryption – if the system was not rebooted after the infection. Research about a possibility to decrypt Stage 2 is in progress.

My research is possible thanks to Malwarebytes.
Disclaimer: This tool is an experiment in unlocking a particular kind of Ransomware, neither Malwarebytes or Hasherezade promise this tool will help in your particular case. This tool should not be considered an official solution to the Petya problem. Any files destroyed, further encrypted or otherwise tampered with against the desire of the user are not the responsibility of the developers. Please use at your own risk.


WARNING: The Stage 2 decoder works only for the Red Petya!

You can download the decoder’s binary here (it is 64bit ELF). Sourcecode is available here.

Few tips

If you opened some executable downloaded from the Internet and your system crashed,
it can be attack of PETYA RANSOMWARE.

Best is if you don’t let the system reboot after the blue screen. However, even if you didn’t managed to catch Petya at proper time, still there is a chance to recover your data.

What to do:
1) From another computer download i.e. Kali Linux ISO 64 bit ( and record on a DVD
2) Boot the computer that crashed from this DVD, choose forensic mode.


3) Now your original hard disk should be mounted. Find it’s identificator, i.e using:

fdisk -l

Sample output:

Device     Boot Start     End Sectors  Size Id Type
/dev/sda1  *      [....]

it means your disk is sda
4) Download the decoder and make it executable (chmod +x decoder). Run it:

./decoder /dev/sda

It will tell you if known symptoms of Petya have been detected on your disk:

[+] Petya bootloader detected!
[+] Petya http address detected!
[+] Petya FOUND on the disk!

If you managed to catch Petya at Stage1, this decoder will give you a key directly:

Key: 8fb9GLT7qkQJ5hBu
[OK] Stage 1 key recovered!!

In other case, we need to recover from the Stage2. It may take up to few minutes. Wait till your key appears:

[+] Trying to decrypt... Please be patient...
ugxwErH4 89
hiSwhrau 77
ugdwErH4 74
hiSwhra4 69
ugdPErH4 67
hiSw1ra4 62
hgSPErH4 59
hiSw1raB 56
gAf31aib 51
hcfw1raB 48
hAf31aib 42
XqfJ115b 38
XPgK115b 37
Xac4115b 35
XaFF1A5e 32
AaFD1Q5B 28
xa8D1Q5B 26
xaM51Q5B 25
x4Gu1Q5B 24
xbGu1Q5F 22
xbG41Q1r 21
xbGt1QuB 18
8bGTqQ5B 0
[+] Key generation finished
[+] Validation passed
[+] YOUR KEY: 8xbxGxTxqxQx5xBx

5) Copy or write down the resulting key. It is very important for recovery!
6) Even if the decoder gave you a key, new Petya versions may come with some changes. That’s why, I cannot guarantee that this key will be valid for you!
I strongly recommend you to make a dump of full disk.
First mount an external disk of appropriate capacity and then dump there the full disk:

dd if=<path_to_infected_disk> of=<output_path>

example (dump an image of the infected disk into a file stored on external disk – in my case the external disk was mounted as kingston):

dd if=/dev/sda of=/media/root/kingston/disk_dump.bin

You can also clone one disk on another – read more here.

After that, you can reboot your system from the disk. If the Petya screen appear, supply the key that you got from the decoder:

After entering the key, Petya will inform you about the progress of decrypting your system. Wait for your system to decrypt.  It will inform you when you can reboot the computer. After that, your system should boot normally.

Posted in Malware, Malware Decryptor, Tools | 19 Comments

Introduction to ADS – Alternate Data Streams

Sometimes during automated malware analysis in a sandbox (i.e. Cuckoo), we can get in the report the following information: “creating alternate data streams”. It is related with an interesting feature of NTFS file system,  that can be used for hidden channels of storing and exchanging information.

Historical context

ADS are from an era when we had resource forks in HFS (Macintosh Hierarchical File System) and the idea was that files would “carry” everything with them, possibly even the application needed to open them, or the fonts needed to view them in many ways this was a beautiful design and idea which sadly never came to fruition. For example a text file could have carried its translations in ADS, a Braille version, RTF and TXT, etc. but also its images in various resolutions depending on screen DPI. All without cluttering the “main view” or those gigantic Word files. – via @cynicalsecurity


In FAT file system – used by old versions of windows – file consisted of 2 elements: attributes and data.

In NTFS it i different – file consists of attributes, security settings, main stream and alternate streams. By default, only the main stream is visible.

Let’s see how it works by creating a sample file: test.txt. At this moment it’s main stream will be empty. However, we will create an alternte data stream. We can write into it using echo command and simple stream redirection.
Naming convention:

optionally we can use ::$DATA at the end, i.e:

echo This message is saved in the ADS > testfile.txt:hidden_stream

echo This message is saved in the ADS > test.txt:hidden_stream

Let’s list the directory and see the newly created file (test.txt)



As we can notice, the file length is displayed as 0 bytes. If we try to open this file by some text editor (i.e notepad) we can see that it is empty. Does it really have something inside? Let’s confirm:

more < test.txt:hidden_stream

more < test.txt:hidden_stream

Now, finally, our text showed up.

So, how we will find out what are the alternate data streams available in particular files? There are several tools dedicated to reading and editing ADS, but if we don’t want to bother about it, we can just use a command dir, with an appropriate parameter:


dir /R – display alternate data streams of the file


Now we can see the same file, test.txt, listed twice: once with a size 0, and then again – with the size 35, with the ADS name added.

We can edit the file in a normal way, and the alternative stream will stay untouched. By the same way we can create several streams.


File in file using ADS

Example 1

We can also hide another file on the alternate data stream. On the below example – we create a new txt file on another. We can then edit it with typical tools:



Yet, opening the file by default way, we can only see it’s main stream:


Example 2

We can also paste an existing file on an alternate data stream, by using a command type

Let’s take as an example a demo.dll – it is a 32bit Portable Executable, exporting one function: Test1. We will place it in the alternate stream of test.txt

type demo.dll > test.txt:demo

type demo.dll > test.txt:demo

Maybe the alternate stream it is hard to notice – but running it is still very easy:


rundll32 test.txt:demo,Test1

Example 3
Exactly the same can be done with (malicious) macros:

type‬‬ ‫‪malware.vbs‬‬ > ‫‪readme.txt:malware.vbs‬‬
‫‪Wscript‬‬ ‫‪‫‪readme.txt:malware.vbs‬‬


One of the legitimate usages of alternate data streams is Zone.Identifier. It is a feature used to identify the file origin. In case if the file comes from some untrusted source, i.e. have been downloaded from the internet, Windows displays a security warning before it can be run.

There are several variants of Zone.Identifier value:

0 My Computer
1 Local Intranet Zone
2 Trusted sites Zone
3 Internet Zone
4 Restricted Sites Zone


Sample content of Zone.Identifier of the file downloaded from the internet:


Malware downloaders may edit Zone.Identifier of the downloaded file, in order to make it run without displaying alert.

ADS and PowerShell

PowerShell comes with a built-in feature to read ADS. There are several commands that can be used to read and edit them:

  • Get-Item
  • Set-Item
  • Remove-Item
  • Add-Content
  • Get-Content
  • Set-Content


Listing all the streams of a file:

Get-Item -Path [filename] -Stream *

Adding hidden message into ADS:

Add-Content -Path [filename] -Value [my hidden message] -Stream [new_stream]


Creating ADS from commandline:

‫‪echo This is a hidden message > testfile.txt:hidden_stream

Displaying files with their alternative data streams:

dir /r

Displaying stream of a file:

more < testfile.txt:hidden_stream::$DATA


Posted in Malware, Uncategorized | Leave a comment

DMA Unlocker

I managed to crack some of the variants of DMA Locker ransomware (version with RSA key), described [here].

For those who are hit by this version , there is an experimental decryptor for it. More details and updates you can find on the dedicated page: here

Posted in Malware, Malware Decryptor, Tools | Leave a comment

Solving KeygenMe V7 by MaxX0r – part 1

This KeygenMe I’ve got personally from the author (MaxX0r). Thank you for such a nice gift and congrats for a good job!

The difficulity level is 3 (according to
It doesn’t contain any advanced crypto, but is nicely obfuscated, self-modifying and containing some defensive features. Due to this properties, it have pretty high detection ratio on VirusTotal. But I ensure you, it is not a malware (just a false positive)! If you still have doubts, you can read thought the code (I will try to describe it clearly in my tutorial).


The KeygenME is a 32-bit PE file. You can download it here (also available on

KMv7_trialAuthor sets several achievement levels (see full list).


Here I would like to present my solution for GOLD, that is:

* create a working keygen
* remove the nag screen

KeyGen source:

+ the version with Nag removed:



Tutorial 1 – removing nag screen

Due to the fact, that I would like to make a detailed tutorial, that is easy to follow for beginners, I divided it in 2 parts. This one is dedicated to removing Nag screen. In the next part, I will describe keygenning. If you wish to see explanation of obfuscation techniques only, you can go directly to the end of the article.

First, I loaded the KeygenMe into ImmunityDebugger:


and searched for “All referenced text strings” (left mouse button click, then: Search for -> All referenced text strings)

It could possibly show as the place, where the “Success” message is displayed. But, no luck this time – no such thing is on the list. Taking a closer look, we notice, that neither the Nag message is present. For sure they are encrypted/obfuscated somehow!

By the way, I spotted some other interesting strings: ntdll.dll, wcsnmp, memset, wscsncpy, comctl32.dll, InitCommonControls, SeDebugPrivilege. It seems, the application loads some functions dynamically. We will not go in details right now, but lets keep it in mind.

Let’s first focus on finding the place, where the Nag and SuccessMsg are stored.

IDA graphs are going to be helpful, so I loaded the same file now to IDA.

Graph of start function have a weird shape, which suggest that some transitions between code chunks are obfuscated.

Also, there is some long piece of code on the stage, which seems to load some obfuscated string (WindowName). It moves a lot of bytes into consecutive variables (probably forming some buffer) . Then calls a function and performs some decoding with it’s help- I given to the called function a name _decode


The body of _decode function is simple. However, it also contain some obfuscation – by breaking standards of argument passing. Usually ECX register is used as a counter, ESI – as a source and EDI as destination. But not here, as you can see…


Let’s see Xrefs to this function – maybe it will help in finding Nag and SuccessMessage:


As we see it is called from 3 functions:

  • start – as we see above, it decodes WindowName
  • sub_401856
  • sub_402551

Let’s take a closer look at the 2 remaining calls.

sub_401856: Function _decode is called in several places. However it decodes some small (max 5-bytes long) chunks… But we are searching for the strings, so let’s skip it for now… (anyways this function looks interesting. It refers to function like GetDlgItemTextW – seems to be fetching user input and then processing it. Accidentally, we found the key verification function! So, from now I will refer sub_401856 as KeyVerification)


Let’s move on:

sub_402551: looks much more promising. It have two paths of execution, one of them is decoding some lengthy buffer (probably a string) + refer to MessageBoxW.


It is referred from the start  – so, seems to be the Nag rather than the SuccessMsg.


As we see, in this case the reference doesn’t mean a direct call. The address is pushed on the stack. After that, some other addresses are also pushed, and then there is RET. It is some complex version of calling via PUSH-to-RET. The function that is called from here is in reality sub_4013B0:


The function takes 2 parameters. It above case, one is the address 4029F6 and the other is the handle to CreateWindowExW.  The address of our interest: sub_402551(the potential Nag) is not among them. To see how it is called, we must first understand how the sub_4013B0 works.

Inside we see the heap allocation and changing access rights to allocated space. Seems, some code is going to be written.

Also, two functions are called by the handlers, that are dynamicaly filled somewhere else:

  • dword_40300C
  • dword_403000

Some dynamic analysis will be required (and I prefer doing it in ImmunityDebugger). So I loaded it in Immunity, set breakpoint at 4013B0 and run. The mysterious handlers got filled, and now we see that

  • dword_40300C -> ntdll.memcpy
  • dword_403000 -> ntdll.memset

Let’s see what they are used for. Here is dump of parameters:

|dest = 001F7268
|src = USER32.CreateWindowExW
\n = 5

|s = USER32.CreateWindowExW
|c = E9 -> JMP
\n = 1

|dest = USER32.7685EC7D
|src = 0012FEB0
\n = 4

|s = 001F726D
|c = E9 -> JMP
\n = 1

|dest = 001F726E
|src = 0012FEB0
\n = 4

Do you see the “code stealing”? First, 5 bytes from the beginning of CreateWindowExW is copied into allocated space. It is overwriten by the jump (E9 = opcode of JMP) to the address, stored on the stack (at 12FEB0). Then, another JMP is writen – this time into the allocated space. Let’s have a look how the CreateWindowExW looks after the modification:


Do you recognize the address of the jump? It’s sub_402551(the potential Nag)! So, finally we found how it is called – whenever CreateWindowExW is called, it jumps to our procedure first.

Let’s see what is written into the allocated space:

001F7268   8BFF             MOV EDI,EDI
001F726A   55               PUSH EBP
001F726B   8BEC             MOV EBP,ESP
001F726D   E9 0F7A6676      JMP USER32.7685EC81

It is the stolen prolog and redirection to the rest of the code of CreateWindowExW. Ok, now we know, that original CreateWindowExW can be now called by refering to the address 1F7268.

Coming back to the 4013B0 (from now I will refer is as: StealCode)

I also set the breakpoint on the return, and follow where the navigation goes next:

004029FC  MOV DWORD PTR DS:[403018],EAX
00402A01  PUSH KeygenMe.004017BE
00402A06  PUSH DWORD PTR DS:[<&USER32.CharUpperW>]
00402A0C  PUSH KeygenMe.00402A17
00402A11  PUSH KeygenMe.004013B0; StealCode
00402A16  RETN

Another “code stealing” is performed. Now the affected procedure is CharUpperW. I don’t think it is necessary to go again in details, just set a breakpoint at the end of StealCode and see what was overwritten:

At the beginning of CharUpperW the redirection has been placed:

7686E981 JMP KeygenMe.004017BE

The procedure at 4017BE takes as a parameter a  buffer of characters. It contains a big switch, which is substituting some characters by the others, by the defined pattern. I named it MixCharacters. So now we know, that CharUpperW leads to calling MixCharacters.

After the second “code stealing”, navigation goes to:


(in the procedure named start by IDA). It leads to the chunk that is decoding WindowName, which we already saw in the previous part of the research.


Then, the CreateWindowEx is called (as we found previously – it is hooked, and leads to execution of sub_402551(the potential Nag). And then the message dispatching loop is executed.

Let’s  set a breakpoint at call CreateWindowExW. It’s parameters are redirected to 402551. Now we can notice, that the parameter, deciding which path should be followed, is in reality the WindowWidth*!

* to be explicit: CreateWindow creates not Windows only, but a variety of controls, like labels, buttons, etc.


To sum up:

  • if the control width is different than 0x78 = 120 -> Execute original CreateWindowEx.


  • if the window width == 120 -> Execute the Nag.

Knowing this, we can remove a nag window by simply patching this check (at 40255E), and changing conditional jump to unconditional.

Obfuscation and defensive technics

The thing I enjoyed the most in this KeygenMe, was its obfuscation and set of defensive techniques (similar techniques are used by malware, that’s why AV systems picked on this).

I noted following:

  • dynamically loaded imports

(Handles to some functions were dynamically loaded and stored in variables. Then, calls were made via this variables  – to make static analysis more difficult)

Loading functions:


Using loaded function (example):


  • self-modifying code

Inside the key verification function we can find some points of code, that ends with Infinite loops (opcodes: EB FE)


It would not make any sense… However, during program execution, this places are modified, and they are converted to jumps to the continuation of the code!

  • calling functions in non-obvious way, i.e. complex “push-retn”KMv7_call_nag
  • “stolen code”, import hooking
    • beginning of the imported function is stolen (removed, and copied inside the KeygenMe space)
    • it is substituted by the call to “a proxy function” (belonging to a KeygenMe)
    • original code of imported function is called after the “proxy function” finished execution

Execution flow:

Let’s see all this elements on the example of the KeygemMe:
User32.dll -> CharUpperW (original):


User32.dll -> CharUpperW (modified):


stolen code + jump to rest of the function:


Function inside the KeygenMe, calling the stolen code via saved pointer (refered on the graph as: Application.myFunction ):


  • time-based anti-stepping protection:

RDTSC is called and it’s result is saved in a variable. In another place, RDTSC is called second time, and the result is compared with the saved one.

If the time difference is > 70000h, the process of generating key is distorted:

Posted in CrackMe | 3 Comments

PE-bear – version 0.3.7 available!

This time I focused on improving usability and implementing the features requested by the users
/* greetz to: Vincent, dummys, Ivan, sdax/ringi, Javier, and others! */


Major bugfixees:
– Support for unicode paths and tags

Major feature list:
– automatic calculation of: MD5/SHA1/Checksum
– opening files via shortcuts
– saving path to last open file
– added: reload PE

…and more!



Posted in PE-bear | 4 Comments