OP 04 October, 2024 - 12:22 AM
(This post was last modified: 04 October, 2024 - 12:23 AM by fireworks. Edited 1 time in total.)
I didn't find a similar article, so I decided to share it. I am not the author of this article, the article was found in the public space
.
So, meet the bloody blister, the purulent abscess and the headache of everyone who works with logs, traffic and installations – the crypt file.
What you will learn from this article:
What is a file crypt, what is included in it, what is not included, and what is completely different.
Why 95% of crypto services on the market are useless dummy, with hellish overpayment of money.
The difference between "unique" and "public" stub.
What is the difference between scantime and runtime?
Runtime - why is it not quite crypto and not quite a simple matter?
Loading file in browser
Smartscreen
What to do in the end and how to solve the issue with crypto?
And much, much, much more!
What is a file crypt and why is it needed?
If this article is being read by complete newbies, then I will have to explain it from the basics. Roughly speaking, a 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 AV.
In general, this is where the task of the crypt ends. But folk legends gradually began to attribute to it (the crypt, that is) absolutely magical properties, and now in 2023, a “literate crypt” almost does not cure stage 4 leukemia.
Active and proactive OS protection systems
We figured out what a crypt is. Right? Now let's break down the next question, which few people understand in general and in some aspects in particular. So, let's consider all the protection systems from A to Z in order. We will go over each of the points further.
1) File loading in the browser - means the "ability" of the file to pass the browser check and not issue various alerts (the file is dangerous, the file is potentially dangerous, the file is rarely downloaded, the file is blocked, etc.). Loading should work simply - the file has downloaded and is ready to open. That's it! No other options.
2) Static antivirus check or ScanTime - AV performs a check directly inside the browser when downloading a file. A good crypt is responsible for successful completion. This option can sometimes be disabled, in some antiviruses, thus, the scantime check will not be performed.
So, let's sum it up - in order for the file to download without problems and alerts, 2 protection systems must be passed - the browser and the antivirus.
3) UAC - sometimes services like to show off that they have implemented a bypass of User Account Control. It has nothing to do with the request to open the file when downloading from the browser. In general, you do not need an extra alert, so you should worry about the bypass, fortunately, it is not difficult.
4) Dynamic check of AV at startup or the so-called RunTime - when the file is launched, AV begins to actively check it according to its algorithms. The crypt is responsible for passing, which must withstand this check. If something is not liked - screw it. We will talk about the difference between scantime and runtime a little later. And about runtime, where everything is extremely complicated, we will devote a separate block of the article.
5) Smartscreen is another proactive protection system that is not associated with the antivirus. Checks the file signature and its certification. If it doesn't like something, it starts asking questions like: "Are you sure you want to run the file?" The logic of the work is beyond human comprehension. Let's consider it separately, because you won't find information about the smartscreen anywhere else.
That is, let's sum it up - in order for the file to run without problems, 2 more protection systems must be passed - dynamic antivirus check 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 the quality of the crypt – step one
If you have a brain or already have experience, then you should immediately think about the fact that an encrypted file needs to be checked somewhere for operability and the ability to bypass protection systems, in particular antiviruses. And if checking a file for the same progruz is quick and easy, then checking a file to bypass the protection of antiviruses, of which there are 3-4 dozen, is already a problematic task, to put it mildly.
That is why various types of virus checkers were invented - from the well-known VirusTotal (VT), which leaks everything to enemies (logically - this is its job), to supposedly shadow checkers that do not leak anything (avcheck, scanmaybin and dincheck).
The logic of the work is simple - you upload a file, mark the AVs that interest you with checkboxes. Click the button and wait for the results of the check. The dincheck service (the only one) also has the ability to check for runtime - you can configure the parameters and check how your file will behave when launched.
The most important remark #1 – 90% of services do not deal with runtime. Why? More on that later.
The most important remark #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 it can be checked automatically only on dincheck, and this is quite expensive (3.5 bucks one-time or a subscription from 50 dollars per week).
The most important remark #3 – I can’t confirm, but it seems that avchek is leaking information “to the left”. The files were dying too quickly. I haven’t noticed anything like that with dynchek.
Checking the quality of the crypt – step two
Attention! ALL checkers on AV are a global scam and the fraud of the century
Comrade, before you run with your tongue hanging out to check your crypt on the same dincheck, read this article, especially the current paragraph and your world will turn upside down.
So, I will not beat around the bush. If you have already visited forums specializing in certain services a la crypt file, then you could notice that everywhere the measure of success is zero detections on scantime through dincheck (usually everyone uses it). Someone calls it FUD=0, someone else, but the essence is simple - the file is checked somewhere and with an important look they show you a link like "here, by zeros, get it and sign for it."
Software creators usually show runtime statistics a la: "We have only N detections, everything is cool and awesome."
And the whole point is that the data that the checkers show is INCORRECT!
The most important remark #4 – I don’t know why this is so, I won’t lie. Because I haven’t studied how checkers are structured and what algorithms they work on. At least if there are detections, then checkers are truthful with a probability of 80-90%. But otherwise, they critically diverge from what is in reality.
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 checkers showed that the file was clean.
"What the hell?" I thought, and we decided to delve deeper into this issue.
15 machines were created on WIN 10, on which 15 official antiviruses were installed.
We tried most of the well-known public and semi-public crypto services and tested it in live conditions. Live conditions. By 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 checking
Once again. In eight cases out of 10, where the checkers showed that everything was clean, in reality there was a detection! Especially on top antiviruses like Avast, Noda, Eset and others.
Since I can already feel that the readers' asses and hands are starting to burn, ready to type angry messages about "their personal 90% knockback", I will immediately make certain adjustments.
Let me give you an example.
Gentlemen, I made a cryptic file from my own file. It loads, my dear, everything is fine and dandy with it. I decided to download it from my native machine. Well, so what? A really extra check wouldn't hurt. And I have AVAST on my native machine, such a dog, it doesn't miss a single nasty thing. And then, gentlemen, I download the file, and the bastard, it, is detected! Well, I'm no fool, I quickly do a scantime check again - everything is clean, damn it!
What a dog! I took a couple of dedicated servers on the ten, installed AVAST there, killed, gentlemen, half a day. I download - detections! Detections, damn it! And the checker shows that everything is clean!
What I mean is, 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 persistently getting a sign about the presence of crap in the file - what are your conclusions? Who is right - the checker or your personal observations? I will leave the question open.
Still do not agree with me? Then read on, I will consider this question additionally in the section "How do they all work then, with such detections?"
Checking the quality of the crypt – 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 (top 10 antiviruses can easily provide 90% coverage) and personally check the crypto build for detections. Yes, manually. 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 for you!
Similarly, check the runtime. And you will be able to see the real picture of the world, and then calculate the approximate losses when printing a file.
And finally - no one prevents you from using checkers for an indirect assessment of the "standard of living of a crypto". And if after loading in the dincheck, detections began to appear, then with a probability of 80-90% this is true.
The most important remark #5 – Why do cryptographers ignore so many obvious data discrepancies? My opinion is that checking in this way is 1) too tedious; 2) impossible to prove to the client. Because there is also the opposite situation, when a clean file on live machines, for some reason, is strongly shown on the dincheck as infected. It is impossible to prove this to the client, and who needs it?
The most important remark #6 – From a technical point of view, making a clean scantime based on the indicators of LIVE machines is no more difficult than making a clean scantime for dincheck. But in this case, the lack of understanding of clients leads to the fact that it is easier for cryptocurrencies to feed false data about detections. And everyone is happy.
What is the difference between scantime and runtime?
In this block I immediately answer 2 specific questions:
What is the process of file encryption anyway?
Why don't 99% of cryptocurrencies do raintime?
So. Let's simplify it for speed, otherwise you can easily sit down to write a book here.
To make a crypt, first of all, you need some kind of "cryptographic module". Which is bought or made from scratch. Then, based on this module, a stub is created (I'm simplifying the explanation as best I can without unnecessary theory). Well, then you can put any monkey who will press the button, and get a ready file.
Therefore, if you meet a support who has no clue about the topic and yells obscenities about how stupid everyone is - then the monkey has been detected. The person was simply put to press a button and that's it. He won't help you in any way anymore.
The most important remark #7 – Of course, the resulting stabilizer will gradually fail and will have to be cleaned, upgraded and adjusted to the changing environment. Which is not the easiest task.
Now, attention!
All of the above is true ONLY for scantime. Because there are no modules that would allow automatic encryption of files under runtime due to the difference in the... let's call it that... technological nature of the process. And it turns out that cleaning runtime is strictly manual and painstaking work.
The most important remark #8 – Given the labor intensity and average price for crypto on the market (20-50 bucks), there is no point in services cleaning runtime. The logical question on the topic: “Why the hell do you need a clean scantime if there are 100500 detections in runtime?” will be moved to the next topic.
What is runtime?
Let's repeat ourselves. Runtime is when you launch a file, the antivirus scans it and makes sure that the process is not dangerous. Meanwhile, the file does its dirty deeds. Based on this alone, we can see that the process of cleaning runtime is much more complicated than making a 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 crypto on scantime. Again, the purity of runtime largely depends on the purity of the build that the creator of your software is doing. Runtime comes in two types - static detect and dynamic detect.
Crypt on scantime and runtime are completely different operations, lying in completely different areas! And they do not intersect with each other in any way.
Conventionally, crypto on runtime is done like this:
The algorithms of the AV operation are studied
Scanning methods are being studied
Weak spots in scanning are found
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 a file is launched, roughly speaking, "primary processing" of the data is carried out according to the algorithms installed in the AV. The cryptographer's task is to identify them and bypass them. Then the file will most likely be sent to the office for an in-depth examination. And then your crypt will die and everything will have to be started from the beginning. This is exactly the window you need to work in. For a unique, high-quality crypt, it can stretch out for many days.
The most important remark #9 – This is why the cleanliness of the basic software build becomes a critical problem. Because cleaning a file with the source code is a million times easier than cleaning a ready-made build and removing runtime detections
The most important remark #10 - Despite this, it is quite possible to remove 3-5 detections per runtime. Depends on which AV is being detected. With a relatively clean build and a skilled cryptor, you can bring the real runtime indicator to 1-3
Why 95% of crypto services on the market are useless dummy. 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 readings (avcheck/dincheck/scanmaybin) and the real data. The difference can be so critical (especially if the stab is old and hasn't been updated for a long time) that the meaning of the crypto as a crypto disappears altogether.
Lack of crypto for runtime. If the build itself already stinks like a rotten egg and real runtime detections have gone well beyond 6-7, then what's the point of even a perfectly clean scantime crypto? The most popular 7-8 ABs make up about 80-90% of global usage.
And of course, few people will use an expensive unique stub (which hardly anyone will make), which generally reduces the use of crypto to zero.
The most important remark #11 - Again, there are quite adequate services that make crypto for scantime using the same method as I described. They take machines, put AB there and check manually - whether it is detected or not. Unfortunately, such services rarely go public, due to the problems I mentioned earlier. No one wants to explain to stupid monkeys why checkers should not be trusted.
How to identify services/specialists that you shouldn’t work with?
When asked about runtime, they either go into a stupor or say that it is not their problem - an adequate service will explain that they do not deal with this and the software creator should monitor the purity of the runtime. A cool service will clean the runtime with an adequately clean build.
He spits venom when reading this article and says that it is all a lie and untruth.
When asked "Why is such a supposedly clean crypt exposed on a live machine?" he starts to behave inappropriately and sprays shit.
A logical question is why do installations happen at all and why do people work with them? Some are even quite successful.
This is a good question and I think it is absolutely necessary to analyze it!
First of all, let's define a critical nuance. Do you get installs from your traffic or buy them?
In the first case, you will hear a common story on the topic: "It is useless to pour traffic to an exe file, no one downloads it, everything is crap, it is already the last century." Or you will hear many sad stories about low conversion. Or you will hear how hard it is to pour files, because "the conversion is not pleasing." This is logical - such a crypt will cut almost the entire conversion by 5-10 times. Believe me, a good landing for porn traffic will give 10-15% 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 and running.
When buying installs, the picture is different. First of all, most of the traffic there is motivated. And schoolchildren will spit on all the alerts of AV and actively install software in the hope of cheats from CS or GTA. Otherwise, there is the so-called "systematic survivorship bias".
Important note #12 - Look at the screenshot of your installations' desktop. You will see that most machines are either not protected at all or have AV of unknown origin. You will very rarely see logs with such AV as ESET, Avira, Commodo, Avast, etc.
Key Note #13 – While you’re working, if you honestly think your crypt is good, you’ve probably already fallen into survivorship bias. Google it, dig into it. Maybe it’ll help you look at the “picture of the world” from a different angle.
The difference between "unique" and "public" stub
As I already wrote, the current crypto from the point of view of schoolchildren and other scum, except that it does not cure cancer in the last stage. And also gives enlightenment and generates bitcoins every day. Cryptographers are shocked by such claims, and the public market is deprived of the last adequate professionals
. First of all, "unique stub" is implied by the fact that it is made individually for the software you need. For those who have not yet understood: module - stub - crypto. Thus, if we assume that the cryptographer "created" a unique stub for a specific client, based on the indicators of "live machines" and reduced it to FUD = 0 by scantime. Then you can take the build, shove it into an archive under a password, keep it on the cloud for a week, then get it out, check it and there will still be FUD = 0
Important Note #14 – Don't forget that live AB check kills crypto. This method is ONLY used to check the quality of the crypto service, not to constantly check the crypto build.
In turn, the public "stab" is made on the principle - one for all. And the lifespan of such a crypt is extremely limited. Therefore, it is usually made immediately before the spill and they hope that it will not die in 5 minutes.
The most important remark #15 – This is a completely adequate option for those who buy installations and are confident in the speed of the spill. The lifespan of the public stub is random.
Well, you have to understand that a quality unique stab for your software usually has a price tag for renting a month for an unlimited crypto file. Because no one cares how many times you are going to use it. The price is from 1K and up.
Loading file in browser
This is where your file's earthly path begins. Ideally, it should be without alerts like - file is dangerous, file is potentially dangerous, file is rarely downloaded, file is blocked. Otherwise, you can forget about 99% of the knock.
First of all, you need to understand two basic things:
Loading of the file itself in the browser does NOT DEPEND on the crypt! The opposite is also true - even the best crypt will not help loading! Because these are different things. Completely different.
Checking a file with a browser and an antivirus are two different checks.
The most important note #16 – Once again. First, when you download a file, the file is checked by the browser (especially when the file is downloading and the download icon is blinking and spinning). Then, after downloading, the file is checked 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 reveal the ways to solve it.
As a bonus, Google is also not standing still and is constantly introducing new conditions. In general, to solve the problem, you need to have at least:
A specific signature
Certificate
Crypt (well, that's logic - because it's better not to google a clean build)
Clean IP of 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 cryptographer with straight hands can help with this problem, but usually does not want to. Why? Thanks to schoolchildren who began to demand this almost with complaints and hysterics.
The most important note #17 – crypt is crypt. Load is load. Don’t mix everything together. Each task requires a separate solution.
Smartscreen
The last line of defense of Windows. A headache for logon users. 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 into account files without a trusted certificate.
What is the reality?
In fact, the smartscreen works like a drug addict on a mixture of DMT, LSD and fly agarics. Blocks good files, lets through bad ones. Doesn't pay attention to untrusted files and swears at files with a valid signature. And completely randomly.
What's the problem?
On average, about 30% of machines have a sign from the smartscreen "do you want to install the file? Signature could not be verified." The envelope is usually so cutting ...
How to bypass?
Alas and ah, there are no guaranteed bypass methods. An ordinary valid certificate does not solve the problem completely. As practice has shown, the use of a valid certificate, which are sold for 200-300 bucks, reduces the appearance of the window by about 1.5-2 times. Is it worth the money? Everyone decides for themselves.
The most important remark #18 – There are situations when the smartscreen does not allow a file 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 will not help, you can not try. It is officially believed that the developer's license of the extended sample helps. And there are also situations when a file without a certificate and signature opens without questions. Some AV, when opening a file, act exactly according to this scheme, even if it is crystal clear.
How to solve the problem?
Again, either just put up with it or use a valid certificate. You can try to buy it yourself - this will significantly save money. Komodo costs only 80-90 dollars. Go for it.
Pricing policy
I will just give my own thoughts on this matter, based again on personal experience. Maybe it will help someone.
Price for public crypt (scantime): 10-70$ In principle, the price depends on the algorithm used and the purity of the scantime. Buying a crypt for 10 dollars, you get the corresponding quality. More expensive crypt - better quality. As practice shows, there are still cryptographers who make normal and adequate public crypt.
In general, there is a golden right - a crypt for 10-15 bucks is not a crypt, but a useless imitation.
Also check, for many, the price of a crypt (which cost 30-50$) may include help with loading. At least it used to be, until Google tightened all the screws completely.
Price for a unique crypt (scantime + runtime): here you need to understand 2 options of the situation. First of all, a cryptor who can make a unique stub can also clean the runtime. But this does not apply to the crypt! Once again: runtime has nothing to do with the crypt! And the service will most likely have to be provided jointly. Usually, a one-time crypt for a unique stub costs about $100-$150 + runtime cleaning. Monthly rent of a unique stub for yourself costs 1-2K.
The most important remark #19 – the price of a unique stab is based on labor costs. Who do you think would buy you a very expensive module, then create a stab, debug it, clean it, and all for the sake of selling you crypto for $40-50? There are no idiots. If you think there are, then most likely you are the idiot here.
The most important note #20 - if you are offered a unique stab for too cheap money, then this is a common scam. Do not fall for the scammers' bait. Crypto is either cheap and simple. Or expensive and complex. There is practically no middle ground here.
Price for help with loading: By today's standards, $20-50, considering that preparing a file is not the fastest thing, is basically an adequate price. Another thing is that this task is boring in the sense that it is not worth the money. On the other hand, you can always come to an agreement. An extra coin never hurt anyone.
What to do as a result?
I am correcting myself and offering as many as 2 options to choose from:
1) Stock up on money, popcorn and go look for all the cryptors on the market. Make a list. Specify what he uses to check scantime. We ourselves must check the crypto on live machines. If there are no discrepancies, congratulations! If there are, we try to agree and provide evidence. If they didn't tell you to fuck off, congratulations! If they did, we keep looking.
The most important remark #21 – digging in shit usually always gives results! Don’t give up. Adequate cryptors exist, you just need to find them.
2) We are looking for a partner-technician who understands the basics of this whole mess. Well, or who has the skills to figure it out. I assure you, there are many good and smart guys who also sit on forums and are looking for an opportunity to join or create a team.
The most important remark #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 to do anything and don’t have anything, then exactly the same trash will stick to you. Do you need it?
leaving a like is much appreciated and help me to keep publishing threads.
.
So, meet the bloody blister, the purulent abscess and the headache of everyone who works with logs, traffic and installations – the crypt file.
What you will learn from this article:
What is a file crypt, what is included in it, what is not included, and what is completely different.
Why 95% of crypto services on the market are useless dummy, with hellish overpayment of money.
The difference between "unique" and "public" stub.
What is the difference between scantime and runtime?
Runtime - why is it not quite crypto and not quite a simple matter?
Loading file in browser
Smartscreen
What to do in the end and how to solve the issue with crypto?
And much, much, much more!
What is a file crypt and why is it needed?
If this article is being read by complete newbies, then I will have to explain it from the basics. Roughly speaking, a 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 AV.
In general, this is where the task of the crypt ends. But folk legends gradually began to attribute to it (the crypt, that is) absolutely magical properties, and now in 2023, a “literate crypt” almost does not cure stage 4 leukemia.
Active and proactive OS protection systems
We figured out what a crypt is. Right? Now let's break down the next question, which few people understand in general and in some aspects in particular. So, let's consider all the protection systems from A to Z in order. We will go over each of the points further.
1) File loading in the browser - means the "ability" of the file to pass the browser check and not issue various alerts (the file is dangerous, the file is potentially dangerous, the file is rarely downloaded, the file is blocked, etc.). Loading should work simply - the file has downloaded and is ready to open. That's it! No other options.
2) Static antivirus check or ScanTime - AV performs a check directly inside the browser when downloading a file. A good crypt is responsible for successful completion. This option can sometimes be disabled, in some antiviruses, thus, the scantime check will not be performed.
So, let's sum it up - in order for the file to download without problems and alerts, 2 protection systems must be passed - the browser and the antivirus.
3) UAC - sometimes services like to show off that they have implemented a bypass of User Account Control. It has nothing to do with the request to open the file when downloading from the browser. In general, you do not need an extra alert, so you should worry about the bypass, fortunately, it is not difficult.
4) Dynamic check of AV at startup or the so-called RunTime - when the file is launched, AV begins to actively check it according to its algorithms. The crypt is responsible for passing, which must withstand this check. If something is not liked - screw it. We will talk about the difference between scantime and runtime a little later. And about runtime, where everything is extremely complicated, we will devote a separate block of the article.
5) Smartscreen is another proactive protection system that is not associated with the antivirus. Checks the file signature and its certification. If it doesn't like something, it starts asking questions like: "Are you sure you want to run the file?" The logic of the work is beyond human comprehension. Let's consider it separately, because you won't find information about the smartscreen anywhere else.
That is, let's sum it up - in order for the file to run without problems, 2 more protection systems must be passed - dynamic antivirus check 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 the quality of the crypt – step one
If you have a brain or already have experience, then you should immediately think about the fact that an encrypted file needs to be checked somewhere for operability and the ability to bypass protection systems, in particular antiviruses. And if checking a file for the same progruz is quick and easy, then checking a file to bypass the protection of antiviruses, of which there are 3-4 dozen, is already a problematic task, to put it mildly.
That is why various types of virus checkers were invented - from the well-known VirusTotal (VT), which leaks everything to enemies (logically - this is its job), to supposedly shadow checkers that do not leak anything (avcheck, scanmaybin and dincheck).
The logic of the work is simple - you upload a file, mark the AVs that interest you with checkboxes. Click the button and wait for the results of the check. The dincheck service (the only one) also has the ability to check for runtime - you can configure the parameters and check how your file will behave when launched.
The most important remark #1 – 90% of services do not deal with runtime. Why? More on that later.
The most important remark #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 it can be checked automatically only on dincheck, and this is quite expensive (3.5 bucks one-time or a subscription from 50 dollars per week).
The most important remark #3 – I can’t confirm, but it seems that avchek is leaking information “to the left”. The files were dying too quickly. I haven’t noticed anything like that with dynchek.
Checking the quality of the crypt – step two
Attention! ALL checkers on AV are a global scam and the fraud of the century
Comrade, before you run with your tongue hanging out to check your crypt on the same dincheck, read this article, especially the current paragraph and your world will turn upside down.
So, I will not beat around the bush. If you have already visited forums specializing in certain services a la crypt file, then you could notice that everywhere the measure of success is zero detections on scantime through dincheck (usually everyone uses it). Someone calls it FUD=0, someone else, but the essence is simple - the file is checked somewhere and with an important look they show you a link like "here, by zeros, get it and sign for it."
Software creators usually show runtime statistics a la: "We have only N detections, everything is cool and awesome."
And the whole point is that the data that the checkers show is INCORRECT!
The most important remark #4 – I don’t know why this is so, I won’t lie. Because I haven’t studied how checkers are structured and what algorithms they work on. At least if there are detections, then checkers are truthful with a probability of 80-90%. But otherwise, they critically diverge from what is in reality.
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 checkers showed that the file was clean.
"What the hell?" I thought, and we decided to delve deeper into this issue.
15 machines were created on WIN 10, on which 15 official antiviruses were installed.
We tried most of the well-known public and semi-public crypto services and tested it in live conditions. Live conditions. By 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 checking
Once again. In eight cases out of 10, where the checkers showed that everything was clean, in reality there was a detection! Especially on top antiviruses like Avast, Noda, Eset and others.
Since I can already feel that the readers' asses and hands are starting to burn, ready to type angry messages about "their personal 90% knockback", I will immediately make certain adjustments.
Let me give you an example.
Gentlemen, I made a cryptic file from my own file. It loads, my dear, everything is fine and dandy with it. I decided to download it from my native machine. Well, so what? A really extra check wouldn't hurt. And I have AVAST on my native machine, such a dog, it doesn't miss a single nasty thing. And then, gentlemen, I download the file, and the bastard, it, is detected! Well, I'm no fool, I quickly do a scantime check again - everything is clean, damn it!
What a dog! I took a couple of dedicated servers on the ten, installed AVAST there, killed, gentlemen, half a day. I download - detections! Detections, damn it! And the checker shows that everything is clean!
What I mean is, 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 persistently getting a sign about the presence of crap in the file - what are your conclusions? Who is right - the checker or your personal observations? I will leave the question open.
Still do not agree with me? Then read on, I will consider this question additionally in the section "How do they all work then, with such detections?"
Checking the quality of the crypt – 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 (top 10 antiviruses can easily provide 90% coverage) and personally check the crypto build for detections. Yes, manually. 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 for you!
Similarly, check the runtime. And you will be able to see the real picture of the world, and then calculate the approximate losses when printing a file.
And finally - no one prevents you from using checkers for an indirect assessment of the "standard of living of a crypto". And if after loading in the dincheck, detections began to appear, then with a probability of 80-90% this is true.
The most important remark #5 – Why do cryptographers ignore so many obvious data discrepancies? My opinion is that checking in this way is 1) too tedious; 2) impossible to prove to the client. Because there is also the opposite situation, when a clean file on live machines, for some reason, is strongly shown on the dincheck as infected. It is impossible to prove this to the client, and who needs it?
The most important remark #6 – From a technical point of view, making a clean scantime based on the indicators of LIVE machines is no more difficult than making a clean scantime for dincheck. But in this case, the lack of understanding of clients leads to the fact that it is easier for cryptocurrencies to feed false data about detections. And everyone is happy.
What is the difference between scantime and runtime?
In this block I immediately answer 2 specific questions:
What is the process of file encryption anyway?
Why don't 99% of cryptocurrencies do raintime?
So. Let's simplify it for speed, otherwise you can easily sit down to write a book here.
To make a crypt, first of all, you need some kind of "cryptographic module". Which is bought or made from scratch. Then, based on this module, a stub is created (I'm simplifying the explanation as best I can without unnecessary theory). Well, then you can put any monkey who will press the button, and get a ready file.
Therefore, if you meet a support who has no clue about the topic and yells obscenities about how stupid everyone is - then the monkey has been detected. The person was simply put to press a button and that's it. He won't help you in any way anymore.
The most important remark #7 – Of course, the resulting stabilizer will gradually fail and will have to be cleaned, upgraded and adjusted to the changing environment. Which is not the easiest task.
Now, attention!
All of the above is true ONLY for scantime. Because there are no modules that would allow automatic encryption of files under runtime due to the difference in the... let's call it that... technological nature of the process. And it turns out that cleaning runtime is strictly manual and painstaking work.
The most important remark #8 – Given the labor intensity and average price for crypto on the market (20-50 bucks), there is no point in services cleaning runtime. The logical question on the topic: “Why the hell do you need a clean scantime if there are 100500 detections in runtime?” will be moved to the next topic.
What is runtime?
Let's repeat ourselves. Runtime is when you launch a file, the antivirus scans it and makes sure that the process is not dangerous. Meanwhile, the file does its dirty deeds. Based on this alone, we can see that the process of cleaning runtime is much more complicated than making a 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 crypto on scantime. Again, the purity of runtime largely depends on the purity of the build that the creator of your software is doing. Runtime comes in two types - static detect and dynamic detect.
Crypt on scantime and runtime are completely different operations, lying in completely different areas! And they do not intersect with each other in any way.
Conventionally, crypto on runtime is done like this:
The algorithms of the AV operation are studied
Scanning methods are being studied
Weak spots in scanning are found
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 a file is launched, roughly speaking, "primary processing" of the data is carried out according to the algorithms installed in the AV. The cryptographer's task is to identify them and bypass them. Then the file will most likely be sent to the office for an in-depth examination. And then your crypt will die and everything will have to be started from the beginning. This is exactly the window you need to work in. For a unique, high-quality crypt, it can stretch out for many days.
The most important remark #9 – This is why the cleanliness of the basic software build becomes a critical problem. Because cleaning a file with the source code is a million times easier than cleaning a ready-made build and removing runtime detections
The most important remark #10 - Despite this, it is quite possible to remove 3-5 detections per runtime. Depends on which AV is being detected. With a relatively clean build and a skilled cryptor, you can bring the real runtime indicator to 1-3
Why 95% of crypto services on the market are useless dummy. 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 readings (avcheck/dincheck/scanmaybin) and the real data. The difference can be so critical (especially if the stab is old and hasn't been updated for a long time) that the meaning of the crypto as a crypto disappears altogether.
Lack of crypto for runtime. If the build itself already stinks like a rotten egg and real runtime detections have gone well beyond 6-7, then what's the point of even a perfectly clean scantime crypto? The most popular 7-8 ABs make up about 80-90% of global usage.
And of course, few people will use an expensive unique stub (which hardly anyone will make), which generally reduces the use of crypto to zero.
The most important remark #11 - Again, there are quite adequate services that make crypto for scantime using the same method as I described. They take machines, put AB there and check manually - whether it is detected or not. Unfortunately, such services rarely go public, due to the problems I mentioned earlier. No one wants to explain to stupid monkeys why checkers should not be trusted.
How to identify services/specialists that you shouldn’t work with?
When asked about runtime, they either go into a stupor or say that it is not their problem - an adequate service will explain that they do not deal with this and the software creator should monitor the purity of the runtime. A cool service will clean the runtime with an adequately clean build.
He spits venom when reading this article and says that it is all a lie and untruth.
When asked "Why is such a supposedly clean crypt exposed on a live machine?" he starts to behave inappropriately and sprays shit.
A logical question is why do installations happen at all and why do people work with them? Some are even quite successful.
This is a good question and I think it is absolutely necessary to analyze it!
First of all, let's define a critical nuance. Do you get installs from your traffic or buy them?
In the first case, you will hear a common story on the topic: "It is useless to pour traffic to an exe file, no one downloads it, everything is crap, it is already the last century." Or you will hear many sad stories about low conversion. Or you will hear how hard it is to pour files, because "the conversion is not pleasing." This is logical - such a crypt will cut almost the entire conversion by 5-10 times. Believe me, a good landing for porn traffic will give 10-15% 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 and running.
When buying installs, the picture is different. First of all, most of the traffic there is motivated. And schoolchildren will spit on all the alerts of AV and actively install software in the hope of cheats from CS or GTA. Otherwise, there is the so-called "systematic survivorship bias".
Important note #12 - Look at the screenshot of your installations' desktop. You will see that most machines are either not protected at all or have AV of unknown origin. You will very rarely see logs with such AV as ESET, Avira, Commodo, Avast, etc.
Key Note #13 – While you’re working, if you honestly think your crypt is good, you’ve probably already fallen into survivorship bias. Google it, dig into it. Maybe it’ll help you look at the “picture of the world” from a different angle.
The difference between "unique" and "public" stub
As I already wrote, the current crypto from the point of view of schoolchildren and other scum, except that it does not cure cancer in the last stage. And also gives enlightenment and generates bitcoins every day. Cryptographers are shocked by such claims, and the public market is deprived of the last adequate professionals
. First of all, "unique stub" is implied by the fact that it is made individually for the software you need. For those who have not yet understood: module - stub - crypto. Thus, if we assume that the cryptographer "created" a unique stub for a specific client, based on the indicators of "live machines" and reduced it to FUD = 0 by scantime. Then you can take the build, shove it into an archive under a password, keep it on the cloud for a week, then get it out, check it and there will still be FUD = 0
Important Note #14 – Don't forget that live AB check kills crypto. This method is ONLY used to check the quality of the crypto service, not to constantly check the crypto build.
In turn, the public "stab" is made on the principle - one for all. And the lifespan of such a crypt is extremely limited. Therefore, it is usually made immediately before the spill and they hope that it will not die in 5 minutes.
The most important remark #15 – This is a completely adequate option for those who buy installations and are confident in the speed of the spill. The lifespan of the public stub is random.
Well, you have to understand that a quality unique stab for your software usually has a price tag for renting a month for an unlimited crypto file. Because no one cares how many times you are going to use it. The price is from 1K and up.
Loading file in browser
This is where your file's earthly path begins. Ideally, it should be without alerts like - file is dangerous, file is potentially dangerous, file is rarely downloaded, file is blocked. Otherwise, you can forget about 99% of the knock.
First of all, you need to understand two basic things:
Loading of the file itself in the browser does NOT DEPEND on the crypt! The opposite is also true - even the best crypt will not help loading! Because these are different things. Completely different.
Checking a file with a browser and an antivirus are two different checks.
The most important note #16 – Once again. First, when you download a file, the file is checked by the browser (especially when the file is downloading and the download icon is blinking and spinning). Then, after downloading, the file is checked 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 reveal the ways to solve it.
As a bonus, Google is also not standing still and is constantly introducing new conditions. In general, to solve the problem, you need to have at least:
A specific signature
Certificate
Crypt (well, that's logic - because it's better not to google a clean build)
Clean IP of 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 cryptographer with straight hands can help with this problem, but usually does not want to. Why? Thanks to schoolchildren who began to demand this almost with complaints and hysterics.
The most important note #17 – crypt is crypt. Load is load. Don’t mix everything together. Each task requires a separate solution.
Smartscreen
The last line of defense of Windows. A headache for logon users. 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 into account files without a trusted certificate.
What is the reality?
In fact, the smartscreen works like a drug addict on a mixture of DMT, LSD and fly agarics. Blocks good files, lets through bad ones. Doesn't pay attention to untrusted files and swears at files with a valid signature. And completely randomly.
What's the problem?
On average, about 30% of machines have a sign from the smartscreen "do you want to install the file? Signature could not be verified." The envelope is usually so cutting ...
How to bypass?
Alas and ah, there are no guaranteed bypass methods. An ordinary valid certificate does not solve the problem completely. As practice has shown, the use of a valid certificate, which are sold for 200-300 bucks, reduces the appearance of the window by about 1.5-2 times. Is it worth the money? Everyone decides for themselves.
The most important remark #18 – There are situations when the smartscreen does not allow a file 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 will not help, you can not try. It is officially believed that the developer's license of the extended sample helps. And there are also situations when a file without a certificate and signature opens without questions. Some AV, when opening a file, act exactly according to this scheme, even if it is crystal clear.
How to solve the problem?
Again, either just put up with it or use a valid certificate. You can try to buy it yourself - this will significantly save money. Komodo costs only 80-90 dollars. Go for it.
Pricing policy
I will just give my own thoughts on this matter, based again on personal experience. Maybe it will help someone.
Price for public crypt (scantime): 10-70$ In principle, the price depends on the algorithm used and the purity of the scantime. Buying a crypt for 10 dollars, you get the corresponding quality. More expensive crypt - better quality. As practice shows, there are still cryptographers who make normal and adequate public crypt.
In general, there is a golden right - a crypt for 10-15 bucks is not a crypt, but a useless imitation.
Also check, for many, the price of a crypt (which cost 30-50$) may include help with loading. At least it used to be, until Google tightened all the screws completely.
Price for a unique crypt (scantime + runtime): here you need to understand 2 options of the situation. First of all, a cryptor who can make a unique stub can also clean the runtime. But this does not apply to the crypt! Once again: runtime has nothing to do with the crypt! And the service will most likely have to be provided jointly. Usually, a one-time crypt for a unique stub costs about $100-$150 + runtime cleaning. Monthly rent of a unique stub for yourself costs 1-2K.
The most important remark #19 – the price of a unique stab is based on labor costs. Who do you think would buy you a very expensive module, then create a stab, debug it, clean it, and all for the sake of selling you crypto for $40-50? There are no idiots. If you think there are, then most likely you are the idiot here.
The most important note #20 - if you are offered a unique stab for too cheap money, then this is a common scam. Do not fall for the scammers' bait. Crypto is either cheap and simple. Or expensive and complex. There is practically no middle ground here.
Price for help with loading: By today's standards, $20-50, considering that preparing a file is not the fastest thing, is basically an adequate price. Another thing is that this task is boring in the sense that it is not worth the money. On the other hand, you can always come to an agreement. An extra coin never hurt anyone.
What to do as a result?
I am correcting myself and offering as many as 2 options to choose from:
1) Stock up on money, popcorn and go look for all the cryptors on the market. Make a list. Specify what he uses to check scantime. We ourselves must check the crypto on live machines. If there are no discrepancies, congratulations! If there are, we try to agree and provide evidence. If they didn't tell you to fuck off, congratulations! If they did, we keep looking.
The most important remark #21 – digging in shit usually always gives results! Don’t give up. Adequate cryptors exist, you just need to find them.
2) We are looking for a partner-technician who understands the basics of this whole mess. Well, or who has the skills to figure it out. I assure you, there are many good and smart guys who also sit on forums and are looking for an opportunity to join or create a team.
The most important remark #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 to do anything and don’t have anything, then exactly the same trash will stick to you. Do you need it?
leaving a like is much appreciated and help me to keep publishing threads.
![[Image: Nuttela-Signature.gif]](https://i.ibb.co/VT79K5v/Nuttela-Signature.gif)
![[Image: Sig.png]](https://i.ibb.co/xh4Mcd3/Sig.png)
