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.
\n\n\n\nAccording to AnyRun Malware Trends Tracker, Formbook occupies the 4th place in a list of the most prevalent malware families in 2020.
\n\n\n\n\n\n\n\nFigure 1 – Formbook is in 4th place among the most prevalent malware families of the past 12 months (June 2020 – June 2021) – AnyRun.
\n\n\n\nFormbook 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.
\n\n\n\nAs 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.
\n\n\n\nA 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.
\n\n\n\nLet’s take a look at how it all began.
\n\n\n\nA 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\n\n\n\n\n\nFigure 2 – ng-Coder offering Formbook malware for sale.
\n\n\n\nAlthough the first sales thread appeared on February 13, 2016, Formbook samples were seen earlier as evidenced by AnyRun:
\n\n\n\n\n\n\n\nFigure 3 – First Formbook sample was seen on January 1, 2016, according to AnyRun.
\n\n\n\nThe Formbook’s seller was hidden under “ng-Coder” avatar.
\n\n\n\nNote: we assume ng-Coder is a male, though we have no direct evidence, and will refer to the avatar as “he” throughout this article.
\n\n\n\n\n
Profile
\ne-mail: ng2Coder@gmail.com\n Skype: Ng.Coder\n skills:\n * strong c\\c++ knowledge\n * strong assembly x86\\x64 knowledge\n\n\n\n
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.
\n\n\n\nA 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\n\n\n\n\n\nFigure 4 – Formbook review requested by ng-Coder.
\n\n\n\nOn May 9, 2016, three months later after publishing the first sales thread, Formbook v.0.3 was offered for sale.
\n\n\n\n\n\n\n\nFigure 5 – Formbook v.0.3 icon.
\n\n\n\nFormbook was advertised as a product supporting multiple features:
\n\n\n\n\n\n\n\nFigure 6 – Formbook v.0.3 features.
\n\n\n\nWhat 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.
\n\n\n\nOther features listed include network traffic sniffing, keylogging, clipboard monitoring, and password extraction for almost one hundred applications including browsers, messengers, FTP and email clients.
\n\n\n\nThe 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.
\n\n\n\nDifferent types of Formbook subscriptions had different prices:
\n\n\n\n\n\n\n\nFigure 7 – The Formbook pricing as offered by ng-Coder.
\n\n\n\nng-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\n\n\n\n\n\nFigure 8 – Net-Protector logo.
\n\n\n\nng-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\n\n\n\n\n\n\n\nIf 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.
\n\n\n\nOn October 6, 2017, Formbook sales abruptly stopped. The reason given was its use in spam campaigns:
\n\n\n\n\n\n\n\nFigure 9 – ng-Coder indicates that Formbook sales have ceased.
\n\n\n\nAs 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.
\n\n\n\nOn 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.
\n\n\n\nAs 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.
\n\n\n\nWe 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.
\n\n\n\nhttp[://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/\n\n\n\n
All the listed domains share common features. They all were registered by the GoDaddy registrar:
\n\n\n\n\n\n\n\nFigure 10 – GoDaddy registrar appears in domains’ details.
\n\n\n\nAnd they all shared the same details about the person who registered them:
\n\n\n\n\n\n\n\nFigure 11 – Details for registering domains as provided by ng-Coder.
\n\n\n\nAccording 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.
\n\n\n\nThe 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\n\n\n\n\n\nFigure 12 – A Formbook sample dropped in May 2020 by GuLoader.
\n\n\n\nThe campaign name in this sample was “private” and the main domain was registered by ng-Coder (ryandeby[.com).
\n\n\n\nOn 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\n\n\n\n\n\nFigure 13 – XLoader as advertised in the underground group.
\n\n\n\nFormbook and XLoader share the same code base, and there are other connections between them as well, as we will see later.
\n\n\n\n\n\n\n\nFigure 14 – The seller confirms that Formbook’s code has contributed a lot to the development of XLoader.
\n\n\n\nOn October 20, 2020, XLoader was offered for sale on the same forum which was used for selling Formbook.
\n\n\n\n\n\n\n\nFigure 15 – XLoader as advertised on the forum.
\n\n\n\nNote: XLoader malware for PC and Mac should not be confused with XLoader malware for Android, first discovered in 2019.
\n\n\n\nOne 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\n\n\n\n\n\nFigure 16 – Mac sales by year, taken from https://www.businessofapps.com/data/apple-statistics/
\n\n\n\nNote: Apple stopped reporting Mac sales in Q4 2018. All subsequent values are estimates.
\n\n\n\nThe 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\n\n\n\n\n\nFigure 17 – xloader announces the decision to stop selling panels and underlines the importance of controlling the customers’ actions.
\n\n\n\nThe pricing for different options is listed in the table below:
\n\n\n\nPackage | \nPrice | \n
Windows, executable, 1 month | \n$59 | \n
Windows, executable, 3 months | \n$129 | \n
macOS, Mach-O, 1 month | \n$49 | \n
macOS, Mach-O, 3 months | \n$99 | \n
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\n\n\n\n\n\nFigure 18 – Interface of the XBinder tool.
\n\n\n\nDid 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\n\n\n\n\n\nFigure 19 – XLoader’s seller states that he is an official seller, not a developer of the malware.
\n\n\n\nWe 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\n\n\n\n\n\nFigure 20 – xloader saying “thank you” to ng-Coder.
\n\n\n\nWe cannot say for sure if the thanks were for a one-time helping hand or if it was for continuous support.
\n\n\n\nAnother 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\n\n\n\n\n\nFigure 21 – xloader sharing the hope about a new crypting service from ng-Coder.
\n\n\n\nWe recap the malware activity timeline and its milestones in the diagram below.
\n\n\n\n\n\n\n\nFigure 22 – The activity timeline of both malware versions.
\n\n\n\nDuring the lifecycle of Formbook/XLoader malware, a number of impersonators and re-sellers claimed they were the official contacts.
\n\n\n\nIt 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.
\n\n\n\nIn 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\n\n\n\n\n\nFigure 23 – A site in the Internet offering XLoader for sale.
\n\n\n\nThe biggest difference is in the 3 months package for macOS, which is $40 higher than the Darknet price.
\n\n\n\nAnother site offers XLoader for $120:
\n\n\n\n\n\n\n\nFigure 24 – Another Internet site offering XLoader for sale.
\n\n\n\nDuring 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.
\n\n\n\nThe breakdown of victims by country is presented in the diagram below:
\n\n\n\n\n\n\n\nFigure 25 – Formbook requests by countries between December 1, 2020 and June 1, 2021.
\n\n\n\nVictims from the United States constitute more than the half of the victims worldwide.
\n\n\n\nAs we stated previously, according to AnyRun, Formbook is in 4th place among the most prevalent malware families of the last year and in 6th 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.
\n\n\n\nIn 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.
\n\n\n\nWe 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.
\n\n\n\nWe 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.
\n\n\n\nStay tuned!
\n\n\n\nCheck 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
\n\n\n\nSandBlast Network Protections:
\n\n\n\nTrojan.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\n\n\n\n
Threat Emulation protections:
\n\n\n\nInfostealer.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\n\n\n\n
Research by: Eyal Itkin, Gili Yankovitch
\nDuring 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.
\nIn 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.
\nThe 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.
\nAs seen in this online cpp reference, the standard specifies a list of code classes, one of which is the “Undefined Behavior” class:
\nThere 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.
\nThe reference also includes some code examples for a few such undefined behavior (UB) cases.
\nBut 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.
\nOne example of such an optimization is found in the following code snippet shown in Figure 1:
\nFigure 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.
\nWhat can we learn about each of the 3 checks?
\na + 100 < a
is semantically equivalent to 100 < 0
, which always evaluates to false
.b < 0
.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.
\nBack 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.
\nNow 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.
\nCompiling 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.
\nAfter 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:
\nvoid 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}\n
Figure 3: MRuby-inspired test for signed multiplication-based integer-overflow UB.
\nvoid 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}\n
Figure 4: Classic signed integer-overflow UB in addition.
\nvoid 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}\n
Figure 5: Constant-propagation + signed addition-based integer-overflow UB.
\nSoon enough, we found that the interesting lines are changed in passes that are related to “constant propagation” and “constant folding.”
\nInitially, 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.
\nAfter 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:
\nLibpng 1.2.29: Found a NULL deref near an optimized out check for NULL.
\nLibtiff Up until 4.0.10 – CVE-2019-14973: Multiple integer overflow checks are optimized out.
\nAll 3 bugs that we found are similar, and look like this:
\ntmsize_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);\n
Figure 6: Integer-overflow check as found in the source of libtiff.
\nThe output of our script, regarding the condition line:
\ntif_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);\n
Figure 7: Actual code after the compiler’s optimizations.
\nThe 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.
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.
\nAlthough 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.
\nGuess #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.
\nThe 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.
\nIt 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.
\nWhen 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.
\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2020/optout-compiler-undefined-behavior-optimizations/","tags":[],"score":0.004386921878904104,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};