PLAY Ransomware

Upon opening the executable in IDA, one can see that most of the assembly code does not make sense and is not too meaningful.
An example can be seen from WinMain, where there is no clear return statement with garbage bytes popping up among valid code.
The control flow in WinMain calls sub_4142F5, and upon return, edi is popped and we run into the garbage bytes at 0x4142F2.
As a result, IDA fails to decompile this code properly.

Using return-oriented programming approach to divert the regular control flow of the program, PLAY is able to bypass most static analysis through IDA’s disassembly and decompilation.
Similar to most modern ransomware, PLAY obfuscates its API call through API name hashing.
The API resolving function takes in a target hash and a DLL address.

It walks the DLL’s export table to get the name of the exports.
For each API name, the malware calls sub_40F580 with the name as the parameter and adds 0x4E986790 to the result to form the final hash.
This hash is compared with the target hash, and if they match, the address of the API is returned.

Most important strings in PLAY are encoded in memory.
The decoding algorithm does not seem to be too clear.
PLAY can run with or without command-line arguments.

Prior to encryption, PLAY initializes and retrieves cryptographic algorithm providers.
Before iterating through all drives to encrypt, PLAY enumerates all volumes on the victim’s system by calling FindFirstVolumeW and FindNextVolumeW.

If the volume is not a CD-ROM drive or a RAM disk, the malware calls GetVolumePathNamesForVolumeNameW to retrieve a list of drive letters and mounted folder paths for the specified volume.
The final drive path to be encrypted is set to the network drive’s universal name or connection name, depending on which exists.
The ransom avoids encrypting “Windows” directory
The default chaining mode is set to AES-GCM.
However, if the file size is greater than 4025 times the encrypted size (which is the chunk size 0x100000 multiplied by the chunk count), the chaining mode is set to AES-CBC.
To encrypt a file from scratch, PLAY first generates an AES key to encrypt the file with.
It calls BCryptGenRandom to generate a random 0x20-byte buffer.
Depending on the chaining mode specified in the file structure, the malware calls BCryptSetProperty to set the chaining properly for its AES provider handle.
Next, BCryptGenerateSymmetricKey is called on the randomly generated 0x20-byte buffer to generate the AES key handle.