• CheckPoint.com
• 
• 
• 
• 
• 
• 

By: Alexey Bukhteyev and Raman Ladutska

From a simple keylogger to a top prevalent malware

Formbook is currently one of the most prevalent malware. It has been active for more than 5 years already. Check Point reported in December 2020 that Formbook affected 4% of organizations worldwide and made it to the top 3 list of the most prevalent malware.

According to AnyRun Malware Trends Tracker, Formbook occupies the 4^th place in a list of the most prevalent malware families in 2020.

\n

\n

^{Figure 1 – Formbook is in 4th place among the most prevalent malware families of the past 12 months (June 2020 – June 2021) – AnyRun.}

Formbook is an Info Stealer that harvests credentials from various web browsers, collects screenshots, monitors and logs keystrokes, and can download and execute files according to the orders received from Command-and-Control (C&C) servers. The code is written in C with assembly inserts and contains a number of tricks to make it harder for researchers to analyze it.

As stated by its author, Formbook was intended to be “a simple keylogger.”  However, customers immediately saw its potential as a universal tool for use in broad spam campaigns that target organizations all over the world. As this potential became a reality, the author stopped sales of the product without giving detailed explanations about the motives behind this decision.

A short time later, Formbook was reborn as XLoader, and the malware is now available for sale in the underground forum by a different avatar. XLoader opened up several new opportunities, with the ability to operate in the macOS being one of the most exciting. XLoader’s story is on-going, and judging by the popularity of the malware, shows no signs of ending any time soon.

Let’s take a look at how it all began.

Formbook: unintended popularity

A post offering the earliest version of Formbook (what we could call a beta-version) for sale appeared on the underground forum on February 13, 2016.

\n

\n

^{Figure 2 – ng-Coder offering Formbook malware for sale.}

Although the first sales thread appeared on February 13, 2016, Formbook samples were seen earlier as evidenced by AnyRun:

\n

\n

^{Figure 3 – First Formbook sample was seen on January 1, 2016, according to AnyRun.}

The Formbook’s seller was hidden under “ng-Coder” avatar.

Note: we assume ng-Coder is a male, though we have no direct evidence, and will refer to the avatar as “he” throughout this article.

Profile

 e-mail: ng2Coder@gmail.com\n Skype: Ng.Coder\n skills:\n * strong c\\c++ knowledge\n * strong assembly x86\\x64 knowledge 

ng-Coder joined the underground hack forum on October 27, 2015. According to his own statement on the forum, he was selling exploits at that time. We cannot point to ng-Coder’s exact country of origin, but judging by his phrasing, English is likely not his native language.

A day before creating the sales thread we saw above, ng-Coder requested a review of his product from an experienced member of the community.

\n

\n

^{Figure 4 – Formbook review requested by ng-Coder.}

On May 9, 2016, three months later after publishing the first sales thread, Formbook v.0.3 was offered for sale.

\n

\n

^{Figure 5 – Formbook v.0.3 icon.}

Formbook was advertised as a product supporting multiple features:

\n

\n

^{Figure 6 – Formbook v.0.3 features.}

What attracted our attention here is a strange description including the phrase “Balloon Executable” and the acronyms MPIE and MEE. These terms, which do not exist in the cyber community, were used by ng-Coder to describe how Formbook operates, i.e., uses position-independent code (shellcode) to inject the malware into a legitimate system process and initiate the shellcode execution.

Other features listed include network traffic sniffing, keylogging, clipboard monitoring, and password extraction for almost one hundred applications including browsers, messengers, FTP and email clients.

The sales pitch was a combined model, in which a customer could choose where to host the panel: on the host provided by the seller (thus using a “Malware-as-a-Service” scheme) or the customer’s own machine (direct acquiring). If the latter was selected, the author also provided the panel source code along with a pre-built binary.

Different types of Formbook subscriptions had different prices:

\n

\n

^{Figure 7 – The Formbook pricing as offered by ng-Coder.}

ng-Coder offered a number different source code protectors to support Formbook. For example, Net-Protector is a cross-platform crypting service with the price of $100 for a Windows executable and $200 for a macOS one:

\n

\n

^{Figure 8 – Net-Protector logo.}

ng-Coder was so confident in his creation that he offered to re-crypt an executable for free if it was detected by any AV in the first 30 days after the encryption:

\n

If the crypted PE file gets flagged by AV in less than 30 days after the first crypt, we will recrypt the same crypted SHA1 for free.

\n

Other examples of protectors included shared source codes of crypting solutions on .NET and Delphi.

On October 6, 2017, Formbook sales abruptly stopped. The reason given was its use in spam campaigns:

\n

\n

^{Figure 9 – ng-Coder indicates that Formbook sales have ceased.}

As we stated at the beginning of this article, the Formbook author didn’t want his creation to be used in email campaigns and banned all customers who did so.

On May 27, 2018, ng-Coder made his last public post on the forum where he provided a technical answer to one of the questions not related to Formbook. No further activity from him has been observed since.

As we will see, although Formbook sales were stopped, its activity was continuing. Not only could users who bought the malware to be hosted on their own servers continue to use it, but ng-Coder could make use of Formbook as well.

Used for the author’s own purposes?

We found evidence that ng-Coder might have his own plans for his creation. We analyzed the domains linked to the ng-Coder email address “ng2coder@gmail[.com” and discovered that these were used in Formbook configurations for particular campaigns labeled “private”, “list” and “zog”. We found 16 unique C&C URLs inside the Formbook malware that pointed to 13 different sub-campaigns.

 http[://www.unlimitedgiveaways.net/zog/hx/\n http[://www.unlimitedgiveaways.net/zog/hx69/\n http[://www.unlimitedgiveaways.net/zog/ab/\n http[://www.socialbumps.net/zog/ct2/\n  \n http[://www.alienzouks.com/private/\n http[://www.adomax1.com/private/\n http[://www.ryandeby.com/private/\n http[://www.gfather.net/private/\n  \n http[://www.surfpay.website/list/ch/\n http[://www.bingo-clicker.site/list/jo/\n http[://www.click-bingo.site/list/le/\n http[://www.click-bingo.site/list/kv/\n http[://www.click-bingo.site/list/mo/\n http[://www.jesse-list.info/list/kw/\n http[://www.wowtracking.info/list/hx47/\n http[://www.wowtracking.info/list/oz/ 

All the listed domains share common features. They all were registered by the GoDaddy registrar:

\n

\n

^{Figure 10 – GoDaddy registrar appears in domains’ details.}

And they all shared the same details about the person who registered them:

\n

\n

^{Figure 11 – Details for registering domains as provided by ng-Coder.}

According to the LocateFamily site, “Amanda George” was living at the address provided at the time of registering the domains. However, we cannot link this person with ng-Coder avatar.

The Formbook activity didn’t just stop there. For example, in May 2020 we discovered a Formbook sample dropped by GuLoader. It was submitted to VirusTotal in June 2020:

\n

\n

^{Figure 12 – A Formbook sample dropped in May 2020 by GuLoader.}

The campaign name in this sample was “private” and the main domain was registered by ng-Coder (ryandeby[.com).

XLoader: the time-proved tricks re-applied in a new environment

On February 6, 2020 a new era began: the era of the Formbook successor called XLoader. On this day, XLoader was advertised for sale in one of the underground groups.

\n

\n

^{Figure 13 – XLoader as advertised in the underground group.}

Formbook and XLoader share the same code base, and there are other connections between them as well, as we will see later.

\n

\n

^{Figure 14 – The seller confirms that Formbook’s code has contributed a lot to the development of XLoader.}

On October 20, 2020, XLoader was offered for sale on the same forum which was used for selling Formbook.

\n

\n

^{Figure 15 – XLoader as advertised on the forum.}

Note: XLoader malware for PC and Mac should not be confused with XLoader malware for Android, first discovered in 2019.

One of the most exciting things about the new malware was its ability to operate in the macOS. With approximately 200 million users operating macOS in 2018 (as reported by Apple), this is definitely a promising new market for the malware to enter.

\n

\n

^{Figure 16 – Mac sales by year, taken from https://www.businessofapps.com/data/apple-statistics/}

Note: Apple stopped reporting Mac sales in Q4 2018. All subsequent values are estimates.

The malware now features a more lucrative economic model for the authors as compared to Formbook. Customers may only buy the malware for a limited time and are only able to use a server provided by the seller; no panel sources codes are sold anymore. Thus, a “Malware-as-a-Service” scheme is used. Centralized C&C infrastructure allows the authors to control how the malware is used by the customers.

\n

\n

^{Figure 17 – xloader announces the decision to stop selling panels and underlines the importance of controlling the customers’ actions.}

The pricing for different options is listed in the table below:

XLoader’s seller also released a free Java binder which is intended to create a standalone JAR file uniting Mach-O and exe binaries:

\n

\n

^{Figure 18 – Interface of the XBinder tool.}

A new developer?

Did the new seller also take on duties as the developer and maintainer of this version of the original Formbook malware? We believe this is not the case. A new seller is just a seller, not a developer.  There must be someone else behind the curtain to handle the technical part.

\n

\n

^{Figure 19 – XLoader’s seller states that he is an official seller, not a developer of the malware.}

We already saw that ng-Coder wasn’t completely out of the picture, even though he no longer operated publicly. Could he be the one continuing to develop the new malware? Apart from technical similarities, we found evidence of a connection between XLoader’s seller and ng-Coder, namely a  message from xloader to ng-Coder saying, “Thank you for the help”:

\n

\n

^{Figure 20 – xloader saying “thank you” to ng-Coder.}

We cannot say for sure if the thanks were for a one-time helping hand or if it was for continuous support.

Another piece of evidence that points at ng-Coder’s continued participation is the statement by XLoader’s seller (posted on December 14, 2020) where he shared his hope that ng-Coder could create a newer cross-platform crypting service:

\n

\n

^{Figure 21 – xloader sharing the hope about a new crypting service from ng-Coder.}

Recap

We recap the malware activity timeline and its milestones in the diagram below.

\n

\n

^{Figure 22 – The activity timeline of both malware versions.}

Re-sellers

During the lifecycle of Formbook/XLoader malware, a number of impersonators and re-sellers claimed they were the official contacts.

It began 5 years ago when ng-Coder raised a warning not to send a payment to him or anyone impersonating him for the exploit, as he stopped selling exploits in 2016. Note that there were impersonators even before Formbook was first available for sale.

In 2021, the situation hasn’t changed much. For example, there is a site freely accessible from the Internet which offers XLoader for sale, but for a higher price than the malware is sold for in the Darknet:

\n

\n

^{Figure 23 – A site in the Internet offering XLoader for sale.}

The biggest difference is in the 3 months package for macOS, which is $40 higher than the Darknet price.

Another site offers XLoader for $120:

\n

\n

^{Figure 24 – Another Internet site offering XLoader for sale.}

Prevalence: countries and campaigns

During the 6 months between December 1, 2020 and June 1, 2021, we saw Formbook/XLoader requests from as many as 69 countries, which is more than a third of the total 195 countries recognized in the world today.

The breakdown of victims by country is presented in the diagram below:

\n

\n

^{Figure 25 – Formbook requests by countries between December 1, 2020 and June 1, 2021.}

Victims from the United States constitute more than the half of the victims worldwide.

As we stated previously, according to AnyRun, Formbook is in 4^th place among the most prevalent malware families of the last year and in 6^th place for all time. This fact implies that there should be quite a lot of Formbook\\XLoader campaigns in-the-wild. Indeed, we observed more than 1400 different campaigns of the malware during several years of monitoring its activity.

In the upcoming articles we share the technical details of the malware’s macOS version which reveal how XLoader operates under the hood and help us to understand how the Formbook\\XLoader family secured its place in malware top prevalence lists.

We also describe a distinctive feature of the XLoader malware which helps it to fool sandboxes and researchers and keep its real C&C servers hidden. Out of almost 90,000 domains used in network communication by the malware, only 1,300 are the real C&C servers – which constitutes just 1.5% of the total. The other 88,000 domains belong to legitimate sites; however, the malware sends malicious traffic to them as well. This presents security vendors with the dilemma of how to determine which are the real C&C servers and not false-positively identify legitimate sites as malicious.

We also share our methods to correctly analyze the XLoader’s communication with the servers and to identify the real C&C – only one out of all the 64 domains present in any chosen sample.

Stay tuned!

Check Point Protections

Check Point Provides Zero-Day Protection Across Its Network, Cloud, Users and Access Security Solutions, SandBlast provides the best zero-day protection while reducing security overhead 

SandBlast Network Protections:

         Trojan.WIN32.Formbook.A\n         Trojan.WIN32.Formbook.B\n         Trojan.WIN32.Formbook.C\n         Trojan.WIN32.Formbook.D\n         Trojan.WIN32.Formbook.E\n         Trojan.WIN32.Formbook.F\n         Trojan.WIN32.Formbook.G\n         Trojan.WIN32.Formbook.H\n         Trojan.WIN32.Formbook.I\n         Trojan.WIN32.Formbook.J\n         Trojan.WIN32.Formbook.K\n         Trojan.WIN32.Formbook.L\n         Trojan.WIN32.Formbook.M\n         Trojan.WIN32.Formbook.N\n         Trojan.WIN32.Formbook.O\n         Trojan.WIN32.Formbook.P\n         Trojan.WIN32.Formbook.Q\n         Trojan.WIN32.Formbook.R 

Threat Emulation protections:

         Infostealer.Win32.Formbook.C\n         Infostealer.Win32.Formbook.D\n         Infostealer.Win32.Formbook.E\n         Infostealer.Win32.Formbook.gl.F\n         Infostealer.Win32.Formbook.TC\n         Formbook.TC\n         Infostealer.Win32.XLoader.TC\n         XLoader.TC\n         Trojan.Mac.XLoader.B 

Sources

\n
1. Check Point Press Release December 2020 // https://www.checkpoint.com/press/2021/december-2020s-most-wanted-malware-emotet-returns-as-top-malware-threat/#
\n
2. Malware Trends Tracker // https://any.run/malware-trends/
\n
3. Malware Analysis Spotlight: Formbook (September 2020) // https://www.vmray.com/cyber-security-blog/formbook-september-2020-malware-analysis-spotlight/ 
\n
4. Significant FormBook Distribution Campaigns Impacting the U.S. and South Korea // https://www.fireeye.com/blog/threat-research/2017/10/formbook-malware-distribution-campaigns.html
\n
5. Formbook Research Hints Large Data Theft Attack Brewing // https://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/
\n
6. Selling FormBook // https://www.blueliv.com/cyber-security-and-cyber-threat-intelligence-blog-blueliv/research/selling-formbook/
\n
7. Cybercrime, new Formbook malspam campaign against hotels // https://www.difesaesicurezza.com/en/defence-and-security/cybercrime-new-formbook-malspam-campaign-against-hotels/
\n
8. VB 2018: Inside Formbook Infostealer // https://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-inside-formbook-infostealer/
\n
9. GuLoader? No, CloudEyE // https://research.checkpoint.com/2020/guloader-cloudeye/
\n
10. Yes, Cyber Adversaries are still using Formbook in 2021 // https://yoroi.company/research/yes-cyber-adversaries-are-still-using-formbook-in-2021/
\n

Research by: Eyal Itkin, Gili Yankovitch

Introduction

During 35C3, Gili Yankovitch (@cytingale) and I attended a great talk called: “Memsad – Why Clearing Memory is Hard” (https://media.ccc.de/v/35c3-9788-memsad). In his talk, Ilja van Sprundel presented the difficulties programmers face when trying to wipe a memory area that may contain secrets. This is due to the fact that most of the time, the calls to memset() have an undefined meaning according to the C standard, and therefore they are optimized out during compilation.

Intrigued by this gap between the programmers’ expectations and the compiler’s behavior, we asked if there are additional optimizations like these, beyond the scope of wiping memory? We were both quite familiar with the C standard, and already knew that many C programmers don’t usually follow each and every part of the standard. This led us to suspect that this extended approach would find some interesting results, and so we began our research.

In this blog post, we describe the versions of the tools and open sources we studied. Note – As our research took place approximately a year ago, some of these may not be fully up to date.

Undefined Behavior in C/C++

The C/C++ programming languages seem simple and quite straightforward to most common/embedded developers. Unfortunately, most programmers are not familiar with the in-depth details of the C standard, nor the C++ one. This is a common cause for many security vulnerabilities that can be found in the dark corners of the code. In a previous blog post from 2016, we gave a few examples of Integer-Overflow cases which are flagged as “undefined” in the standard. You can read more about it here.

As seen in this online cpp reference, the standard specifies a list of code classes, one of which is the “Undefined Behavior” class:

There are no restrictions on the behavior of the program. Examples of undefined behavior are memory accesses outside of array bounds, signed integer overflow, null pointer dereference, …, etc. Compilers are not required to diagnose undefined behavior (although many simple situations are diagnosed), and the compiled program is not required to do anything meaningful.

The reference also includes some code examples for a few such undefined behavior (UB) cases.

But what does it all mean? In theory, if compilers detect a code snippet which is undefined, they can do whatever they like: “the compiled program is not required to do anything meaningful.” In practice, compiler writers are relatively conservative, and they only apply code optimizations if the optimization will preserve the true meaning of the code in all defined cases. While compilers won’t actively search for a UB case and change the entire program to the efficient “return 0;” function, they will apply an optimization if it makes sense in all of the standard-defined cases.

One example of such an optimization is found in the following code snippet shown in Figure 1:

Figure 1: Signed integer-overflow UB-based optimizations.

On the left, we see 3 code checks with the signed addition of two operands, and on the right we see the matching assembly instructions, as compiled by Clang x86-64 version 3.9.0 with optimizations flags “-o2”. This example was generated by the always useful Compiler Explorer.

What can we learn about each of the 3 checks?

\n
1. The first check was removed: a + 100 < a is semantically equivalent to 100 < 0, which always evaluates to false.
\n
2. The second check was also changed to: b < 0.
\n
3. Only the third check wasn’t modified by the compiler’s optimizations.
\n

The compiler’s optimization tried to eliminate identical operands from both sides of the comparison, as such an optimization preserves the condition being checked. The only case in which the condition will in fact be changed is if the original addition operation will overflow (be bigger than 2GB). However, signed integer overflow is undefined by the standard, and so the compiler can ignore this edge case and continue on with the optimization.

Back in 2007, a similar optimization led to a wide discussion in regard to GCC’s optimizations. We highly recommend that our audience read the entire discussion.

Now that we understand the nature of UB-based compiler optimizations, it is time to recreate the results from the original research, so we can try and expand them to cover all UB-based optimizations.

Starting to play with GCC

Compiling our own version of GCC wasn’t an easy feat, but we finally got it to work by following this excellent guide. We chose GCC (version 8.2.0) instead of Clang, because the original research introduced a small patch for GCC to print out a warning each time the compiler removes a call to memset(), and it’s easier to expand an existing patch than to recreate everything from scratch.

Figure 2 shows the simple patch for catching opt-out calls to memset():

Figure 2: GCC patch to warn about optimized out calls to memset().

Less than 10 lines of code, and that’s it. Sadly, catching every UB-based optimization demanded way more code changes than this original patch.

After a few hours of toying around with the compiler, we found a neat debug trick: You can run GCC and tell it to dump the code tree after each pass. Just bear in mind that there are tens of dozens of such passes, so going through them isn’t very easy. To test in which pass these optimizations occur, we wrote 3 simple test programs in C, each with a unique integer-overflow UB:

void ub_signed_int_overflow_case_1(int length, int capacity)\n{\n    if (capacity < 0 || length < 0)    \n    {\n        printf(\"Negative\\n\");\n        exit(4);\n    }\n    /* allocate the buffer */\n    while( length > capacity )\n    {                         \n        capacity *= 2;\n        /* EI-DBG: Should get optimized out */\n        if (capacity < 0)      \n        {                       \n            printf(\"Overflowed\\n\");\n            exit(2);              \n        }                                             \n    }\n    ...\n}

Figure 3: MRuby-inspired test for signed multiplication-based integer-overflow UB.

void ub_signed_int_overflow_case_2(int length)\n{\n    int capacity = 120;\n    /* EI-DBG: Should get optimized out */\n    if (length + capacity < length)\n    {\n        printf(\"Overflowed\\n\");\n    } else\n    {\n        printf(\"OK!\\n\");\n    }\n}

Figure 4: Classic signed integer-overflow UB in addition.

void ub_signed_int_overflow_case_3(int length)\n{\n    int capacity = 120;\n    if(capacity < 0)\n    {\n        printf(\"Negative\\n\");\n        return;\n    }\n    if(length < 0)\n    {\n        printf(\"Negative\\n\");\n        return;\n    }\n    /* EI-DBG: Should get optimized out */\n    if (length + capacity < 0)\n    {\n        printf(\"Overflowed\\n\");\n    } else\n    {\n        printf(\"OK!\\n\");\n    }\n}

Figure 5: Constant-propagation + signed addition-based integer-overflow UB.

Soon enough, we found that the interesting lines are changed in passes that are related to “constant propagation” and “constant folding.”

Initially, we thought that UBSan might be useful in prompting our undefined-behavior tests. However, it turns out that most of the optimizations happen before it kicks into action, and it only reports dynamic violations in the code that survived the optimizations. Not exactly useful.

Debugging GCC’s behavior was way tougher than we initially anticipated, but after we sprayed the code with multiple debug prints, we zoomed in on fold_binary_loc in file fold-const.c. It turns out that the documentation inside the code was misleading, and in fact most of the optimizations happen inside generic_simplify. As if that wasn’t enough, this logic is contained in a generated file that is generated from the patterns inside match.pd.

Now that we (think that we) understood where all of the optimizations happen, we placed plenty of print messages on UB-based decisions throughout the code, and near optimization based decisions. We then wrapped our modified GCC with a Python script to keep track of our messages, and tell us if a code line was optimized because of a UB-based logic in that same line. Surprisingly, we had to fix a few bugs in the line tracking inside GCC, as we initially encountered a few bugs in our script which we traced back to GCC’s code. Time for the results.

Results

After we finalized our GCC patch, we tried to use it to compile a wide variety of open sources, and sadly, most of them were free of UB-based warnings. These are the warnings that we did find:

Libpng 1.2.29: Found a NULL deref near an optimized out check for NULL.

\n
• The check was optimized out because of the possible deref before it. Bingo.
\n
• This bug was already fixed in the latest version of the library.
\n

Libtiff Up until 4.0.10 – CVE-2019-14973: Multiple integer overflow checks are optimized out.

\n
• During our research, these 3 bugs were still valid, but we couldn’t find an actual way to exploit them to something more than a DoS.
\n
• While writing this blog post, we found this commit from a few months ago. It addressed exactly our results, now labeled CVE-2019-14973, and even mentions it was caused by undefined behavior in C.
\n

All 3 bugs that we found are similar, and look like this:

tmsize_t bytes = nmemb * elem_size;\n\n/*\n * XXX: Check for integer overflow.\n */\nif (nmemb && elem_size && bytes / elem_size == nmemb)\n    cp = _TIFFrealloc(buffer, bytes);

Figure 6: Integer-overflow check as found in the source of libtiff.

The output of our script, regarding the condition line:

tif_aux.c:70 – overflow based pattern simplification
\ntif_aux.c:70 – simplification due to constant (variables) propagation (2)
\ntif_aux.c:70 – gimple_simplified to: if (1 != 0)
\ntif_aux.c:70 – Folding predicate 1 != 0 to true
\ntif_aux.c:70 – propagate known values: always true, if (1 != 0)
\ntif_aux.c:70 – Folded into: if (1 != 0)
\ntif_aux.c:70 – gimple_simplified to: if (_3 != 0)

In short, it identified the overflow check bytes / elem_size == nmemb as always true and notified us that it folded it out, to the code that can be seen in Figure 7.

if (nmemb && elem_size)\n    cp = _TIFFrealloc(buffer, bytes);

Figure 7: Actual code after the compiler’s optimizations.

The reason for this optimization is surprising: tmsize_t is signed. For some unknown reason, the authors of the library decided to give their basic used type the confusing name of tmsize_t, even though, in contrast to the well known type size_t, it is not unsigned.

Conclusions

Our first conclusion is obvious when you think of it: the latest compiler versions contain more optimizations and produce more efficient code. GCC 5.4 failed to optimize the multiplication in libtiff, but GCC 8.2 optimized it out like a charm. Our second conclusion, however, is more interesting.

Although we were quite optimistic when we started this research, we soon realized that our expectations weren’t correlated to the results we received in practice. While we don’t know why there are way more calls to memset() that get optimized out in comparison to other undefined behavior cases, we can still speculate:

Guess #1: It is possible that programmers are more aware of other UB-cases when compared to optimized out calls to memory wiping. Based on our previous experience in code audit and vulnerability research, this isn’t very likely. However, we do know that open sources tend to get compiled with various compilation flags that instruct the compiler to treat signed integer overflow just like unsigned integer overflow. This is one solution for handling code that wasn’t written according to the standard.

Guess #2: Fuzzers. Many open sources were fuzzed to death, and if compilers would introduce an optimization that would “break” the code, fuzzers will find this gap and report it. As fuzzers don’t usually care about memory wiping, this explains why such optimizations went widely unnoticed up until Ilja’s talk in 35C3.

The second guess seems way more likely, and it also means that although useful, our patch for GCC won’t give us a valuable advantage in comparison to the research tools already used.

It was a good lead to research, but sadly for us, it seems that fuzzers killed such bug classes before we reached them. On a more optimistic tone, since fuzzers test the binary level and not the code level, they can’t be fooled by the original intent of the programmer; they test the actual code as produced by the compiler, after it performed all of the optimizations rounds.

When combined with our first conclusion, we advise researchers and programmers alike to fuzz their programs after they compile them with the most updated version of the compiler. It seems that simply upgrading the compiler is enough to find results based on the recent optimizations that this compiler now supports.