The first issue of Cerbero Journal, our company e-zine, is out!
What does it contain? News, technical articles, tips & tricks and much more.
It includes the nostalgia bonus if, like us, you’re old enough to remember the golden era of e-zines.
The first issue of Cerbero Journal, our company e-zine, is out!
What does it contain? News, technical articles, tips & tricks and much more.
It includes the nostalgia bonus if, like us, you’re old enough to remember the golden era of e-zines.
Here summarized are the main news of this release of Cerbero Suite 5.6 and Cerbero Engine 2.6.
We created the MalwareBazaar Intelligence package. This package lets you access intelligence from MalwareBazaar directly from the file report.
Commercial licenses for Cerbero Suite Advanced have access to this package.
We created an UPX Unpacker package available for all licenses.
From the UPX web-site: “UPX is a free, portable, extendable, high-performance executable packer for several executable formats.”
By installing the UPX Unpacker package, binaries compressed with UPX are automatically identified and unpacked as child objects.
PE, ELF and Mach-O binaries are all supported.
If for some reason a binary is not automatically unpacked, the unpacker can be invoked manually as an action.
Additionally, the unpacker can be invoked from Python.
You can read more about the topic in our dedicated post.
We introduced a new major core feature, namely the capability to generate files which do not exist on disk and store them in the analysis report.
While this feature may not appear as essential, it has countless real-world applications. For example, an unpacker may unpack a file during the scanning process and store the resulting file as an internal file. When the unpacked file is requested, the operation bypasses the unpacker and directly accesses the internal file.
Internal files can be referenced from embedded objects as well as from root entries.
You can read the details about the topic in our dedicated post.
We made several improvements which can be best described as ‘after-scanning actions’.
For instance, it is now possible to programmatically add scan entries to a report after the scanning has occurred.
While the user could always manually load embedded objects after scanning, it is now possible to load embedded objects programmatically after scanning.
Furthermore, we added the capability to add new root entries to a report by letting the user choose files from disk. This can also be performed programmatically.
Last but not least, we added the capability to promote the data in a hex view to a root file in the report.
You can read more about the topic in our dedicated post.
As already mentioned this in the paragraph of the after-scanning actions, we added the capability to add new root entries to a report by letting the user choose files from disk.
If added from code, root entries can also reference internal files.
As already mentioned this in the paragraph of the after-scanning actions, we added the capability to promote the data in a hex view to a root file in the report.
The data from the hex view is stored as an internal file and referenced from the root entry. The advantage over loading an embedded object from a hex view is that promoting the data to a root file isn’t limited to analysis hex views. In fact, this action can be performed from any hex view.
While we routinely add new APIs to our SDK, this release comes with a larger number of new and improved APIs in the Core module.
Having already completed the SDK documentation of our core modules, we have started documenting our file format modules and just finished the first two.
We have documented the API for parsing Microsoft Cabinet files.
And we have documented our comprehensive API for parsing certificate files in both DER and PEM encodings.
We’ll continue documenting our file format modules in the upcoming months.
We have improved our settings page. Specifically, we have switched from a tab-based interfaced to a list-based one.
The reason for this change lies in the capability of plugins to add custom pages to the settings and a tab-based interfaced may get too cramped in the future.
We fixed a number of issues related to the Python Global Interpreter Lock. These issues would show themselves rarely but could lead to crashes under the right conditions when using scan providers implemented in Python.
A user reported issues with VBA extraction related to code page support. The extracted VBA now correctly shows non-ascii characters.
We have also made other minor improvements and fixed a few minor issues.
Having already completed the SDK documentation of our core modules, we have started documenting our file format modules and just finished the first two.
Namely, we have documented the API for parsing Microsoft Cabinet files.
And we have documented our comprehensive API for parsing certificate files in both DER and PEM encodings.
We’ll continue documenting our file format modules in the upcoming months.
We created an UPX Unpacker package for the upcoming 5.6 version of Cerbero Suite.
From the UPX web-site: “UPX is a free, portable, extendable, high-performance executable packer for several executable formats.”
By installing the UPX Unpacker package, binaries compressed with UPX are automatically identified and unpacked as child objects.
PE, ELF and Mach-O binaries are all supported.
If for some reason a binary is not automatically unpacked, the unpacker can be invoked manually as an action.
Additionally, the unpacker can be invoked from Python.
from Pkg.UPXUnpacker.Unpack import unpack ret, output = unpack(file_name) # prints the unpacker output print(output.decode("utf-8"))
This package will be available for all licenses of Cerbero Suite.
In the upcoming 5.6 version of Cerbero Suite we’ve made several improvements which can be best described as ‘after-scanning actions’.
For instance, it is now possible to programmatically add scan entries to a report after the scanning has occurred.
The following is the code used in the example.
from Pro.Core import * def main(): sp = proCoreContext().currentScanProvider() e = ScanEntryData() e.category = SEC_Online e.type = CT_Intelligence e.otarget = "Test" sp.addHookEntry("MalwareBazaarIntelligence", e) main()
While the user could always manually load embedded objects after scanning, it is now possible to load embedded objects programmatically after scanning.
In the code example we use the recently introduced internal files to demonstrate how to add an embedded object referencing an internal file.
from Pro.Core import * def main(): sp = proCoreContext().currentScanProvider() r = sp.getGlobalReport() uid = r.newInternalFileUID() path = r.newInternalFilePath(uid) with open(path, "w") as f: f.write("hello " * 5) r.saveInternalFile(uid, "Test File") sp.addInternalFile(uid, "", "Internal File") main()
Furthermore, we added the capability to add new root entries to a report by letting the user choose files from disk. This can also be performed programmatically.
In the code example we demonstrate how to add both an internal file as root entry and a regular file on disk.
from Pro.Core import * def main(): sp = proCoreContext().currentScanProvider() r = sp.getGlobalReport() uid = r.newInternalFileUID() path = r.newInternalFilePath(uid) with open(path, "w") as f: f.write("hello " * 5) r.saveInternalFile(uid, "", "Test") proCoreContext().addObjectToReport("Test", REPORT_INT_ROOT_PREFIX + uid) proCoreContext().addObjectToReport("Kernel32.dll", r"c:\Windows\System32\Kernel32.dll") main()
Last but not least, we added the capability to promote the data in a hex view to a root file in the report.
The data from the hex view is stored as an internal file and referenced from the root entry. The advantage over loading an embedded object from a hex view is that promoting the data to a root file isn’t limited to analysis hex views. In fact, this action can be performed from any hex view.
The upcoming 5.6 version of Cerbero Suite introduces a new major core feature, namely the capability to generate files which do not exist on disk and store them in the analysis report.
While this feature doesn’t seem so important, it has countless real-world applications. For example, an unpacker may unpack a file during the scanning process and store the resulting file as an internal file. When the unpacked file is requested, the operation bypasses the unpacker and directly accesses the internal file.
In the following example a dummy internal file is generated for a scanned file and adds it as an embedded object to the generated report.
from Pro.Core import * def scanning(sp, ud): # skip if it's a nested scan: avoid recursion if sp.isNestedScan(): return # a global report is needed to store internal files r = sp.getGlobalReport() if not r: return # generate an internal file id uid = r.newInternalFileUID() if not uid: return # retrieve the path on disk for the internal file path = r.newInternalFilePath(uid) # generate the content of the internal file with open(path, "w") as f: f.write("hello " * 5) # save the internal file r.saveInternalFile(uid, "TEST FILE") # add the internal file as embedded object sp.addInternalFile(uid, "", "Test")
The lines in the ‘hooks.cfg’ configuration file:
[IntFileTest_1] label = Internal file test file = intfile_hook.py scanning = scanning enable = yes
What follows is a screenshot of the result of this operation.
Internal files can be referenced as embedded objects as well as root objects. When referencing an internal file from a root entry in the report it is enough to set the file name of the entry as following:
REPORT_INT_ROOT_PREFIX + uid
This means that not only embedded objects, but also root objects can reference internal files which may be temporary if the project is not saved by the user.
We’ll soon use internal files to create new and also expand existing packages for Cerbero Suite.
With the upcoming 5.6 version of Cerbero Suite Advanced we’ll release our MalwareBazaar Intelligence package. This package lets you access intelligence from MalwareBazaar directly from the file report.
The package can be downloaded from Cerbero Store and will initially be available only to commercial licenses.
Here summarized are the main news of this release of Cerbero Suite 5.5 and Cerbero Engine 2.5.
Cerbero Engine already supports various platforms and architectures. Now, it comes in two different editions: Classic and Metal.
While in the Classic edition all UI functions are available, the Metal edition comes without UI dependencies.
The Metal edition is designed to be run in cloud and server environments which may lack a graphical interface.
We took great care in preserving plugin compatibility.
Plugins which import graphical functions are compatible with the Metal edition: all UI functions are available, though they are provided only as stubs. A few graphical methods like msgBox fall back to console I/O.
Providing two editions of Cerbero Engine allows us to offer the perfect fit for organizations which need a powerful and flexible back-end for their services.
Customers with commercial licenses for Cerbero Suite Advanced and Cerbero Engine can verify Microsoft Authenticode signatures on Linux and macOS. Our Authenticode support includes full-chain certificate and time-stamp verification.
The only required step to verify Authenticode signatures on non-Windows systems is to install our “Microsoft Authenticode” package from Cerbero Store.
Cerbero Suite has been using its own implementation of Microsoft Authenticode for performance reasons since the very beginning, back in 2012. However, thanks to the recently introduced Cerbero Store we can now offer this feature on systems other than Windows.
We have also exposed Authenticode validation to our Python SDK. You can read more about the topic in our dedicated post.
While Cerbero Suite already lets you inspect certificates inside binaries, now it can load them directly from disk and also lets you inspect each individual ASN1 object.
Both DER and PEM encodings for certificates are supported.
You can inspect all types of certificates, including X509, PKCS7 and PKCS12.
We have also exposed the code to our Python SDK in order to make the programmatic parsing of certificates a simple task.
You can read more about the topic in our dedicated post.
We’ve made various improvements to command line support, the most interesting among them is the addition of command line I/O on Windows.
On Windows running scripts with the ‘-c’ argument results in not being able to see the stdout output. The reason for this is that the cerpro executable is built as a GUI application and therefore is not attached to a terminal.
To overcome this limitation we have added a launcher on Windows called “cerpro_console.exe”.
For example:
cerpro_console.exe -e "t=input('Input a string: ');print(t)"
The code asks the user to input a string and prints it back.
Of course, the cerpro_console executable can be used to launch any functionality of Cerbero Suite which supports console mode (‘-c’).
For example the following command prints out the command-line help to stdout:
cerpro_console.exe -h
You can read about all the improvements we’ve made in our dedicated post.
We have released the official SDK documentation for command line scripting and package management.
We have improved the visualization of the SDK documentation by adding tables which sum up the contents of modules and classes.
This makes it quicker to grasp the contents of an object.
We have also made other minor improvements and fixed a few bugs.
With the upcoming releases customers with commercial licenses for Cerbero Suite Advanced and Cerbero Engine can verify Microsoft Authenticode signatures on Linux and macOS. Our Authenticode support includes full-chain certificate and time-stamp verification.
In conjunction with our recently extended support for certificate file formats, this provides complete support for inspecting signed Portable Executable binaries.
The only required step to verify Authenticode signatures on non-Windows systems is to install our “Microsoft Authenticode” package from Cerbero Store.
Cerbero Suite has been using its own implementation of Microsoft Authenticode for performance reasons since the very beginning, back in 2012. However, thanks to the recently introduced Cerbero Store we can now offer this feature on systems other than Windows.
We have also exposed Authenticode validation to our Python SDK.
from Pro.PE import * print(PE_VerifyAuthenticode(obj))
Alternatively, scan hooking extensions can check the generated report for the validation scan entries.
In the upcoming 5.5 version of Cerbero Suite and the 2.5 version of Cerbero Engine we support certificate formats. While Cerbero Suite already lets you inspect certificates inside binaries, now it can load them directly from disk and also lets you inspect each individual ASN1 object.
Both DER and PEM encodings for certificates are supported.
You can inspect all types of certificates, including X509, PKCS7 and PKCS12.
We have also exposed the code to our Python SDK in order to make the programmatic parsing of certificates a simple task.
For example, enumerating every ASN1 object in a certificate takes just a few lines of code:
from Pro.Core import * from Pro.Certificates import * def main(): obj = proCoreContext().currentScanProvider().getObject() class Visitor(DERObjectVisitor): def Visit(self, obj, oi): print(oi.offset, oi.content_size) return 0 v = Visitor() obj.VisitObjects(v) main()
We’ll be fully documenting the Pro.Certificates module this year.