Stealer's crypt: Learning to crypt correctly.

[Tomcat]

So, meet - a bloody callus, a purulent abscess and a headache for everyone who works with logs, traffic and installations - crypt files​

What you will learn from this article:

• What is a file crypt, what is included there, what is not included, and what is completely different.
• Why 95% of crypto services on the market are useless duds, with a hellish overpayment of money.
• The difference between a “unique” and a “public” stub.
• What is the difference between scantime and runtime?
• Runtime - why is it not quite a crypt and not quite a simple matter?
• Uploading a file in the browser
• Smartscreen
• What to do as a result and how to resolve the issue with crypto?
• And much, much, much more!

The article is strictly based on rich empirical experience in working with the extraction of logs and, as a consequence, crypto files of various kinds. As a result, I had to completely abandon public services, then private services, and then plunge headlong into the ins and outs of this niche. I will introduce you to the results in this article.

Who will benefit from this article:

• For complete beginners, to immediately understand the overall picture of the world and its pitfalls.
• Experienced people who are already tired of God paying knows for what, which either doesn't work or works crookedly.
• Cryptors who decided to raise the level of their service (what the hell, maybe there will be such people here).

Who should pass by:

• You can't prove anything to your mother's warriors and monkeys with a 200% mark, and it's useless to explain to you any information that doesn't fit into your square-nest way of thinking.

What is a file crypt and why is it needed?​

If this article is being read by complete beginners, then you will have to explain it from the beginning. Roughly speaking, the file is encrypted so that for antiviruses this file looks white and fluffy. That is, it can be downloaded and launched, without any consequences from this very AB.

In general, this is where the crypt's task ends. But folk legends gradually began to attribute absolutely magical properties to it (the crypt, that is), and now in 2020, a “literate crypt” does not cure stage 4 leukemia

Active and proactive OS protection systems​

We figured out what crypt is. Right? Now let's break down the following question, which few people understand in general, and some aspects in particular. So, let's look at all the protection systems from start to finish in order. We will go through each point further in the future.

1) Loading a file in the browser – means the “ability” of the file to pass the browser scan and not issue various kinds of alerts (the file is dangerous, the file is potentially dangerous, the file is rarely downloaded, the file is blocked, etc.). The download should work simply - the file has been downloaded and is ready to open. All! No other options.

2) Static antivirus scan or ScanTime - AV scans directly inside the browser when downloading a file. A good crypt is responsible for successful completion. This option can sometimes be disabled; for some antiviruses, scantime scanning will not be performed.

That is, let's sum up the intermediate result - in order for the file to be downloaded without problems and without alerts, 2 protection systems must be passed - a browser and an antivirus.

3) UAC – sometimes services like to pretend that they bypass User Account Control. It has nothing to do with the request to open a file when downloading from a browser. In general, you don't need an extra alert, so you should try to bypass it, since it's not difficult.

4) Dynamic checking of AV at startup or the so-called RunTime - when you start a file, AV begins to actively check it using its own algorithms. The crypt is responsible for the passage, which must withstand this test. If you don't like something, screw it. We'll talk about the difference between scantime and runtime a little later. And about runtime, where everything is extremely difficult, we will devote a separate section of the article.

5) Smartscreen is another proactive protection system that is not related to antivirus. Verifies the file's signature and certification. If he doesn't like something, he starts asking questions on the topic: “Are you sure you want to run the file?” The logic of work is beyond the human sphere of understanding. Let's look at it separately, because you won't find information about the smartscreen anywhere else.

That is, let's sum up the final result - in order for the file to start without problems, 2 more protection systems must be passed - dynamic antivirus scanning and smartscreen. If your build is working (and many crypts kill the performance of the build, by the way), you will receive the long-awaited knock on the panel.

Checking crypts for quality - step one​

If you have a brain or already have experience, then you should immediately think that the encrypted file needs to be checked somewhere for functionality and ability to bypass security systems, in particular antiviruses. And if checking a file for the same load is quick and easy, then checking a file to bypass the protection of antiviruses, of which there are a dozen or so, is already a problematic task, to put it mildly.

That is why various kinds of checkers for viruses were invented - from the well-known VirusTotal (VT), which leaks everything to enemies (logically, this is his job), to supposedly shadow checkers that do not leak anything (avcheck, scanmaybin and dinchek).

The logic of the work is simple - you download the file, check the boxes of the ABs that interest you. Press the button and wait for the test results. The dinchek service (the only one) also has the ability to check for runtime - you can configure the parameters and check how your file behaves when launched.

The most important note #1 is that 90% of services do not deal with runtime. Why? More on this later.

The most important note #2 - you will be surprised, but most hamsters do not even know about such a parameter as runtime. Firstly, because see point 1. Secondly, because you can check it automatically only on dink, and this is quite expensive (3.5 bucks one-time or subscription from $50 per week).

The most important note #3 – I can't confirm it, but it seems like the avchek is leaking information to the left. The files began to die too quickly when I was working with it. This was not noticed behind the dinchek.

Checking the crypt for quality - step two​

Attention! ALL checkers on AB are a global scam and the scam of the century

Comrade, before you run, sticking out your tongue, to check your crypt on the same dink, read this article, especially the current paragraph, and your world will turn upside down.

So, I won't beat around the bush. If you have already visited forums specializing in certain services a la crypt file, then you might have noticed that everywhere the measure of success is zero detections on scantime via dinchek (usually everyone uses it). Some call it FUD=0, others call it differently, but the essence is simple - the file is checked somewhere and with an important look you are shown a link like “here, by zero, receive and sign.”

Software creators usually show statistics on runtime a la: “We have only N detectors, everything is cool and cool.”

And the whole point is that the data shown by the checkers is INCORRECT!

Important Note #4 – I don't know why this is, I won't lie. Because I haven't studied how checkers are structured and what algorithms they use. At least if there are detectors, then the checkers are truthful with a probability of 80-90%. But otherwise, they are critically at odds with what is in reality. If anyone has any assumptions/data, write to me in a personal message and let's talk.

It all started at one time with the fact that antiviruses on machines detected a file where it could not be detected by default, because all the checkers showed that the file was clean.

"What the hell?" - I thought, and we decided to delve deeper into this issue

1. 15 machines were created on WIN 10, on which 15 official antiviruses were installed.
2. We went through most of the well-known public and semi-public crypto services and tested it in live conditions. Exactly alive. Taking the file and personally downloading it through the browser to the machine and trying to run it.

Conclusion for scantime and Runtime - the discrepancy was up to 80% during live testing

Again. In eight cases out of 10, where the checkers showed that everything was clean, in reality a detection was observed! Especially on top antiviruses such as Avasta, Noda, Eseta and others.

Since I already directly feel that the readers' farts and hands are starting to burn, they are ready to type angry messages about “their personal failure is 90%,” I will immediately make certain adjustments.

Let me give you an example​

Gentlemen, I made a cryptic from my file. Loading, my dear, everything is nice and blissful with him. I decided to download it from my own machine. So what? An extra check wouldn't hurt. Yes, and I have AVAST on my own machine, the dog is like that, it doesn't miss a single nasty thing. And then, gentlemen, I download the file, and it's such an infection, it's detected! Well, I'm not a bastard, I quickly do a scantime check again - everything is clean, damn it!

From the dog! I took a couple of DEDs on the top ten, put AVAST there, and, gentlemen, killed me for half a day. Download - detectives! Detectives, grab his mother by the leg! And the checker shows that everything is clean!

What do I mean by this, if you personally check a file on a live machine with a certain AV, or even on several machines with the same AV, and you are constantly getting a sign about the presence of rubbish in the file - what are your conclusions? Who is right – the checker or your personal observations? I'll leave the question open.

Still don't agree with me?

Then read on, I will consider this issue further in the section “How then does everything work with such detections”?

Checking the crypt for quality - step three​

So, if I have shaken your picture of the world, and you have decided to check my words for truth yourself. Then your next step is simple - you need to make/buy at least 10 machines (the top 10 antiviruses can provide 90% coverage) and personally check the encrypted build for detections. Yes, with pens. Yes, in such a hemorrhoidal way. But this is the only way you can be sure of the quality of the work that was done to you!

Likewise, check the runtime. And you will be able to see the real picture of the world, and then calculate the approximate losses when the file is deleted.

And finally, no one is stopping you from using checkers to indirectly assess the “crypto standard of living.” And if, after loading, detections began to appear in the dyncheck, then with a probability of 80-90% this is so.

Critical Note #5 – Why do cryptors then ignore so many obvious data discrepancies? My opinion is that checking in this way is 1) too tedious and 2) impossible to prove to the client. Because the opposite situation also happens, when a file that is clean on live machines, for some reason, is strongly shown on dinchek as infected. The client cannot prove this, and who needs it?

The most important note #6 - From a technical point of view, making a pure scantime based on the performance of LIVING cars is no more difficult than making a pure scantime for a dincheck. But in this case, the lack of understanding of clients leads to the fact that it is easier for cryptors to feed false data about detections. And everyone is happy.

What is the difference between scantime and runtime?​

In this post I immediately answer 2 specific questions:

• What exactly is a crypt file process?
• Why don't 99% of cryptors engage in write time?

So. Let's simplify it very much for speed, otherwise you can safely sit down to write a book.

To make a crypt, first of all, you need some kind of “cryptographic module”. Which is bought or made from scratch. Next, based on this module, a stub is created (I simplify the explanation as best I can without unnecessary theory). Well, then you can plant any monkey that will press the button and receive a finished file.

Therefore, if you meet a support who is completely clueless about the topic and yells obscenities about how stupid everyone is, then the monkey has been detected. The person was simply forced to press a button and that was all. He won't help you anymore.

Important note #7 – Of course, the resulting stub will gradually fail and will have to be cleaned, upgraded and adjusted to the changing environment. Which is no longer the easiest task.

Now attention!

All of the above is ONLY true for scantime. Because there are no modules that would allow files to be automatically encrypted at runtime due to the difference in... let's call it that... the technological nature of the process. And it turns out that cleaning runtime is strictly manual and painstaking work.

The most important note #8 – Due to the labor costs and the average price for crypto on the market (20-50 bucks), there is no point in cleaning runtime for services. A logical question on the topic: “Why the hell do you need pure scantime if there are 100,500 detectors at runtime?” Let's move it to the next topic.

What is runtime?​

Let's repeat. Runtime is when you run a file, the antivirus scans it and makes sure that the process does not pose a threat. Meanwhile, the file does its dark deeds. Based on this alone, you can be sure that the process of cleaning rantain is much more complicated than making clean scantime. And cleaning runtime has nothing to do with crypto .

Runtime does not use the algorithms of the same module that is used for crypt on scantime. Again, the purity of runtime largely depends on the purity of the build that the creator of your software is doing. There are two types of runtime - static detect and dynamic detect.

Scantime crypt and runtime are two completely different operations that lie in completely different areas! And they don't intersect with each other in any way.

Conventionally, crypt for runtime is done like this:

1. AV operation algorithms are being studied
2. Scanning methods are being studied
3. Scanning weaknesses are found
4. The file is being “cleaned”

As you understand, any AV does not have a magic button to “decompile the file and get into the guts,” otherwise any tricks would be useless.

Therefore, when the file is launched, roughly speaking, “primary processing” of the data is carried out according to the algorithms installed by the AV. The cryptor's task is to identify them and bypass them. Next, the file will most likely be sent to the office for an in-depth examination. And then your crypt dies and everything will have to start all over again. It is through this window that you need to work. For a unique high-quality crypto, it can last for many days.

The most important note #9 – This is why the purity of the base software build becomes a critically acute problem. Because cleaning a file if there are sources is a million times easier than cleaning a ready-made build and removing runtime detections

Important note #10 - Despite this, it is quite possible to remove 3-5 detectors per runtime. Depends on what kind of AB is being fired. With a relatively clean build and a strong cryptor, you can bring the real runtime indicator to 1-3

Why 95% of crypto services on the market are useless dummies. Have you asked? We answer!​

I don't want to offend anyone, the post has a neutral connotation. Some have a business, others have information about this business

So, based on the above, we take 3 points:

• The difference between the checker reading (avcheck/dincheck/scanmaybin) and real data. The difference can be so critical (especially if the stub is old and has not been updated for a long time) that the meaning of the crypt as a crypt disappears altogether.
• Lack of crypto for runtime. If the build itself already stinks like a rotten egg and real detections at runtime have exceeded 6-7, then what's the point of even a perfectly clean scantime crypt? The most popular 7-8 ABs account for approximately 80-90% of global usage.
• And of course, few people will use an expensive unique stub (which who the hell will do), which generally reduces the use of crypto to zero.

The most important note #11 - Again, there are quite adequate services that make crypts for Scantime using the same method as I described. They take cars, put AB there and check with their pens whether it will be detected or not. Unfortunately, such services rarely go public, due to the problems I mentioned earlier. Nobody wants to explain to stupid monkeys why checkers should not be trusted.

How to identify services/specialists with whom you should not work?

• When asked about runtime, they either fall into a stupor or say that this is not their problem - an adequate service will explain that they do not deal with this and the cleanliness of the runtime should be monitored by the creator of the software. Cool service - it will clear the anti-time with an adequately clean build.
• He spits venom when reading this article and says that this is all a lie and untrue.
• When asked “Why is such a supposedly pure crypt being burned on a living machine?” starts to behave inappropriately and spews shit.

The logical question is why then there are installations at all and people working with them? Some are even quite successful.​

This is a good question and I think it definitely needs to be addressed!

First of all, let's define a critical nuance. Do you receive installs from your traffic or buy them?

In the first case, you will hear a common story on the topic: “It's useless to send traffic to an exe file, no one downloads it, it's all bullshit, this is already the last century.” Or you will hear a lot of sad stories about the low envelope. Or you will hear how difficult it is to upload files, because “the envelope is not happy.” This is logical - such a crypt will cut almost the entire envelope by 5-10 times. Believe me, a good landing page for porn traffic will give 10-15% of the conversion as a native one. With good traffic, of course. But instead of 10-15 installs from 100 clicks, you will get 1-2-3 installs with difficulty.

When buying installations, the picture is different. First of all, most of the traffic there is motivated. And the shkolota will not care about all AB alerts and will actively install software in the hope of cheats from CS or GTA. Otherwise, there is what is called “survivorship bias.”

Important Note #12 - Look at the desktop screenshot of your installations. You will see that most of the machines are either not protected at all, or have AVs of unknown origin. You will rarely see logs from such AV as Eset, Avira, Commodo, Avast, etc.

Critical Note #13 – As you go along, if you honestly think your crypt is good, then you've most likely already fallen into survivorship bias. Google it, get into it. Perhaps this will help you look at the “picture of the world” from a different angle.

The difference between a “unique” and a “public” stub​

As I already wrote, the current crypt, from the point of view of shkolota and other sudras, does not cure the last stage of oncology. It also gives enlightenment and generates bitcoins every day. Cryptors are going nuts from such presentations, and the public market is losing its last adequate professionals

First of all, “unique stub” means that it is made individually for the software you need. For those who have not yet understood: module - stub - crypt. Thus, if we assume that the cryptor “created” a unique stub for a specific client, based on the indicators of “living machines” and reduced it to FUD = 0 according to scantime. Then you can take a build, put it in an archive with a password, keep it on the cloud for a week, then take it out, check it and it will still be FUD=0

Important note #14 – Don't forget that checking live ABs kills crypts. This method is used ONLY to check the quality of the crypto service, and not for constant verification of the crypto build.

In turn, the public “stub” is made according to the principle – one for everyone. And the lifespan of such a crypt is extremely limited. Therefore, it is usually done immediately before the spill and they hope that he will not die after 5 minutes.

Important note #15 – This is a completely adequate option for those who buy installations and are confident in the speed of the spill. The lifespan of a public stub is random.

Well, you need to understand that a high-quality uni-stub for your software usually has a price tag for rent per month for an unlimited crypt file. Because no one cares how many times you are going to use it. Price from 1K and above.

Uploading a file in the browser​

This is where the earthly path of your file begins. Ideally, there should be no alerts a la - the file is dangerous, the file is potentially dangerous, the file is rarely downloaded, the file is blocked. Otherwise, you can forget about 99% of the impact.

First of all, you need to understand two basic things:

• Loading the file itself in the browser does NOT DEPEND on the crypto! The opposite is also true - even the best crypt will not help the load! Because these are different things. Completely different.
• Checking a file with a browser and an antivirus are two different checks.

Critical Note #16 – One more time. First, when downloading a file, the file is checked by the browser (especially when the file is loading and the download icon is blinking and spinning). Then, after downloading, the file is scanned by the antivirus (if this module is active).

Preparing a file for loading in a browser is a complex and multifactorial task. And, of course, no one will try to solve it

As a bonus, Google also does not stand still and constantly introduces new conditions. In general, to solve the problem you need to have at least:

1. A specific signature
2. Certificate
3. Crypt (well, this is logic - because it's better not to Google a clean build)
4. Clean IP domain and hosting

That is, as you noticed, crypting a file and preparing an already encrypted file for loading in a browser are completely different tasks. An adequate cryptor with straight hands can help with this problem, but usually does not want to. Why? Thanks to the shkolota who began to demand this almost with complaints and hysterics.

Important Note #17 – A crypt is a crypt. A load is a load. Don't mix everything together. Each problem requires a separate solution.

Smartscreen​

The last line of defense of Windows 10. A headache for denkeepers. And a thing of dubious usefulness for the average user.

What is its theoretical essence?

Apparently, the system was supposed to check the certification of files and take files without a trusted certificate.

What in fact?

In fact, the smartscreen works like a drug addict on a mixture of DMT, LSD and fly agarics. Blocks good files, allows bad ones. Does not pay attention to untrusted files and swears at files with a valid signature. And completely random.

What is the problem?

On average, about 30% of machines have a sign from the smartscreen “do you want to install a file? The signature could not be verified." It's normal for an envelope to cut like that...

How to get around?

Unfortunately, there are no guaranteed workarounds. An ordinary valid certificate does not completely solve the problem. As practice has shown, the use of a valid certificate, which sells for 200-300 bucks, reduces the appearance of the window by about 1.5-2 times. Is it worth the money? Here everyone decides for themselves.

Important note #18 – There are situations when the smartscreen does not allow a file to pass through that has a valid license or digital signature officially purchased with hard-earned money. This is due to the fact that there are too few downloads of this file. Cheating won't help, you don't have to try. It is officially believed that an extended sample developer license helps. There are also situations when a file without a certificate and signature is opened without questions. Some ABs act exactly according to this scheme when opening a file, even if it is crystal clear.

How to resolve the issue?

Again, either just accept it or use a valid certificate. You can try to buy it yourself - it will save a lot of money. At Komodo it costs only 80-90 dollars. Go for it.

Pricing Policy

I will just give my own thoughts on this matter, again based on personal experience. Maybe this will help someone.

Price for public crypt (scantime): $10-50 In principle, the price depends on the algorithm used and the purity of scantime. Buying crypto for $10, you get the corresponding quality. More expensive crypts - better quality. As practice shows, there are still cryptors who still make normal and adequate public cryptos.

In general, there is gold right - crypt for 10-15 bucks, this is not crypt, but a useless imitation

Also check, for many, the price of crypto (which costs $30-50) may include assistance with loading in the service. At least it used to be included until Google tightened all the nuts.

Price for a unique crypt (scantime + runtime): here you need to understand 2 options for the situation. First of all, a cryptor who can make a unique stub can also clear runtime. But this does not apply to crypto! Once again: runtime has nothing to do with crypto! And the service will most likely have to be provided jointly. Typically, a one-time crypt for a unique stub costs about $100-$150 + runtime cleaning. Monthly rental of a unique stub for yourself costs 1-2K.

Important note #19 – the price of a unique stub is based on labor costs. Who do you think will buy you such a very expensive module, then create a stub, debug, clean it and all in order to sell you crypts for $40-50? There are no idiots. If you think there is, then most likely you are the idiot here.

The most important note #20 - if you are offered a unique stub for too cheap money, then this is a common scam. Don't fall for scammers. Crypt is either cheap and simple. Or expensive and complicated. There is practically no middle ground here.

Price for help with loading: By today's standards, $20-40, taking into account the fact that preparing a file is not the fastest thing, in principle, an adequate price. Another thing is that this task is tedious in the sense that it is not worth the money. On the third side, it is always possible to reach an agreement. An extra coin won't hurt anyone.

What to do as a result?

I'll correct myself and offer 2 options to choose from:

1) We stock up on money, popcorn and go look for all the cryptors on the market. We make a list. Let's clarify what he uses to check scantime. We make sure to check the crypts ourselves on live machines. If there is no discrepancy, congratulations! If there is, we try to come to an agreement and provide evidence. If you didn't tell me to go to hell, congratulations! If sent, we look further.

Important Note #21 – Digging through shit usually always produces results! Don't give up. There are adequate cryptors, you just need to find them.

2) We are looking for a technical partner who understands the basics of this whole bad thing. Well, or who has the skills to figure it out. I assure you, there are many good and smart guys who also sit on the forums and are looking for an opportunity to join or create a team.

Important note #22 – by this time you need to have at least some kind of base. If you yourself don't know shit, don't know how and don't have it, then exactly the same fluff will stick to you. Do you need it?