[donovanranda]

github.com/lurumdare/Lycosidae

Bypass ScyllaHide

Features
- Import no leak
- Strings no leak

[Paskowsky]

github.com/lurumdare/Lycosidae

Bypass ScyllaHide

Features
- Import no leak
- Strings no leak

Working link : https://github.com/lurumdare/Lycosidae

I dont know if this is your code, but it's not bad. I've looked at source code and basically you are restoring hooked functions from scyllahide that is "new" and all the functions you call are called by hash which is something malwares and or shellcodes do since 1999 🤣  🤣 .

However a reverser looking at code will notice, maybe not on first run, that his plugin isn't working and just patch the code so crc check to compare functions always returns true.
That's a solution that crossed my mind just now.

A layer of obfuscation would decrease probabilities of this happening so it's still a good release  🤝

Regards,
Paskowsky  🤝

[SKIDROOTKIT]

This won't do anything. You can easily work on this.

[donovanranda]

I dont know if this is your code, but it's not bad. I've looked at source code and basically you are restoring hooked functions from scyllahide that is "new" and all the functions you call are called by hash which is something malwares and or shellcodes do since 1999 🤣  🤣 .

However a reverser looking at code will notice, maybe not on first run, that his plugin isn't working and just patch the code so crc check to compare functions always returns true.
That's a solution that crossed my mind just now.

A layer of obfuscation would decrease probabilities of this happening so it's still a good release  🤝

Regards,
Paskowsky  🤝

Yes. It is my code.

Read VM_Manul.md


if you add virtualization,
it will be hard for the reverser

[dracx]

Yes. It is my code.

Read VM_Manul.md


if you add virtualization,
it will be hard for the reverser

may I ask how would virtualization help?

[SKIDROOTKIT]

may I ask how would virtualization help?

It's just a layer of obscurity. Any decent reverse engineer should be able to reverse virtual handlers that lead to the devirtualization of vm opcodes.

[binbus]

It's just a layer of obscurity. Any decent reverse engineer should be able to reverse virtual handlers that lead to the devirtualization of vm opcodes.

Then why have you never done it?

[SKIDROOTKIT]

Then why have you never done it?

Wdym? This is a general thing. Reversing a virtualization system isn't difficult in theory. The only thing that stands in its way is more obscurity.. obfuscation, encryption, etc.

[smutnagab]

Then why have you never done it?

There's no need to get emotional and attack him out of the blue, he's just stating facts. I don't see how what he has said is "offensive" and justifies the response you gave him. The point of a forum like HackForums is to share knowledge!

A layer of virtualisation would merely be more obscurity which results in more work for the reverse-engineer in order to get the information they desire, but if the reverse-engineer is skilled and determined enough, they will inevitably get through it all.

If the virtualisation is custom for each use-case (e.g. different virtual operation codes being translated with changes in the algorithms for the conversion, etc.) then it can be tiresome and ware the reverse-engineer out if they have to reverse-engineer many binaries apart of the same software package using a virtualisation layer, but even this would still be trivial if they were skilled and determined enough to get the task at hand completed. It would merely take them more time to get the information they desire to extract from the software.

[binbus]

Wdym? This is a general thing. Reversing a virtualization system isn't difficult in theory. The only thing that stands in its way is more obscurity.. obfuscation, encryption, etc.

Do it then

Skid

[warn]

[vertox]

Do it then

Skid

[warn]

don't rek me now bro

[donovanranda]

add few checks
check project on github