_Overview

Diamotrix is a malware that first emerged in mid-2024 and remains active today. It specializes in cryptocurrency-based clipboard hijacking and can be classified as a Crypto Clipper. Unlike other clippers that operate in a more indirect manner, this malware focuses most of its activity on replacing cryptocurrency wallet addresses copied to the clipboard. Diamotrix has been observed in campaigns alongside various stealers and loaders, sharing infrastructure and infection chains with malware such as SVCStealer, Lumma, and Rhadamanthys. As a result, some analyses have also categorized it as part of multi-payload operations focused on financial fraud and information theft.

The malware is typically distributed alongside other loaders or is invoked by other stealer, making it commonly associated with phishing campaigns, fake installers, cracked applications, and similar delivery mechanisms. It has a wide range of infection vectors due to its operational integration with other malware families, serving in most cases as a tactical complement to other malicious software. The most common combination in terms of infrastructure or execution chain is its association with SVCStealer, in what could be described as a dropper-as-a-service model, where threat actors distribute common malware bundles through a single execution flow. SVC and Diamotrix are often treated as the same malware in signatures because of their communication patterns and the way their activities typically complement each other. However, they are two distinct malware families that may simply share a common origin or opportunistic infrastructure.

As mentioned previously, Diamotrix has appeared in a large number of campaigns over recent years, usually alongside all kinds of loaders, droppers, and stealers. During my research, I observed this malware being deployed by, or participating in the execution chains of, StealC, Rhadamanthys, TinyLoader, Amadey, RedLine, Lumma, and, of course, SVC. These relationships within large-scale Malware-as-a-Service (MaaS) campaigns are evident, with threat actors purchasing access to deploy it through droppers such as Optimal Dropper, and others. In other cases, it may be dropped or extracted during the execution of other stealers, but it is extremely rare to encounter Diamotrix operating entirely on its own.

_Technical Analysis

As mentioned earlier, the way the execution chain begins varies significantly, as Diamotrix can be launched by droppers, loaders, and other stealers. During the investigation, the majority of identified samples originated from cracks or various types of software that ultimately served as the starting point for the execution of multiple malware families, eventually leading to Diamotrix.

The way this malware operates is relatively straightforward and appears fairly clean from a telemetry perspective. It injects itself into explorer.exe, where it establishes an infinite loop after hijacking the clipboard. Everything copied to the clipboard is evaluated to determine whether it is a cryptocurrency wallet address. If a match is found, the address is replaced with one stored in memory or predefined by the malware. While the concept appears simple, the underlying implementation is more complex than it initially seems and remains well concealed from casual observation.

The following diagram summarizes the findings of the Diamotrix investigation, based on dozens of analyzed samples that were consolidated to provide a clearer understanding of its behavior:

To understand how Diamotrix operates and how it relates to its surrounding ecosystem, dozens of samples were collected and analyzed in order to study its modus operandi. As previously noted, it is virtually impossible to find this malware without some form of association with another threat. Therefore, it is necessary to examine those related malware families before reaching Diamotrix itself, with particular attention given to SVCStealer, which shares infrastructure with Diamotrix in the majority of observed cases.

In both SVC and Diamotrix, the initial stage is most commonly the result of being dropped by another malware family, whether a loader, dropper, or stealer. As a result, multiple payloads may be executed sequentially. Through an email, a YouTube video, a link, or a file masquerading as something legitimate, victims can unknowingly receive an entire malware bundle. A clear example is the use of TinyLoader to deploy several complementary malware families that ultimately lead to the execution of Diamotrix.

Another example, and probably one of the most widespread, is the use of cracks or fake applications posing as updates or new software versions. These often come with hidden payloads and may contain droppers or stealers that later work in conjunction with Diamotrix.

In some cases, we can encounter tools such as those mentioned earlier that share the same infrastructure and communicate with the same C2 server. This means that one malware family can lead investigators to another, highlighting how certain IP addresses are reused across different portals and malware operations, information that later becomes valuable during pivoting activities.

There are also dozens of phishing domains that have communicated with a wide range of malware families that eventually lead to Diamotrix. The trail associated with initial access is extensive, with as many entry points as there are motivations and droppers to investigate.

Once a victim falls for any of these initial access techniques, a wide variety of malware families may be encountered, as discussed previously. For this reason, and perhaps unusually, I believe it is easier to analyze Diamotrix first in order to understand all aspects of its functionality before examining its relationships with other malware. Among those related threats, the most relevant by far is SVC, as it appears in the majority of execution flows where Diamotrix is present.

_Diamotrix

During the analysis process, which involved several weeks of examining different Diamotrix variants and builds, one thing became clear: in most cases, the malware is either triggered by an external loader, packed, or deployed by another malware family. It is uncommon to encounter scripts responsible for executing preliminary stages or similar mechanisms. Typically, the payload is dropped into a directory and then executed directly or invoked by another process.

The binary is usually a 64-bit C++ executable, with a size generally ranging between 100 KB and 300 KB.

Regarding visible dynamic behavior, I analyzed a wide variety of samples to determine whether any of them exhibited significantly different visual characteristics. In practice, what we usually observe is explorer.exe executing the sample, while everything else, excluding file creation or persistence mechanisms, takes place in memory. There is nothing particularly striking from a visual standpoint, but the approach is practical and complicates detection, since no new processes appear to be making suspicious requests or displaying anomalous behavior at the process level.

In many samples, the first stage involves privilege escalation by enabling the well-known SeDebugPrivilege, which allows the malware to access protected processes and perform the injection routines that will follow later in the execution chain.

It then performs mutex creation and validation routines, preventing reinfection and, depending on the implementation, determining whether the user has already executed the malware in order to terminate execution if necessary.

Following this, a persistence routine is typically established. The destination folder may be assigned either a random name or an identifier calculated beforehand, although the naming convention varies across samples. In some cases, the malware deliberately selects names designed to blend into the operating system environment, such as “services”, which is then used when creating a new registry entry. The most commonly abused registry location for this purpose is:

Software\Microsoft\Windows\CurrentVersion\Run

Both the directory and the file itself, which is simply a copy of the original binary created through CopyFileW, are marked as hidden. This is intended to prevent users who do not have hidden files enabled from seeing the file responsible for persistence, which will be executed during every system startup cycle

Across the analyzed samples, persistence through registry key abuse is by far the most common technique. Unless a preceding loader or dropper establishes persistence through scheduled tasks or other mechanisms, Diamotrix generally relies on registry-based persistence.

The malware then selects the process it intends to inject into, which in most cases is explorer.exe. It performs a routine commonly used to determine whether the target process is already running and, in some variants, whether anti-analysis tools are present. This is achieved by capturing a snapshot of running processes using CreateToolhelp32Snapshot and iterating through them with the Process32First and Process32Next APIs. In this particular case, and in many others, the primary objective is simply to verify that the target explorer.exe instance is running as a 64-bit process through IsWow64Process. As mentioned previously, the Diamotrix payload is x64, so it ensures that the target explorer process is also x64 before proceeding.

I also encountered other binaries containing preliminary stages that used the same process enumeration technique, but with the objective of identifying applications commonly associated with reverse engineering or malware analysis.

Once these checks are completed, the malware has everything required to perform the reflective DLL injection process. Instead of relying on LoadLibrary, it writes the entire PE image into the target process memory and creates a remote thread using CreateRemoteThread in combination with WriteProcessMemory. Before doing so, Diamotrix’s pseudo-loader manually parses the PE structure to locate the ReflectiveLoader export, obtaining the address of the function responsible for manually loading the DLL inside explorer.exe. It then calculates the actual address of the export within the remote process and starts execution through the newly created thread. The reflective loader subsequently reconstructs the PE image in memory and prepares the DLL for execution

Within the binary extracted from memory, this export can be observed performing the following tasks:

1. Locating the PE base address in memory
2. Resolving kernel32.dll and ntdll.dll through the PEB
3. Resolving required API functions
4. Allocating new memory regions
5. Copying PE headers and sections
6. Resolving imported functions
7. Applying relocation entries
8. Invoking DllMain

As shown previously, once the library has been injected into the running explorer.exe process, it is possible to observe a module corresponding to the payload that was previously identified in memory.

At this point, the actual Diamotrix payload begins execution

The execution flow continues entirely within explorer.exe memory space. The original process responsible for launching the payload terminates, and execution is effectively transferred to the injected code.

On many occasions, I have encountered Diamotrix samples that only contained the payload component and lacked the initial stage. While this can be useful for signature development and isolated analysis, it creates difficulties when attempting to understand the full set of TTPs employed throughout the execution chain, as the initial stage is responsible for persistence, privilege escalation, and several other behaviors that are essential for understanding the malware as a whole.

After extracting and analyzing multiple samples, the reality is that they are remarkably similar to one another.

The Diamotrix payload typically begins with a mutex. Yes, another mutex. While its name varies between samples, its purpose remains the same as previously described

The bulk of the payload executes within a separate thread created to handle multiple tasks. Diamotrix repeatedly executes a function in an infinite loop, which is responsible for carrying out all of the malware’s core functionality.

After creating the thread that hosts the primary routine on which the malware is built, it proceeds with loading libraries and resolving imports. This stage is quite common not only in Diamotrix but also across many malware families, as it helps evade detection mechanisms that rely on import-based signatures or specific combinations of imported functions.

In this case, Diamotrix follows the well-established LoadLibraryA + GetProcAddress approach, dynamically loading the libraries and functions it requires. This capability is essential for mapping additional functionality at runtime.

The difference becomes more apparent once all libraries have been loaded, as the malware acquires access to components providing a wide range of capabilities. Some of the most relevant include:

• Keyboard monitoring and management (msctf.dll)
• Character composition and input method handling (imm32.dll)
• International font, layout, and text rendering support (lpk.dll)
• Access to Windows graphical components, useful for screenshot-related functionality (gdi32.dll)

Following this stage, the malware begins monitoring keyboard activity, arguably the most critical point in the execution flow, as it serves as the entry point to the main loop and the management of any new user input. At this stage, the malware performs the OpenClipboard + GetClipboardData routine to access and lock the clipboard, followed by a GlobalLock call to obtain a pointer to the clipboard contents. This allows it to determine whether the clipboard contains data, whether it is empty, and to store the contents for later comparison.

Every clipboard string examined by the malware is evaluated. If the content does not correspond to a cryptocurrency wallet, execution immediately jumps to the end of the loop and begins again. The execution flow only becomes relevant once a wallet address is identified.

The following functions are responsible for determining whether the clipboard string corresponds to a valid cryptocurrency wallet. The binary loads a collection of regular expressions and replacement wallet addresses, which depending on the sample may either be extracted dynamically from memory or remain statically embedded within the binary. In the more sophisticated Diamotrix variants, the former approach is used, and the malware applies different regular expression patterns depending on the wallet technology being analyzed

BTC
\b(1|3|bc1)[a-zA-HJ-NP-Z0-9]{25,42}\b

ETH
\b0x[a-fA-F0-9]{40}\b

TRON
\bT[a-zA-HJ-NP-Z0-9]{33}\b

LITE
\b(L|M)[a-zA-HJ-NP-Z0-9]{26,34}\b
\bltc1[a-z0-9]{25,90}\b

DOGE
\bD[a-zA-Z0-9]{32,34}\b

The most important validation function relies on a switch-based logic structure that applies different validation routines depending on the identified pattern type. Combined with the regular expressions, this allows the malware to determine the technology associated with the clipboard wallet address, such as BTC, ETH, and others.

Once validation is complete, the malware selects the replacement wallet that will overwrite the address currently stored in the clipboard and saves the selected candidate in memory. This process is performed through an internal state mechanism based on backtracking and incremental evaluation, creating the appearance of block-by-block processing. As a result, the wallet string may appear to be processed in sections during analysis.

Being even bigger geeks, the process also leverages the Levenshtein distance algorithm. This mechanism is not used to modify the victim’s wallet address directly but rather as an internal scoring system for comparing candidate replacement wallets during the selection process. Since multiple wallets may be available for a given cryptocurrency type, this function helps determine the most suitable replacement

The final outcome is the selection of one of the malware’s predefined wallet addresses corresponding to the same blockchain technology as the original address, whether BTC, ETH, or another supported cryptocurrency

The wallets observed during the investigation showed considerable activity, and every address I tested throughout the various analyses had remained active within recent months

Once the replacement address has been selected, the only remaining step is to replace the original clipboard content with the newly assigned wallet. The malware performs a strcpy operation and, following the same clipboard access mechanism described previously, reopens the clipboard and writes the replacement string already stored in memory.

After multiple validation checks and safeguards, the entire process operates extremely quickly. Once the malware enters its monitoring loop, wallet replacement occurs within fractions of a second whenever a cryptocurrency address is detected, immediately passing through the workflow described above

As mentioned previously, Diamotrix is not a particularly large or feature-rich malware family. Its functionality is generally intended to support a broader malicious objective. When investigating this malware in isolation, identifying network communications can be challenging because it is typically bundled with other malware families that complicate the overall picture. Given that SVC is the malware most closely associated with Diamotrix, both from a signature perspective and due to its presence in the majority of observed execution chains, I decided to examine it in greater depth to determine whether Diamotrix was embedded within it or systematically spawned from memory during execution.

_SVCStealer

As for SVCStealer, it is malware that, as its name rather conveniently suggests, is focused on information theft. It has been active since late 2024, which aligns quite well with the earliest observed activity associated with Diamotrix. The delivery mechanism is also very similar to what has already been discussed, with victims typically being infected through loaders, droppers, and related malware families.

I am not going to spend too much time on its internal operation because, while I was in the middle of my own analysis, I realized that not long ago Phatcharadol Thangplub had already done an excellent job covering it. Although I analyzed several samples with the same level of rigor applied to Diamotrix, I will spare you every last detail. His analysis is excellent, very recent, and well worth reading.

Like many malware families, SVC begins with mutex-related routines. I was genuinely surprised by how many samples reused the exact same mutex or only minor variations of it

Afterward, it creates files using a specific UUID, allowing it to mimic a legitimate application directory, most commonly within ProgramData.

At this point, much like Diamotrix, it moves into dynamic library loading in order to expand its capabilities.

Unlike Diamotrix, however, SVC routinely performs checks for a wide range of reverse engineering and malware analysis tools. This actually reinforced my suspicion that it serves as a complementary component within a broader operation, because despite being a fairly technical malware family, Diamotrix itself rarely includes these types of protections. SVC also tends to delegate these checks to a separate thread.

From there, it selects another working directory, usually within AppData, commonly under Roaming, and creates individual folders for each category of information it intends to steal, such as browser data, cryptocurrency wallets, and other artifacts. Naturally, the wallet-related functionality was the part that interested me the most.

Unfortunately, it does not implement functionality comparable to what we saw in Diamotrix. While it makes use of switch statements and follows similar logical structures, it is nowhere near the level of complexity observed in Diamotrix.

At this stage, we can observe how it iterates through each targeted data source and stores the collected information within the corresponding directories.

The final result is a consolidated collection of all harvested data stored within the ProgramData folder structure it previously created.

During this collection phase, SVC also captures a screenshot, which is stored in the same directory and later exfiltrated alongside the rest of the stolen information

In addition, it gathers information about the victim’s system and installed software, storing the results in TXT files. In my opinion, aside from browser-related information, this is probably some of the most valuable data it collects. It essentially inventories the entire system. While many stealers gather basic device and user information, SVC collects a surprisingly comprehensive profile of the victim’s environment

Another aspect that I found particularly interesting was the exfiltration process itself. Once data collection is complete, SVC creates a ZIP archive containing the entire directory structure it has built throughout execution.

The archive is then transmitted to an attacker-controlled server.

In most samples, identifying an active administration panel is difficult because the infrastructure rotates frequently. During the communication process, however, two PHP components consistently stand out:

• Data.php: Responsible for receiving the collected data and ZIP archive, while also forwarding a summary of the stolen information to the threat actor via Telegram
• Login.php: Used as the threat actor’s administration panel for monitoring incoming victims and stolen data

This was particularly interesting from the very beginning because, in many cases, the same site is used for both Diamotrix and SVC, as well as for other malware families. The infrastructure is frequently shared, and in some cases even the same PHP filenames responsible for delivering key information to the attacker are reused

_Laboratory

To better understand exactly what was being sent to the server and to examine the final stage of SVC’s operation, I went looking for the builder so I could analyze the process from the other side. Personally, I consider this essential when researching stealers and RATs. Fortunately, the well-known LLCPPC has a sample that allowed me to do exactly that.

The builder allows the operator to specify a domain or IP address, from which it derives a path and a PHP endpoint, typically get.php

The builder itself is fairly simple. Once these parameters are configured, it generates the binary, and it becomes possible to identify the configured domain directly within the string data

The overall functionality is identical. From a static analysis perspective there are, of course, some differences because this is not a pristine SVC sample but rather one embedded within a crack. Even so, the underlying behavior remains the same and the malware performs the same core functions.

Once execution reaches the final stage, we can observe the communication process and see exactly what is received on the server side.

At its core, the PHP script is simply responsible for receiving the ZIP archive, validating that the uploaded file is indeed a ZIP, retrieving the configured Telegram token, and using it to send the notification through Telegram

The result observed from the receiving side is simply a ZIP file containing all of the information stolen from the victim’s device, accompanied by a notification message

🔥 SVC STEALER: NEW LOG!

Naturally, the code can be modified, the message can be customized, and so on. However, this setup makes it very easy to validate the two PHP components mentioned previously, namely Login.php and get.php.

As for the wallet-related functionality, Diamotrix and SVC approach the problem differently. However, both are written in the same language, both begin their execution flow in a remarkably similar way, and their exfiltration mechanisms share a number of characteristics. In many cases, they even communicate with the same infrastructure, use the same PHP endpoints, and rely on the same destinations. Because of this, it is not difficult to understand why detection signatures sometimes classify them as the same malware family

_Infrastructure

Since I was already exploring the exfiltration side of both malware families, it seemed like a good opportunity to examine what they might have in common across the tangled web of interconnected servers in an attempt to identify additional points of overlap between them.

Starting from the same site that had been used for exfiltration and that we examined earlier, it was possible to identify multiple IP addresses sharing the same response body and following the same pattern. Some used random strings, while others literally contained references to “diamo” and, to absolutely nobody’s surprise, were related to Diamotrix.

Most of the cross-referenced communications eventually led back to login.php-style panels that had also been used to receive information through PHP endpoints with naming patterns such as get.php, data.php, or variations of them, not only for Diamotrix and SVC but also for other malware families such as Tiny

Beyond the response body itself, I also pivoted on infrastructure assets used by these kits. Once again, this led to addresses that had been associated with both Diamotrix and other malware families, often using different PHP naming conventions while maintaining the same underlying infrastructure pattern

In many cases, malware tags expanded significantly as additional context became available, with some infrastructure previously associated with Tiny, Amadey, Lumma, and other malware families. This suggests either the use of similar deployment patterns or the existence of multipurpose infrastructure being sold as part of broader service offerings. In practice, this can result in threat actors purchasing combinations such as SVC + Diamotrix or Tiny + Amadey, while the real point of contact between them is the infrastructure provided by whoever is operating the service. The malware operators themselves are often just customers of the ecosystem. In other words, one threat actor builds the platform and everyone else simply buys access to it and makes a few modifications. A classic MaaS model.

It is also possible to identify domains that have been used both for malware communications and for hosting administration panels, while simultaneously serving as download locations for the malware itself. As a result, some droppers appear to leverage the same infrastructure both to retrieve payloads and to support the communication channels later used by those payloads

On the Diamotrix side specifically, I identified numerous infrastructures using the “diamo” naming convention and following the same pattern observed with SVC: a login panel accompanied by a second PHP endpoint responsible for receiving data, typically data.php

Applying the same logic, it is possible to locate similar infrastructures associated with other malware families. Pony is a good example, as it frequently follows the same architectural model. This format is widespread across the ecosystem and sometimes overlaps with SVC and Diamotrix campaigns, while in other cases it is used in entirely unrelated operations.

Looking further back through historical infrastructure, I found evidence that some operators previously relied on infrastructure serving multiple purposes simultaneously, both for malware delivery and for command-and-control communications. At the same time, they also used domains rather than direct IP addresses

• Diamotrix.club
• Diamotrix.pack
• diamotrix.world
• Diamotrix.online

This pattern predates the current campaigns and illustrates a gradual shift toward more “universal” infrastructure models, which are now widely adopted across many malware families operating within the same ecosystem and increasingly overlapping with one another.

Another interesting point involves the PHP endpoints themselves. During Diamotrix communications, the overall structure is extremely similar to what is observed with SVC, although different endpoint names are used.

When trying to understand the differences and similarities between Diamotrix and SVC, I think the following summary captures the situation quite well:

PHP	Function
get.php	Upload ZIP/log
post.php	Beaconing / Registration
data.php	Status / Telemetry
login.php	Panel auth

To summarize and conclude, and before I disappear down yet another rabbit hole, because this has already become much longer than I expected (what a surprise), what seems to be happening is that shared hosting environments are often used to support multiple malware families simultaneously. During infrastructure pivoting alone, I encountered Pony, StealC, Tiny, Diamotrix, SVC, and several others. As we have seen, the naming patterns themselves are not particularly exotic. They either reference the malware family directly or rely on random strings, something that can be observed across dozens of MaaS infrastructures.

On the other hand, I do believe there are threat actors providing infrastructure through a common builder or management panel, as elements such as timestamps, PHP naming conventions, and deployment patterns are often identical. Does this mean that SVC and Diamotrix share the same origin? I do not think so. My impression is that this is more likely the result of an adversary offering malware and preconfigured infrastructure kits, with customers making only minimal changes. That said, I do believe there are operational links between Diamotrix and SVC, particularly in how they are deployed and how their capabilities complement one another.

_Detection Opportunities

• [TA0005][T1055.001] Reflective DLL Injection into Explorer.exe

(Process) Explorer.exe | Suspicious File > VirtualAllocEx + WriteProcessMemory + CreateRemoteThread > (Module Load) Explorer.exe loading unsigned DLL

• [TA0011][T1071.001] Outbound HTTP from Explorer.exe

(OutBound connection) From Explorer.exe > (Connection Anywhere) Port 80 | 443

• [TA0011][T1041] Request and external exfiltration to suspicious domains using PHP files

(OutBound connection) From injected explorer | Suspicious File > (Remote host pattern-Regex)  .*[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\/[a-z0-9]{3,10}\/[a-z0-9]{3,5}\.php

More restrictive
(OutBound connection) From injected explorer | Suspicious File > (Remote host pattern-Regex)  .*\/[a-z0-9]{3,10}\/(data|get|post|login)\.php

• [TA0003][T1547.001] Persistence using registries by Diamotrix

(Registry) *\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
(ValueData-Regex) \\AppData\\Roaming\\\w{18,22}\\.*\.exe

_TTP

[TA0001][T1566] Phishing
[TA0002][T1204.002] Malicious File
[TA0002][T1055.002] Portable Executable Injection
[TA0002][T1055] Process Injection
[TA0003][T1547.001] Registry Run Keys / Startup Folder
[TA0004][T1134] Access Token Manipulation
[TA0005][T1027] Obfuscated Files or Information
[TA0005][T1140] Deobfuscate/Decode Files or Information
[TA0005][T1036] Masquerading
[TA0005][T1036.005] Match Legitimate Name or Location
[TA0005][T1564.001] Hidden Files and Directories
[TA0005][T1055.001] Dynamic-link Library Injection
[TA0006][T1005] Data from Local System
[TA0006][T1115] Clipboard Data
[TA0007][T1480.001] Environmental Keying
[TA0007][T1497.001] System Checks
[TA0007][T1497.003] Time Based Evasion
[TA0008][T1573] Encrypted Channel
[TA0042][T1583.001] Domains

_IOC

62.60.226.159/zbuyowgn/login.php
62.60.226.159/xopbixc/data.php
158.94.208.102/diamo/login.php
196.251.107.61/diamo/login.php
176.46.152.47/diamo/login.php
178.16.53.7/diamo/login.php
77.90.153.62/diamo/login.php
85.208.84.41/diamo/login.php
176.46.152.46/diamo/login.php
185.156.72.89/nzcwzue/login.php
185.156.72.8/diamo/login.php
185.81.68.156/diamo/login.php
176.46.157.64/ioc/data.php
176.46.157.65/diamo/post.php
62.60.226.166/diamo/post.php
194.38.21.76/diamo/post.php
196.251.107.23/diamo/data.php
diamotrix.club/diamo/login.php
diamotrix.world/diamo/post.php

01f303cb85989ef20126e3f30e8d1509ab498c1950ecddd1a9e0f6d7f04183ac
Fedb5550c0513a9c02c134fb36be423509a9d89c17dac6443ce8865f1d9f8acf
9372b977f945b3024129c560096bf216c573dd673cd3564ada3f814a903146a1
da3df0178395eeffbc1a58409a099b63d73b585867fe17ca66ac1d9ea9e98690
1fb1ab4e3fd05fb92c7bf995874116caaf8c6522043f96e7819ca46040e29d65
6ee280efcad12a54fe6ab0dcf5db5f3b18658a9bce5c039cf0e1751804f5e617
Fc8197adf50313fa8d889ded2ed96600a9d946caa01448d21b207bfe94ccff0e
86b8e95a757e682c640e9d755c1e74db5911313821daea67e07b4fc0c403b940
539820d48e7c88cc5c21e2ed88b6f13943f0a0235bf01018055e222839ab90c7
Babb03c19dd9dac3d64432044a8c012b372e6550df19ada6a375f86e4e54ae6e
Bd261f3b2ff652cda344a9ec88731eaf1db858d54dcebe5ce0dddc3edffcae7c
C89c7ec770a47e7286c830a04d76762a78f697060a210699ff7d633516975035
B03b1a95a187a72f9cf31fe1ea742a7f168f4ba451f90a12e4ae3ee65c9e23a5
81997765ffabdaab5417720fd9202834a0cfef810b769f6a1300b0e32694e5cb
6ac38594d51647d07dcaaa9a6b6bde035143ec8fbc6505ed1da9370452d7d9f0
6f45f3e911dd8ac4574c61b11bf105d846a10b365e989e20b51c9b02137bf41d
c89c7ec770a47e7286c830a04d76762a78f697060a210699ff7d633516975035
10c05f9e11a9f5f3262e0d80e744fcf6fe3a1d0f59e76da0149b228de392f1f5
B343680787b950a9927bfb5c430c408566d0db86acd7725701fb90dae352fc50
Fd997d4409d123a29e694724b50365697c2df49442ad396ecea166e27af7e2e8
ba4bd66ba4fd69530fad78404e70818b7d86dc12969ae0bf877ea1eefb6aa360