![]() |
#1
|
||||
|
||||
VMProtect Source Code Potentially Leaked
Posted on Twitter by gmhzxy:
https://twitter.com/gmhzxy/status/1563608617169096708 Someone has shared screenshots of the source code to VMP opened within Visual Studio. Possible public leak incoming, but wouldn't be surprised if whoever has it tries to profit via Bitcoin first.
__________________
Personal Projects Site: https://atom0s.com |
The Following 2 Users Say Thank You to atom0s For This Useful Post: | ||
tonyweb (08-28-2022) |
#2
|
||||
|
||||
wait and see
__________________
AKA Solomon/blowfish. |
#3
|
|||
|
|||
https://ieeexplore.ieee.org/document/9139515
I seriously wonder when this tool will get in the hands of public, its gonna be the doomsday for vmpsoft. Can we say that the VMProtect era is coming to an end? |
#4
|
|||
|
|||
I expect nothing, and i'm still let down.
|
#5
|
|||
|
|||
Never gonna happen. At least not this tool.
|
#6
|
|||
|
|||
Quote:
But also how this hybrid mode works. I didn't see the details but I imagine the first execution is emulated and later execution are natively run. But different codepaths leasing to that point could change the unpacked result. Making certain targets likely impossibly slow if you require too much emulation. Further some targets are connected to a server with things like latency monitored e.g. games. Emulation would cause disconnects and make it very difficult in any time sensitive environment. Such a tool is not so difficult to code a prototype of either. So I suspect it won't be easy to go from the academic prototype sufficient for research to state of the art targets. |
#7
|
|||
|
|||
For what it's worth, I haven't found it uploaded to VT either. Presumed someone would upload to VT to make sure it's not "backdoored".
|
#8
|
|||
|
|||
The news was spread on Wednesday, but there is no evidence.
|
#9
|
||||
|
||||
![]()
Potential VMProtect code leak could offer a possibility to easily build something like "MyVMProtect", but not a possibility to quickly develop something like "DeVMProtect".
The reason is very simple: VMProtect contains a code to virtualise, but it contains no code to devirtualise. One could check existing researches about virtual machines and VMProtect to explore existing possibilities to devirtualise VMProtect'ed code. Some tools (like based on VTIL, for example) provide enough details about structure of VM internals, so VMProtect source code will just prove some assumptions and reveal additional details about these VMProtect internals, but basic information is already available in VMProtect research papers and articles, accomplished by source code (see VTIL project and its tools). This means that researchers already have enough information to devirtualise at least some blocks of virtualised code. The only missing thing is a 'one click solution for dummies' to quickly unpack and devirtualise VMProtect. But leakage of actual VMProtect sources, with greater probability, it will lead to the appearance of VMProtect clones rather than appearance of DeVMProtect (VMProtect devirtualiser) for dummies.
__________________
EnJoy! |
The Following 9 Users Say Thank You to Jupiter For This Useful Post: | ||
#10
|
||||
|
||||
can upload please link not working for me.
|
#12
|
||||
|
||||
It's true that the VMP VM is well documented and wont give much insight, i would actually be more interested in obtaining a full list of their normal obfuscation actions ... but would be spectacular in any case.
x64unpack can switch between emulation and native execution, and their results are excellent, including fairly real-world examples. Of course there will always be cases where it doesnt work, + countermeasures. But I have used standard DBI the past for tracing and unpacking, and if done correctly and with some tuning they yield excellent results. |
#13
|
|||
|
|||
https://twitter.com/ESETresearch/status/1594937054303236096
huh |
![]() |
Thread Tools | |
Display Modes | |
|
|