Skip to content

Commit 7051eb0

Browse files
committed
small README changes
1 parent e5e293b commit 7051eb0

1 file changed

Lines changed: 6 additions & 4 deletions

File tree

README.md

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -180,10 +180,11 @@ You can view the full docs [here](docs/documentation.md). All the details such a
180180
<br>
181181

182182
> There's already loads of projects that have the same goal such as
183-
<a href="https://github.com/CheckPointSW/InviZzzible">InviZzzible</a>, <a href="https://github.com/a0rtega/pafish">pafish</a> and <a href="https://github.com/LordNoteworthy/al-khaser">Al-Khaser</a>. But the difference between the aforementioned projects is that they don't provide a programmable interface to interact with the detection mechanisms, on top of having little to no support for non-Windows systems.
184-
> Pafish and InviZzzible have been abandoned for years, while Al-Khaser does receive updates and has a wide scope of detection that includes anti-debuggers, anti-injection, and so on, but the VM detections are not sophisticated enough to be practically applied to real-world scenarios while not providing enough VM detection techniques. An additional issue is that they are all GPL projects.
183+
<a href="https://github.com/CheckPointSW/InviZzzible">InviZzzible</a>, <a href="https://github.com/a0rtega/pafish">pafish</a> and <a href="https://github.com/LordNoteworthy/al-khaser">Al-Khaser</a>. But the difference between the aforementioned projects is that they don't provide a programmable interface to interact with the detection mechanisms, on top of having little to no support for non-Windows systems. Additionally, the VM detections in all those projects are often not sophisticated enough to be practically applied to real-world scenarios while not providing enough VM detection techniques. An additional issue is that they are all GPL projects.
184+
>
185+
> Pafish and InviZzzible have been abandoned for years. Although Al-Khaser **DOES** receive occasional updates and has a wide scope of detection that VMAware doesn't provide (anti-debugging, anti-injection, and so on), it still falls short due to the previously mentioned problems above.
185186
>
186-
> I wanted the core detection techniques to be accessible programmatically in a cross-platform way for everybody to get something useful out of it rather than providing just a CLI tool. It also contains a larger quantity of techniques, so it's basically just a VM detection framework on steroids with maximum flexibility.
187+
> While those projects have been useful to VMAware, we wanted to make them far better. My goal was to make the detection techniques to be accessible programmatically in a cross-platform and flexible way for everybody to get something useful out of it rather than providing just a CLI tool. It also contains a larger quantity of techniques, so it's basically just a VM detection framework on steroids that focuses on practical and realistic real-world usability.
187188
188189
</details>
189190

@@ -200,7 +201,7 @@ You can view the full docs [here](docs/documentation.md). All the details such a
200201
<summary>Wouldn't it make it inferior for having it open source?</summary>
201202
<br>
202203

203-
> The only downside to VMAware is that it's fully open source, which makes the job of bypassers easier compared to having it closed source. However, I'd argue that's a worthy tradeoff by having as many VM detection techniques in an open and interactive way rather than trying to obfuscate it. Having it open source means we can have valuable community feedback to strengthen the library more effectively and accurately through discussions, collaborations, and competition against anti-anti-vm projects and malware analysis tools which try to hide it's a VM. All of this combined further advances the forefront innovations in the field of VM detections much more productively, compared to having it closed source.
204+
> The only downside to VMAware is that it's fully open source, which makes the job of bypassers easier compared to having it closed source. However, I'd argue that's a worthy tradeoff by having as many VM detection techniques in an open and interactive way rather than trying to obfuscate it. Having it open source means we can have valuable community feedback to strengthen the library more effectively and accurately through discussions, collaborations, and competition against anti-anti-vm projects and malware analysis tools which try to hide it's a VM. All of this combined has further advanced the forefront innovations in the field of VM detections much more productively, compared to having it closed source.
204205
>
205206
> In other words, it's about quality, feedback, and openness over security through obfuscation.
206207
@@ -289,6 +290,7 @@ And if you found this project useful, a star would be appreciated :)
289290
- [Georgii Gennadev (D00Movenok)](https://github.com/D00Movenok)
290291
- [utoshu](https://github.com/utoshu)
291292
- [Jyd](https://github.com/jyd519)
293+
- [git-eternal](https://github.com/git-eternal)
292294

293295
<br>
294296

0 commit comments

Comments
 (0)