PZM Solutions

Russian translation - https://vk.com/wall-212294020_22 Why partition is neccessary for your application security? First of all, let's define what partition is and what does it stand for. PZMutator provides you an option called binary partition, with this option enabled your binary will require you to allocate several memory regions for your application instead of just one, thus the binary will be mapped on these regions: each region contains only a single page (4096 bytes) of real data (functions, pointers, constants etc), you can fill the region with random junk bytes to confuse attackers but it's up to you. From the attacker perspective dumping your application will look like this: firstly, he needs to find all of the memory regions that your application uses; secondly, he needs to save all of these regions to binary files (note that your application may contain more than hundreds of regions depending on its real size); finally, attacker should make a database in any of dissasemblers by combining the regions to begin static analysis. Instead of just finding region with your application and dumping it, mutated binaries with partition are much harder to dump and analyze. We highly recommend you to turn on partition option for your project. What is partition verification? As you may know there's an address space in any application that is reserved for system modules only and in our case the deal is ntdll.dll. Let's get deeper into it. First of all, we need to be aware of the algorithm of process creation: when process is spawned in usermode and main (and not any other) thread hasn't been launched yet, there's some memory regions which are reserved: the lowest region is your application's PE itself and the highest is ntdll.dll, if your application is running under x64 Windows there will be some more dlls in 64-bit space like ntdll.dll (x64), wow64.dll, wow64cpu.dll and some others... The most known and common dump launching (cracking) technique is to break an application when it launches and allocate memory region with any (dump) base, this approach doesn't require attacker to find and manually fix all of the relocs (which is nearly impossible itself with the mutator). To prevent your application dumps from being simply mapped into address space we've added an option which called partition verification in the mutator. With this option enabled mutator will require your clients to allocate memory regions for some of the fragments on extremely high address space. In the request with mapper data there will be additional field (int) in json object called "high_pages", this field contains the number of regions which have to be allocated with base higher than 0x77000000, to achieve this you should scan all memory starting from 0x77000000 and find spaces with no mapped modules there (1 page cave is enough for each region). Partition verification option will check if there's enough pages allocated on high memory and if not (e.g., attacker patched an application to prevent memory from allocating that high), mapping process will be aborted. To enable both partition and partition validation you need to set these options to true in SDK while initializing the mutator.

pzm::instance->set_option< bool >( pzm::option_t::OPTION_PARTITION, true );
pzm::instance->set_option< bool >( pzm::option_t::OPTION_PARTITION_VALIDATE, true );

Still need assistance and security advice? Contact us - pzm322.com

Mutator v1.2. - Added binary partition and option to verify each partition on backend. More information - Jump tables are now being shuffled seperately from functions that own them - Improved .rdata shuffling - Improved function shuffling with try/catch blocks - Fixed binary size calculaiton - Fixed crashes related to library functions shuffling - Optimized mapping process, now it takes only 5 ms. Data preparation process takes less than 1 ms. Please note that some of APIs have changed, SDK has already been updated for the latest API.

Note that there's a PoC snippet of usage, if you want to use mutator without creating additional dependencies in your backend project please refer to this repository - https://github.com/pzm322/mutator

Mutator v1.1. - Added random junks generation - Added ON_MMAP_START, ON_MMAP_END callbacks - Added library functions shuffling - Improved several mutation types - Improved direct import mapping - Removed paddings after functions epilogue in .text section - Fixed conditional jumps pointing outside of functions - Fixed xmmwords alignment causing crashes - Fixed incorrect float pointers behavior while formatting - Added callback support in SDK Purchase for $149/month here. Note that mutator currently supports only x86 Windows portable executables (PE)

Starting from 17 Oct 2022 pzmutator will be available for $149/month. SDK and docs as well as further necessary information and snippets will be published at 0:00 EST.

pzmutator has never been so easy to use. Release for public use soon

PZMPay admin dashboard. * Currently available only for invited users/companies

We added more european payment methods and gateways to our new PZMPay version as well as alipay gateway for china.

We have finally finished developing our own payment gateway pzmpay. A new version of PZMPay has minimalistic responsive design with correct and simple layout on each type of device. We have also paid much attention to experience of payment process by making it as simple and native as possible. Current payment process is multistaged (region -> method -> details -> confirmation (if needed)) unlike the previous version of PZMPay. The new version of PZMPay supports cards issued anywhere outside of Russia as well as russian cards, for russian payers payment amount is calculated in rubles for any other payers in US dollars. We are planning to release this version by connecting to our projects starting from tomorrow. Stay tuned!