Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Security Apps
Emsisoft
What's good about Emsisoft?
Message
<blockquote data-quote="Fabian Wosar" data-source="post: 841238" data-attributes="member: 24327"><p>Scripts are generally not high-entropy because they are text. It's difficult to create a high-entropy text file. The entire idea of AMSI in general is, that you don't have to deal with obfuscation or encryption at all, because every function that can evaluate scripts (think eval() in JavaScript/Python or IEX in PowerShell for example) will first pass the string they are about to evaluate/execute to AMSI for scanning.</p><p></p><p>Your questions kind of suggest that you may have not a clear idea what AMSI is. AMSI is just a standardised API that any interpreter can use to pass either a memory buffer (think the content of a file for example) or a string (think a line of script that is about to be interpreted) to an installed AV in a standardised manner. So instead of Python, for example, having to maintain different code to support scanning with Kaspersky, Windows Defender and Emsisoft for example, they can just use AMSI and whichever AV the user has installed will scan on Python's behalf, provided that the AV actually supports AMSI.</p><p></p><p>The key point to notice here is, that the interpreter has to use AMSI. So it is irrelevant if we "support Python" for example. Because Python's implementation is responsible to show us the code it is about to execute before it executes it. This also does include things like virtual environments and stuff like that. So whenever you do an "import" in Python, for example, Python would read the file you imported, whether from the global installation location or a virtual environment, and pass that as a string or buffer to AMSI to scan it. Whenever a Python script decrypts a string that contains malicious code for example and passes it into eval() to execute the string as Python code, Python is responsible to hand that string that is about to be eval'd over to AMSI so it can be scanned. That should also explain why blocking encrypted/obfuscated/high-entropy scripts as you called them is unnecessary. Because if the interpreter does things right, they will pass us the decrypted and deobfuscated code eventually, no matter how many layers of encryption and obfuscation have been applied. That is ultimately the true power of AMSI here.</p><p></p><p>So any question whether we support Python or node.js or any other scripting language with our AMSI module is kind of backwards. If an interpreter supports AMSI, then we support it as well. There is no extra work that an AMSI provider like EAM would have to take in order to support a certain interpreter specifically.</p><p></p><p></p><p>It's a necessity for us really. We are a small company, we don't want to maintain many products in parallel. In addition, pretty much every one of our employees (except maybe some of the marketing people) is also the personal computer technician for their entire extended family and friends, so they know the pain a lot of people who manage like a couple of family PCs feel. Just didn't feel right to us to lock such useful functionality behind a prohibitive paywall or some "minimum licenses required".</p><p></p><p></p><p>We do detect some anomalies with browsers, but we could probably detect more. The biggest issue is that a lot of these things can't effectively be monitored without injecting code into the browser, which browser vendors do not want you to do (Microsoft blocks it in Edge, Google and Firefox plan to as well). In fact, Chrome will outright tell users to uninstall their AV if they see an AV vendor injecting code into their browser. If the world's number one browser tells their users to uninstall your software and you have a minuscule userbase compared to them, you will have to evaluate whether or not risking your economic livelihood is worth it.</p></blockquote><p></p>
[QUOTE="Fabian Wosar, post: 841238, member: 24327"] Scripts are generally not high-entropy because they are text. It's difficult to create a high-entropy text file. The entire idea of AMSI in general is, that you don't have to deal with obfuscation or encryption at all, because every function that can evaluate scripts (think eval() in JavaScript/Python or IEX in PowerShell for example) will first pass the string they are about to evaluate/execute to AMSI for scanning. Your questions kind of suggest that you may have not a clear idea what AMSI is. AMSI is just a standardised API that any interpreter can use to pass either a memory buffer (think the content of a file for example) or a string (think a line of script that is about to be interpreted) to an installed AV in a standardised manner. So instead of Python, for example, having to maintain different code to support scanning with Kaspersky, Windows Defender and Emsisoft for example, they can just use AMSI and whichever AV the user has installed will scan on Python's behalf, provided that the AV actually supports AMSI. The key point to notice here is, that the interpreter has to use AMSI. So it is irrelevant if we "support Python" for example. Because Python's implementation is responsible to show us the code it is about to execute before it executes it. This also does include things like virtual environments and stuff like that. So whenever you do an "import" in Python, for example, Python would read the file you imported, whether from the global installation location or a virtual environment, and pass that as a string or buffer to AMSI to scan it. Whenever a Python script decrypts a string that contains malicious code for example and passes it into eval() to execute the string as Python code, Python is responsible to hand that string that is about to be eval'd over to AMSI so it can be scanned. That should also explain why blocking encrypted/obfuscated/high-entropy scripts as you called them is unnecessary. Because if the interpreter does things right, they will pass us the decrypted and deobfuscated code eventually, no matter how many layers of encryption and obfuscation have been applied. That is ultimately the true power of AMSI here. So any question whether we support Python or node.js or any other scripting language with our AMSI module is kind of backwards. If an interpreter supports AMSI, then we support it as well. There is no extra work that an AMSI provider like EAM would have to take in order to support a certain interpreter specifically. It's a necessity for us really. We are a small company, we don't want to maintain many products in parallel. In addition, pretty much every one of our employees (except maybe some of the marketing people) is also the personal computer technician for their entire extended family and friends, so they know the pain a lot of people who manage like a couple of family PCs feel. Just didn't feel right to us to lock such useful functionality behind a prohibitive paywall or some "minimum licenses required". We do detect some anomalies with browsers, but we could probably detect more. The biggest issue is that a lot of these things can't effectively be monitored without injecting code into the browser, which browser vendors do not want you to do (Microsoft blocks it in Edge, Google and Firefox plan to as well). In fact, Chrome will outright tell users to uninstall their AV if they see an AV vendor injecting code into their browser. If the world's number one browser tells their users to uninstall your software and you have a minuscule userbase compared to them, you will have to evaluate whether or not risking your economic livelihood is worth it. [/QUOTE]
Insert quotes…
Verification
Post reply
Top