Analyzing FLUX#CONSOLE: Using Tax-Themed Lures, Threat Actors Exploit Windows Management Console to Deliver Backdoor Payloads
Threat Research
Securonix Threat Research Security Advisory
Analyzing FLUX#CONSOLE: Using Tax-Themed Lures, Threat Actors Exploit Windows Management Console to Deliver Backdoor Payloads
By Securonix Threat Research: Den Iuzvyk, Tim Peck
Publication Date: 12.17.24
tldr:
The Securonix Threat Research team has been monitoring an interesting tax-related phishing campaign where threat actors leveraged MSC files and advanced obfuscation techniques to execute a stealthy backdoor payload.
Is the abuse of LNK files finally on the decline? It seems that almost all malware campaigns these days feature a malicious LNK (shortcut) file as the initial code execution lure. In fact, the last three campaigns our team analyzed leveraged shortcut files, including SLOW#TEMPEST, SHROUDED#SLEEP and CRON#TRAP.
The attack likely starts with either a phishing email link or attachment. While we were not able to obtain the original phishing email used in the attack, the lures and nomenclature used in the filenames and lure documents suggest that the campaign follows standard tax-themed phishing methods (Income-Tax-Deduction-and-Rebates202441712.pdf for example). All of the documents examined are in English and one of which is a general tax document that appears to be prepared by the government of Pakistan.
Figure 1: phishing lure document: Income-Tax-Deduction-and-Rebates202441712.pdf (income.pdf)
The PDF document itself is benign and is simply used as a distraction, however, the malware that gets executed on the victim’s machine in the background is far from it.
The FLUX#CONSOLE campaign covers a rather interesting approach that threat actors are taking to deliver malware and to skirt traditional AV detections. One of the more notable aspects of the campaign is how the threat actors leverage MSC (Microsoft Common Console Document) files to deploy a dual-purpose loader and dropper to deliver further malicious payloads. In theory, the end result between both MSC and LNK files is the same: to execute malicious code by enticing the user to double click it, which is all you need to execute malicious code in the background. This explains why these file types are both common initial execution points in phishing email campaigns.
This loader efficiently handles both payload delivery and execution, leading to a stealthy and highly obfuscated backdoor DLL file. In this advisory, we’ll break down the technical aspects of this campaign, shedding light on the use of some of these more unconventional techniques.
The usage of .msc files is starting to pick up traction this year. In another campaign tracked earlier as GrimResource threat actors were observed using these files to execute malicious payloads. However, with this campaign, the threat actors do not appear to be leveraging a known XSS vulnerability found in adps.dll, as reported previously.
Key takeaways
- Tax-themed lures (T1566): Users are tricked into downloading and running malicious payloads by tax-themed document lures.
- Exploitation of MSC Files (T1218.014): The campaign discusses the abuse of MSC files, leveraging their legitimate appearance to evade detection while delivering malicious payloads.
- DLL Sideloading using Dism.exe (T1574.001): The threat actors copied the legitimate Windows process Dism.exe into a staging directly to sideload a malicious dropped DLL (
DismCore.dll). - Persistence through Scheduled Tasks (T1053.005): The malware in this campaign uses scheduled tasks to ensure the malware remains active and survives system reboots.
- Advanced Obfuscation Techniques (T1027.010): From highly obfuscated JavaScript to concealed DLL-based malware and C2 communications, the threat actors employed multiple layers of obfuscation to complicate analysis and hinder detection.
What Are .MSC Files?
Microsoft Management Console (MMC) snap-in files are normally a harmless type of configuration file used to manage administrative tools in Windows. Examples include tools like Event Viewer, Task Scheduler, and Device Manager. These files are XML-based and define how the MMC framework loads and displays snap-ins, allowing administrators to customize the interface for specific management tasks. When double-clicked, an .msc file automatically launches the MMC framework (mmc.exe) and executes the contained instructions.
As we observed in the FLUX#CONSOLE campaign, threat actors can exploit these.msc files because of their ability to execute embedded scripts or commands under the guise of legitimate administrative tools. In this scenario we observed the use of JavaScript, though the execution of VBScript is also supported. Therefore, any malicious code executed through the .msc file will execute under the context of mmc.exe.
The robust flexibility of MMC files can be exploited maliciously since attackers can craft .msc files that, when opened, execute arbitrary code without explicit user consent. One such method involves embedding a reference to a vulnerable ActiveX control within the .msc file’s StringTable section. When MMC processes this file, it loads the specified ActiveX control, which can be manipulated to execute malicious scripts or commands. This technique leverages the MMC’s capability to host various controls and extends its functionality, thereby facilitating unauthorized code execution. We’ll dive a bit deeper into this subject further down.
Initial infection
Code execution begins when the user double clicks on the “Inside ARRVL-PAX-MNFSTPK284-23NOV.pdf.msc” file. The file does a pretty good job of masquerading as a PDF, especially if the user does not have file extensions visible. Unfortunately, the setting for common extension visibility is disabled by default in modern versions of Windows.
Avoiding antivirus appears to be quite effective as at the time of writing, the malicious .msc file only scored just 3/62 positive detections according to VirusTotal:
Figure 2: VirusTotal threat score for ARRVL-PAX-MNFSTPK284-23NOV.pdf.msc
Let’s now dive into the msc file and determine what goes on under the hood when the user double clicks the file.
MSC file analysis
As we mentioned prior, the .msc file is essentially XML formatted, though what makes it lucrative for attackers is the fact that it is able to execute embedded payloads in the form of VBScript or JavaScript.
In a nutshell, before we dive too deep into it, the file essentially performs two main functions which perform the same task: download and execute a malicious DLL file “DismCore.dll” by sideloading it using the legitimate DISM.exe Windows process.
Through layers of obfuscation, the DLL is decoded and extracted from within the .msc file itself, or it’s downloaded from a remote URL which performs the same action. This effectively enables the malicious .msc file to function as either a loader or a dropper depending on the environment.
Figure 3: XML contents of ARRVL-PAX-MNFSTPK284-23NOV.pdf.msc phishing lure
Hidden execution
The FrameState section provides configuration for the visual and positional state of the MMC window, specifying that the status bar should be visible (ShowStatusBar="true"). However, the WindowPlacement element indicates an intention to hide the window from the user. In the image above we can make some observations which indicate malicious intent. First, the XML code instructs the window placement is set to X="-1" and Y="-1" which attempts to keep the interface hidden or non-interactive. It also uses ShowCommand="SW_HIDE" which does exactly what you’d expect, hide elements from the user to obfuscate its behavior.
Lure appearance
The VisualAttributes section defines the icon used for the MMC file, sourcing it from C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe which gives the file an appearance of legitimacy by associating it with a trusted application like Microsoft Edge, though this appears to be changed later on as further down it is configured with three different image sizes which masquerade as a PDF: a “Large” icon (BinaryRefIndex="0"), a “Small” icon (BinaryRefIndex="1"), and a larger version (Large48x, BinaryRefIndex="2"), all stored as binary data within the file. The embedded icons mimic standard PDF icon which is apparent when viewing the file from Windows Explorer.
Figure 4: document lure (ARRVL-PAX-MNFSTPK284-23NOV.pdf.msc) as it would appear to the user
Code execution
As seen in the figure below, the StringTable includes a GUID {2933BF90-7B36-11D2-B20E-00C04F983E60} associated with MSXML, a Microsoft XML parser. This parser allows XSL transformations using JScript, providing a pathway for code execution. By referencing this GUID, the .msc file can instantiate an MSXML ActiveX object, which can then process malicious XSL content containing embedded scripts. When MMC loads this .msc file, it processes the XSL, leading to the execution of the embedded JScript code.
Figure 5: string table within ARRVL-PAX-MNFSTPK284-23NOV.pdf.msc
This enables two actions to happen. First, the HTML content found at the remote URL (above) will be parsed and any script contents will be silently executed. This effectively acts as a loader, which downloads and executes next-stage payloads.
The second action performed is the execution of obfuscated JavaScript payloads present in the .msc file’s <binary> section. The file contains 13 (index 0-12) binary XML sections, three of which are dedicated to icon file data. The rest were junk code except for index 9 which contained additional embedded JavaScript which would also be processed as XSL by the MSXML ActiveX Object.
The remote and embedded payloads in the .msc file both aim to accomplish the same goal: delivering and executing a malicious DLL (which we’ll dive into later). By providing redundancy in the attack chain, this double approach ensures if one delivery mechanism is blocked or fails, the other can still achieve execution. And just to recap, the remote payload leverages a hosted HTML file to download and deploy the DLL dynamically, while the embedded payload includes the DLL’s encoded content directly within the .msc file for local decoding and execution. This design attempts to increase the overall reliability of the attack.
Whether or not the DLL payload is dropped remotely or from the embedded payload, the resulting file (DismCore.dll) is the same (b33d76c413ef0f4c48a8a61cfeb5e24ff465bbc6b70bf0cada2bb44299a2768f).
Let’s first dive into the embedded payload then we’ll circle back to the remote payload.
Embedded payload analysis
As we mentioned prior, the embedded payload is contained within the Base64 encoded “binary” data located at index 9 <binary> index tags within the .msc file. Decoding the Base64 blob gives us additional XML formatted code which contains a next-stage JavaScript file wrapped in <ms:script> </ms:script> tags.
Figure 6: embedded payload – obfuscated JavaScript within XML
After taking the time to deobfuscate the JavaScript, we get a bit more insight into its functionality. First, the script reaches out to a legitimate website to download a seemingly random PDF file from the URL:
hxxps://ewh.ieee[.]org/reg/ccece15/files/ccece-word-sample.pdf
This file is saved to C:\Users\Public\IEEE-Template-.pdf and then executed using the ShellExecute function to display it to the user. This provides the user with the intended result (the opening of a PDF) of their original action (double clicking a “PDF”).
Next, the script deobfuscates and executes the next stage JavaScript payload.
Figure 7: embedded payload – download, execute lure document, then execute next-stage binary payload
The (renamed) variable “reversedString” contains the embedded backdoor payload “DismCore.dll” which is decoded and dropped into the user’s %ProgramData% directory. Additional deobfuscation functions and file operations can be seen in the figure below.
Figure 8: embedded payload – decompiling of DismCore.dll
Persistence is established using scheduled tasks. Both the embedded and remote versions of the code contain this persistence functionality.
Remote JavaScript payload analysis
In addition to delivering the payload from an embedded and obfuscated string, the .msc file is able to execute additional code by reaching out to a remote HTML file which also accomplishes the same goal. Upon execution, mmc.exe will attempt to download and parse any contents found at the following URL:
hxxps://siasat[.]top/xyzxyzhanoiwhb3237gb2wahabjiki/Vuznbe3fbo234t34-snake-2723.html
As seen in the image below, the HTML file contains a single <script> tag containing obfuscated JavaScript code. The code is simply URL encoded.
Figure 9: remote payload – obfuscated JavaScript code of Vuznbe3fbo234t34-snake-2723.html
Deobfuscation of the code is quite trivial and can be managed using a single CyberChef recipe. The next layer (stage 3) also contains more malicious JavaScript code which performs several functions. First, it uses document.write(unescape('...')) to decode and inject its contents into the page. This technique is a common method for hiding malicious payloads from simple static analysis.
It then sets up an ActiveXObject, a feature of Internet Explorer often exploited by attackers. It does this by creating an XMLHTTP request to retrieve obfuscated file contents contained within the same page. Once retrieved it’s then executed.
Figure 10: remote payload – next-stage JavaScript execution of Vuznbe3fbo234t34-snake-2723.html (stage 2)
Moving down the obfuscation chain we’re left with even more obfuscated JavaScript. The obfuscation used is slightly different from what we observed in the previous stages. Dynamic function references (IE: _0x8ff745) are generated during runtime. It also uses functions like reverseString, decryptString, and hexDecode to dynamically decrypt next-stage payloads, avoiding static detection. These end up decoding a binary payload which is hex-decoded into a string, converted to Base64, and then decoded to its final binary form for execution. (See Appendix A for deobfuscation script)
Figure 11: remote payload – next-stage JavaScript execution of Vuznbe3fbo234t34-snake-2723.html (stage 3)
Similar to the embedded payload the remote payload performs similar functions. Just to recap, after taking the time to deobfuscate the JavaScript we’re left with code that is much more human readable. The script performs several key tasks:
- Using XMLHTTP requests, it downloads content from a remote URL (NOTE: different than the embedded payload) (
hxxps://siasat[.]top/xyzxyzhanoiwhb3237gb2wahabjiki/income.pdf) and stores it locally. This phishing lure presents the user with an expected result (opening a PDF) to their action (double clicking a file) - The script uses hex and Base64 encoding methods to decode the binary payload from a huge string.The result is a DLL file (
DismCore.dll). The script creates and moves a malicious DLL (DismCore.dll) to%ProgramData%. - Next, the script copies the legitimate Windows system file Dism.exe from its home in
C:\Windows\System32and also saves it to%ProgramData%
Figure 12: remote payload – next-stage JavaScript execution of Vuznbe3fbo234t34-snake-2723.html (stage 4)
With all the pieces in place, the script executes the copied version of Dism.exe within C:\ProgramData which leverages DLL search order hijacking, a form of DLL sideloading to execute the malicious payload DismCore.dll once the copied Dism.exe process starts.
Persistence using scheduled tasks
Persistence is established using scheduled tasks with the task scheduler ActiveX COM object (Schedule.Service). The task is designed to run every 5 minutes with the single goal of executing the version of Dism.exe that was copied into C:\ProgramData prior. Details for the creation and result of the scheduled task can be found in the image below:
Figure 13: persistence – scheduled task details
In a nutshell, the task called “CoreEdgeUpdateServicesTelemetryFallBack” is created running every 5 minutes. The goal of the task is to simply execute the Dism.exe process which was copied into C:\ProgramData. This then executes the main DLL payload (DismCore.dll).
DLL sideloading & analysis of DismCore.dll
The DllGetClassObject function is a standard entry point for COM objects, and it is likely the function called by dism.exe as part of the DLL sideloading attack. When dism.exe loads the malicious DLL (due to the path hijacking), it will search for and call DllGetClassObject if it’s present. This function is commonly used to retrieve an object that can create or manage COM objects for the DLL.
DismCore.dll: obfuscation and junk code
The variables referenced in the function below (rclsid, riid, and ppv) represent the parameters passed to this function, as per the standard COM API DllGetClassObject. These are typically used to retrieve a class object that can create an instance of a specified class.
The function includes obfuscated loops, conditional checks and other various string comparisons.
The comparison logic involving DAT_180044ac0 and a long, meaningless string suggests the use of “junk code” to confuse analysts.
Figure 14: decompiled pseudocode – obfuscation found in DismCore.dll analysis
Next, we observed obfuscation and manipulation of memory using bitwise shifts and type casting. Variables such as (uStack_6e0) are split into smaller segments, potentially to obscure their values and reconstruct them later. This pattern is common in malware to complicate analysis by spreading out meaningful data into less recognizable pieces. Also, as seen above, the initialization of local_3d8 further supports its use as a structured container for manipulated variable contents.
DismCore.dll: core task and response handling
This segment below shows how the malware handles specific tasks or responses. The condition checks for a special value (0x8000000000000000), which appears to represent an error or state code, and calls a function (FUN_180030036) to process the data. This is indicative of command-response mechanisms, potentially used in malware to handle instructions from a remote Command and Control (C2) server.
Figure 15: decompiled pseudocode – handling and response of specific conditions
The block of pseudocode below shows the decision-making based on the state of specific variables (local_618 for example). The function attempts to parse structured data in JSON-like arrays ([) or objects ({). These conditional branches indicate that the program processes input or commands in a serialized format. This parsing logic is likely critical for its primary operation, whether it be related to task execution or data processing.
Figure 16: decompiled pseudocode – handling of JSON formatted data
C2 traffic analysis
With the malicious code libraries loaded into the Dism.exe process from DismCore.dll, we observed the process attempting communication to the attacker’s C2 server found at hxxps://siasat[.]top/data. The process issued a series of POST requests.
Approximately 12 hours after initial infection, these POST requests were received with an answer.
Both request and response were encoded in order to blend into normal HTTPS traffic making network-based detections difficult.
The initial request sends a large Base64 encoded string to the attacker’s C2 server. Decoding the Base64 of the initial request, we found it contains a unique UUID which is used by the attacker to identify the machine or session. The rest is encrypted which we were unfortunately unable to analyze. Below is an example of a captured request and a response
Request: MmM1Nzg0NTMtYzgwMC00MTA4LWIyMDctMjE4ZGNjZTI5N2U0kMUkWUlTRJ0w8pKpgVC1vfdqJk3S+YdXpv1qL8UQRCagl+3OmbAx7wuI ...[TRUNCATED]... HiV9GH26mmNaZpOBeteGgKEyoc+1mwT6QQ
Response:
MmM1Nzg0NTMtYzgwMC00MTA4LWIyMDctMjE4ZGNjZTI5N2U0o1MRy24S2++M/3p/rBVKcMP6Pyr39XVQPk9PEhb7T1WKSS8R9QfoKrWqwv .....[TRUNCATED].... rZ/2nQ1NlwJbrqhn39PiLmOw47brLsSz+bw==
Some of the responses were massive in size, suggesting that the attackers were able to successfully exfiltrate data from the victim’s machine. The attackers had “hands on keyboard” for approximately another 12 hours on the victim machine before the connection was disrupted, making the total timeline between initial infection to connection close to about 24 hours in total.
Wrapping up…
The FLUX#CONSOLE campaign highlights the persistent use of modern obfuscation techniques in malware development. From the highly obfuscated JavaScript used in the initial stages to the deeply concealed malware code within the DLL, the entire attack chain exemplifies the complexities of detecting and analyzing contemporary malicious code. This campaign serves as a reminder of the evolving tactics employed by threat actors and the growing challenges faced by defenders in mitigating these sophisticated threats.
When it comes to evolving tactics, another notable aspect of this campaign is the exploitation of MSC files as a potential evolution of the classic LNK file which has been popular with threat actors over the past few years. Like LNK files, they also allow for the execution of malicious code while blending into legitimate Windows administrative workflows. This approach, combined with the use of highly obfuscated JavaScript to deliver a malicious sideloaded DLL stress the importance of robust endpoint monitoring solutions that are capable of adapting quickly to the rapidly changing threat landscape.
The overall impact of the FLUX#CONSOLE campaign allows for stealthy and persistent access to the victim’s computer. While the attack was disrupted 24 hours after initial infection, with full access, the threat actors would theoretically have been able to gather and exfiltrate data or enumerate other systems and move laterally.
Victimology and attribution
The attacker’s entire infrastructure was hosted using the domain siasat[.]top. At the time of publication the network appears to have been taken offline, or is now operating under a different domain. The single domain is hosted behind Cloudflare’s network which makes the gathering of infrastructure related metadata difficult.
We believe that Pakistan was the primary target of this campaign based on the lures and wording used in the documents and filenames. While there have been several APT groups that continuously target Pakistan such as Sidewinder, Gamaredon and Lazarus Group, none of the TTPs found in the FLUX#CONSOLE campaign align with any known TTPs from past campaigns from what we were able to identify.
Securonix recommendations
- As this campaign likely started using phishing emails, avoid downloading files or attachments from external sources, especially if the source was unsolicited. Malicious payloads from phishing emails can be delivered as direct attachments or links to external documents to download. Common file types include zip, rar, iso, and pdf.
- As .msc files were leveraged, look for unusual child processes spawning from the legitimate Windows mmc.exe process.
- Monitor common malware staging directories, especially script-related activity in world-writable directories. In the case of this campaign the threat actors staged their operations out of the:
C:\ProgramDatadirectory. - We strongly recommend deploying robust endpoint logging capabilities to aid in PowerShell detections. This includes leveraging additional process-level logging such as Sysmon and PowerShell logging for additional log detection coverage.
- Securonix customers can scan endpoints using the Securonix hunting queries below.
MITRE ATT&CK Matrix
|
Tactics |
Techniques |
|
Initial Access |
T1566.001: Phishing: Spearphishing Attachment |
|
Command and Control |
T1071.001: Application Layer Protocol: Web Protocols T1132: Data Encoding T1572: Protocol Tunneling |
|
Defense Evasion |
T1027: Obfuscated Files or Information T1027.010: Obfuscated Files or Information: Command Obfuscation T1036: Masquerading T1036.007: Masquerading: Double File Extension T1218: System Binary Proxy Execution T1218.014: System Binary Proxy Execution: MMC T1574.001: Hijack Execution Flow: DLL Search Order Hijacking |
|
Execution |
T1059.003: Command and Scripting Interpreter: Windows Command Shell T1059.007: Command and Scripting Interpreter: JavaScript T1204.002: User Execution: Malicious File |
|
Persistence |
T1053.005: Scheduled Task/Job: Scheduled Task |
|
Exfiltration |
T1041: Exfiltration Over C2 Channel |
Relevant Securonix detections
- EDR-ALL-1245-RU
- EDR-ALL-1294-RU
- WEL-ALL-1205-RU
- WEL-ALL-1253-RU
- EDR-ALL-1343-RU
Relevant hunting queries
(remove square brackets “[ ]” for IP addresses or URLs)
- index = activity AND rg_functionality = “Next Generation Firewall” AND (destinationhostname CONTAINS “ewh.ieee[.]org/reg/ccece15/files/ccece-word-sample.pdf” OR destinationhostname CONTAINS “siasat[.]top”)
- index = activity AND rg_functionality = “Endpoint Management Systems” AND (deviceaction = “File created” OR deviceaction = “File created (rule: FileCreate)”) AND customstring49 ENDS WITH “\\ProgramData\\Dism.exe”
- index = activity AND rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create” OR deviceaction = “Process Create (rule: ProcessCreate)” OR deviceaction = “ProcessRollup2” OR deviceaction = “Procstart” OR deviceaction = “Process” OR deviceaction = “Trace Executed Process”) AND customstring49 ENDS WITH “\\ProgramData\\Dism.exe”
C2 and infrastructure
|
C2 Address |
|
siasat[.]top |
|
hxxps://ewh.ieee[.]org/reg/ccece15/files/ccece-word-sample.pdf |
Analyzed files/hashes
|
File Name |
SHA256 |
|
ARRVL-PAX-MNFSTPK284-23NOV.pdf.msc |
b3b2d915f47aa631cc4900ec56f9b833e84d20e850d78f42f78ad80eb362b8fc |
|
d9y3d2t7-jt32-s32s-kechw1297245.tmp |
b33d76c413ef0f4c48a8a61cfeb5e24ff465bbc6b70bf0cada2bb44299a2768f |
|
IEEE-Template-.pdf |
F6C435A9A63BDEF0517D60B6932CB05A8AF3B29FC76ABAFC5542F99070DB1E77 |
|
income.pdf Income-Tax-Deduction-and-Rebates202441712.pdf |
5756F6998E14DF4DD09F92B9716CFFA5CD996D961B41B82C066F5F51C037A62F |
References:
- Github: grimresource.msc
https://gist.github.com/joe-desimone/2b0bbee382c9bdfcac53f2349a379fa4 - GrimResource – Microsoft Management Console for initial access and evasion
https://www.elastic.co/security-labs/grimresource - SideWinder Uses Server-side Polymorphism to Attack Pakistan Government Officials — and Is Now Targeting Turkey
https://blogs.blackberry.com/en/2023/05/sidewinder-uses-server-side-polymorphism-to-target-pakistan - PTA Report Reveals Surge in Cyber Attacks, APT Threats in Pakistan’s Digital Sector
https://propakistani.pk/2024/11/12/pta-report-reveals-surge-in-cyber-attacks-apt-threats-in-pakistans-digital-sector/
Appendix A: [Python script] Obfuscated JavaScript decoder (for DLL)
import os
import base64
def reverse_string(input_str):
return input_str[::-1]
def decrypt_string(input_str):
return input_str.replace(‘$’, ‘4’).replace(‘!’, ‘1’)
def sanitize_hex_string(hex_string):
return ”.join(filter(lambda c: c in ‘0123456789abcdefABCDEF’, hex_string))
def hex_decode(hex_string):
return bytes.fromhex(hex_string)
def base64_decode(base64_string):
return base64.b64decode(base64_string)
def save_to_file(file_path, data):
with open(file_path, ‘wb’) as file:
file.write(data)
def main():
# Obfuscated string
obfuscated_string = “[put JavaScript string here]”
reversed_string = reverse_string(obfuscated_string)
decrypted_string = decrypt_string(reversed_string)
sanitized_hex_string = sanitize_hex_string(decrypted_string)
if len(decrypted_string) != len(sanitized_hex_string):
print(f”Sanitized invalid characters… Original length: {len(decrypted_string)}, Sanitized length: {len(sanitized_hex_string)}”)
binary_data = hex_decode(sanitized_hex_string)
final_binary_data = base64_decode(binary_data.decode())
output_file = os.path.expanduser(“~/output.bin”)
save_to_file(output_file, final_binary_data)
if __name__ == “__main__”:
main()
