Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add detection support for newer versions of VMProtect. #734

Merged
merged 3 commits into from
Apr 14, 2020

Conversation

tamaroth
Copy link
Contributor

@tamaroth tamaroth commented Apr 8, 2020

Since version 2.04, every protected file has a public signature (detected with a YARA rule) and
the checksum of the first 64 DWORDS in the last executable section is always constant despite the
bytes in that part being different.

In addition, the tests were added here

@s3rvac s3rvac self-requested a review April 9, 2020 04:33
@s3rvac s3rvac self-assigned this Apr 9, 2020
@s3rvac
Copy link
Member

s3rvac commented Apr 9, 2020

Let's run TeamCity tests.

Copy link
Member

@s3rvac s3rvac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the added support of newer versions of VMProtect! Could you please take a look at the failing tests? The code looks good, but there is something that prevents two tests from passing.

@s3rvac
Copy link
Member

s3rvac commented Apr 9, 2020

Let's run TeamCity tests.

@s3rvac s3rvac removed the request for review from PeterMatula April 9, 2020 10:56
Since version 2.04, every protected file has a public signature (detected with a YARA rule) and
the checksum of first 64 DWORDS in the last executable section is always constant despite the
bytes in that part being different.
@tamaroth tamaroth force-pushed the improvement-vmprotect-detection branch from 10619fa to ec1cc47 Compare April 9, 2020 12:53
@s3rvac
Copy link
Member

s3rvac commented Apr 9, 2020

Let's run TeamCity tests.

@s3rvac
Copy link
Member

s3rvac commented Apr 9, 2020

That macOS fail is caused by #702 (not by the present PR). However, the Linux build is unfortunately still failing. I will try to debug it. There is either another bug, or the build did not run with the fix, or there is something else going on.

@s3rvac
Copy link
Member

s3rvac commented Apr 9, 2020

The build has run for ec1cc47, which is currently the latest commit in this PR. So, the build has run with the fix.

@s3rvac
Copy link
Member

s3rvac commented Apr 9, 2020

I am able to reproduce the issue when using this Dockerfile. However, I was not yet able to determine the exact cause as when I start debugging the issue, the problems seem to go away. I will investigate it further. I just wanted to let you know about the progress.

…mber().

It read bytes from the given offset as a number of the given type.
…e of SecSeg::getBytesAtOffsetAsNumber().

This makes the code a bit more readable as we do not have to retrieve and
operate with the bytes (we just use SecSeg::getBytesAtOffsetAsNumber() for
that).
@s3rvac
Copy link
Member

s3rvac commented Apr 10, 2020

Let's run TeamCity tests.

@s3rvac
Copy link
Member

s3rvac commented Apr 10, 2020

Alright, so, even after about 6 hours of debugging, I was unable to determine the real cause. Here is a couple of notes:

  • retdec-fileinfo was crashing due to the changes in PeHeuristics::getVmProtectHeuristics() in this PR. Here is a backtrace from gdb:
    #0  0x00005555558618b8 in retdec::cpdetect::PeHeuristics::getVmProtectHeuristics() ()
    #1  0x000055555586f531 in retdec::cpdetect::PeHeuristics::getFormatSpecificCompilerHeuristics() ()
    #2  0x000055555583ec12 in retdec::cpdetect::CompilerDetector::getAllCompilers() ()
    #3  0x000055555584050b in retdec::cpdetect::CompilerDetector::getAllInformation() ()
    #4  0x0000555555666ee1 in retdec::fileinfo::FileDetector::getCompilerInformation() ()
    #5  0x00005555556677ac in retdec::fileinfo::FileDetector::getAllInformation() ()
    #6  0x0000555555614bc0 in main ()
    
    Line information is not available as the crashes are only reproducible in a release build.
  • The crash was only reproducible with GCC 7 in Ubuntu (this is what the Linux TC agent runs). I was able to reproduce it by using this Dockerfile.
  • The crash was only reproducible with the Release build type. If I tried a different build type (even RelWithDebInfo), it stopped crashing.
  • I have tried upgrading GCC 7 from 7.4.0 to 7.5.0, but to no avail (it did not fixed the crashing).
  • valgrind did not report any errors apart from retdec-fileinfo crashing with the backtrace above. I have tried several different build types with several different compilers.
  • When I tried to debug the code by manually inserting debug prints, the crashing stopped. The crashing also stopped when I modified the computing of the checksum.
  • The crash appeared to happen on the following line:
    checksum += *reinterpret_cast<const std::uint32_t*>(&data[i * 4]);
    However, when I simply printed the obtained integers, the code worked without any issues.
  • The memory returned by section->getBytes() and stored in data seemed to be valid.

I do not know how to debug this further. I believe this to be a compiler bug. I would really like to know this for sure, but I do not have the time nor will to debug it further.

Nevertheless, I was able to modify the code so it is more readable and the Linux TC build no longer fails. @tamaroth: If the current code is OK from your point of view, we can merge the PR as all the tests pass now.

@tamaroth
Copy link
Contributor Author

Thank you for your thorough investigation. If it crashed only on a specific version and only when placed directly in the checksum computing loop, perhaps there was a bug in optimisation? Hard to tell.

Again, thank you for your code review and updated code, it will be useful in the future.

The code looks good to me! 👍

@s3rvac s3rvac merged commit 9f36fb2 into master Apr 14, 2020
@s3rvac s3rvac deleted the improvement-vmprotect-detection branch April 14, 2020 09:08
s3rvac added a commit that referenced this pull request Apr 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants