ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

The Frankenstein virus

Updated on September 3, 2012

It's Alive! It's ALIVE!

Ok. Enough of the drama.

Historically, computer viruses have been written with a single block of code and then launched into the internet. The code seeks to replicate itself and thus spread like a biological virus, and also to deliver a payload into each victim. This block of code did not change, and therefore to detect it, all you need to do is read enough bytes from the code and compare that signature with a list of known signatures. If you find a match, then the virus is blocked. It is simple and fast to create a signature and the virus signature does not change when it replicates.

Encrypted viruses

In another chapter in the arms-race between virus writers and detection techniques, we find the encrypted virus. At the most fundamental level, encryption is simply a scrambling of previously ordered and meaningful patterns like taking a deck of cards, throwing them in the air and collecting them up again in a new order. If you were to do that using a repeatable method rather than a pure random act like throwing them in the air, and if that method produced a result that looks just as random, then you have a potential encryption algorithm. The great difference between having a method and using pure random operations is that the method permits a way to unscramble the jumble and put it back to the original order. The unscrambling is enabled by knowledge of a key. If the key is essential to the unscrambling, and you can keep the key secret, then you have a decent example of an encryption algorithm. (Whether it is any good or not is another question.)

Providing you can get the key and use the same unscrambling method, then the original data (or code in this case) is recoverable.

In this system, the virus obscures its signature by using a key and a decryptor to mask the signature. It changes the key every time it replicates so there is never the same signature on any two computers.

Although the body (payload) of the virus and the signature changes each time, the decryption method remains constant and virus detection can concentrate on finding known decryption methods instead.

Polymorphic viruses

In response to the ability of virus detection methods to identify decryptor routines, There are now polymorphic viruses which try to avoid detection by deliberately changing in subtle ways to alter the decryptor signature and yet still function as required. Virus detection of polymorphic viruses is of course much harder but there are certain characteristics of polymorphic code that can be detected. It can take days to months to generate a detection method for a polymorphic virus.

In the case of polymorphic virus detection, the focus is on specific sequences of operation that are characteristic of the various mutation engines use to scramble the decryptor. This is not an easy task because there are many billions of variations.

So the anti-virus researches have turned to ways to trick the encrypting polymorphic virus into decrypting itself in an environment that is controlled and will not infect the host. Once it has been revealed, detection is easy.

On the downside, this controlled environment is often a fairly sophisticated simulation of a real machine and therefore can be a rather slow method of detection.


Heuristics are like "rules of thumb" or a collection of educated guesses. Some problems in computing science are provably known to be impossible to solve in a reasonable time, but the application of heuristics can sometimes make it practical to get very close to a certain solution in a reasonable time.

Anti virus techniques can also use heuristics to make a judgement on a possible virus to see if it is worth applying a more detailed analysis.

As an example of a heuristic rule, consider the following code snip:


	c = a * b;

The code defines two values and multiplies them together. It looks like proper code but a functional program would not use code like this because the resulting value c is not used. It is simply ignored. In fact, a good optimising compiler would warn the programmer and omit this code from the compiled result. A polymorphic virus however might use this kind of trick to mutate a decryptor without altering the real function of the decryptor.

If a polymorphic heuristic detection engine sees this kind of illogical behaviour, then it increases a counter that raises suspicion. If several of these anomalies are detected, then at some threshold, the AV engine will declare the code to be a virus.

But this is a moving target. As more virus mutation engines are created, new heuristics are needed and as more heuristics are applied, more time is needed for analysis. Over time, the modern viruses might be using some techniques that are not detected. The AV engine could eventually be applying hundreds of old heuristics. It's a waste of time to use heuristics that are no longer applicable and it's not scalable to just keep adding heuristics. Cleaning this mess up becomes a difficult task.

To overcome this ballooning bloat with typical heuristic engines, companies like Symantec have found a way to be more selective based on polymorphic profiles (Lookup Symantec Striker for details.)

The Frankenstein Virus

The Frankenstein Virus has been realised as a proof of concept and as far as is known (or admitted) there are no live examples of this today.

The idea is that the resulting virus is stitched together from existing, functional and legitimate segments of code that are already found on the target host. If this is the case, then the resulting code could evade heuristic detection because each segment of code is not only benign, but consists of nothing that makes it stand out. However the code itself as a whole would be capable of delivering a payload.

Instead of sending a fully functional virus from computer to computer, the Frankenstein virus would be more like a set of specifications or a recipe or set of goals on how to build a certain algorithm. It would therefore be constructed differently on each computer and would not be easily distinguishable from any other legitimate code.

The code that locates useful sections of legitimate code is being called the 'gadget finder'. For any particular goal, there could be many individual gadgets that could perform the task and this is what provides diversity in the assembled virus.

If the blueprint and gadget-finder is unexceptional as far as the heuristic detection engine is concerned, then a Frankenstein virus would present new challenges for anti-virus software.


There are a few comments bouncing through cyberspace about this proposal. Here are some, and my thoughts.

  • Gadgets? You don't know what you are talking about. These would be libraries or Frameworks that would have to be linked and modified to avoid name clashes.

I don't see that this is a requirement. Just to find any sequence of code that does something useful could be a gadget. This sequence of code could be a small portion of a library.

  • It's AIDS for your computer!

Yes - not a bad analogy there. Although it's not specifically using AV code as part of its function, it could happen to use a little bit and that would mirror the fact that HIV is an auto-immune disease.

  • This is not new. AV companies can't keep up with mutating viruses today, and this is just more of what we already know.

As explained above, this is more than what we already know because of the possibility to evade anomaly detection using heuristics. If some heuristics still apply, then they are likely to be more complex and therefore take longer to run.

Should I be worried?

There is likely to be a lot of hype about this in the coming days or weeks. I think it might die down fairly quickly, but keep an eye out for this and similar techniques. We really are in an arms-race with cyber-criminals. Some think they have and will always have the upper hand, and yet I've me some prominent people who thinks it's getting more difficult for the virus writers.

Just as every encryption system is breakable, every virus is detectable. The real question is "Who gets the upper hand at any given time?"


    0 of 8192 characters used
    Post Comment

    • Austinstar profile image


      6 years ago from Somewhere near the center of Texas

      I wish I could understand more of this, but I'm happy that there are programmers out there, like you, that know how to detect and destroy viruses. I hope they pay you the big bucks!


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)