PasivRobber: Chinese Spyware or Security Tool?

On March 13, 2025, our team found a suspicious mach-O file on Virustotal named wsus. After our initial analysis of this file and the package which installed it, we discovered over 20 related binaries used to capture data from macOS systems and applications, including WeChat, QQ, web browsers, email, etc. This multi-binary suite indicates a deep understanding of macOS and their target applications. The software’s targeted applications and other observed network connections strongly indicate both a Chinese origin and target user base. 

During our research, it was initially unclear whether this suite of applications was legitimate. The following reasons compelled us to dig deeper: 

• The main binary used for starting the suite is “goed,” which appears to be a misspelled version of Apple's legitimate geod daemon 
• The suite appears to query “com.apple.goed,” which does not exist in a clean install of macOS. This deceptive tactic makes the initial binary seem like it’s included in the macOS that Apple legitimately uses as a LaunchDaemon: com.apple.geod. Once goed is running, the software launches a wsus binary which appears to be using a well known acronym for Windows Server Update Services. The suite also obfuscates its plugin dylibs by using the file extensions ".gz" instead of ".dylib" 
• The suite attempts obfuscation through naming similarities and by hiding the initial package from the list of software when installed 

We felt that these irregularities merited further analysis of the suite, and our goal in this blog is to share the range of capabilities and behaviors observed during our analysis. Given the scale of this analysis, not all findings were covered and we may provide additional updates on interesting artifacts as analysis continues.

OSINT

Using open source intelligence (OSINT) methods, we first attempted to determine if this package was malware, enterprise-grade spyware, or a sophisticated forensic tool. We started this research with a closer analysis of the software’s potential targets and the parties likely responsible for its development. 

Multiple characteristics lead us to believe that, in addition to its probable Chinese origin, this software also primarily targets Chinese users. Our preliminary conclusion is based on the following data: 

• The software surreptitiously collects data from applications that are popular among Chinese users, including WeChat and QQ
• The macOS installer package had a Developer ID of “weihu chen,” and development paths had the name “Meiya”

Initial open source searches connected these identifiers to a Windows counterpart with the signature “Xiamen Huanya Zhongzhi Technology Partnership Enterprise.” Combining search criteria for “Xiamen Huanya Zhongzhi Technology Partnership Enterprise” and “Meiya” showed that the former had agreed to acquire a 20% stake in a company called “Xiamen Meiya Yian Information Technology Co” from “SDIC Intelligence Xiamen Information Co., Ltd.”

“Xiamen Meiya Yian Information Technology Co” and “SDIC Intelligence Xiamen Information Co., Ltd” are related to an organization called “Meiya Pico,” which, according to their website, develops forensic tools and other security products. Additional sources show prior evidence linking Meiya Pico to the “Chinese Military-Industrial Complex” and confirming their development of surveillance software.

A United States Treasury press release identifying “Eight Chinese Tech Firms as Part of The Chinese Military-Industrial Complex” stated the following:

“Xiamen Meiya Pico Information Co., Ltd. (Meiya Pico) operates or has operated in the surveillance technology sector of the economy of the PRC. Meiya Pico has developed a mobile application designed to track image and audio files, location data, and messages on ordinary citizens’ cellphones. Meiya Pico has also collaborated with other entities to develop a transcription and translation tool for the Uyghur language to enable authorities to scan electronic devices for criminal content. In 2018, residents of Xinjiang were required to download a desktop version of Meiya Pico’s surveillance software so authorities could monitor for illicit activity.”

Based on this research, plus their similar capabilities and sophistication level, we think it’s possible but not definitive that the software we discovered could be connected to Meiya Pico. These capabilities are detailed  throughout the following sections.

Installation Method

When researching the macho file named wsus, we found an installer pkg that was signed by “weihu chen (QPV7YX8YQ9).” The pkg contained 2 binaries: a “launchd plist,” and a secondary pkg that was not signed. The initial pkg’s preinstall script checks for the persistence LaunchDaemon, unloads it, removes the directory, and then forgets the package with `pkgutil –forget com.ament.pkg`. Once the initial pkg payload was on disk, the postinstall script verifies the system version to see if it was under macOS 14.4.1. 

If the device is under that version threshold, the postinstall script installs the program.pkg that actually holds the main payload, with its full suite of macho’s and dylibs. The secondary pkg verifies the CPU architecture and puts the appropriate binaries into /Library/protect/wsus/bin. The postinstall script will then attempt to move the ‘libIMKeyTool.dylib` into `/usr/lib/` then run `update_config` to pull current configuration files and create persistence with loading the LaunchDaemon.

LaunchDaemon

com.myam.plist
{
  "KeepAlive" => 1
  "Label" => "goed"
  "ProgramArguments" => [
    0 => "/Library/protect/wsus/bin/goed"
  ]
  "RunAtLoad" => 1
}

Due to the size of this application suite, we use diagrams throughout this post to provide summaries of each file involved. The suite has multiple binaries that spawn other binaries and load dylibs up to five deep. Due to the interdependent use of dylibs, and the depth in which it calls, we have dubbed this suite PasivRobber.

The name is an homage to the film Inception and its multi-level dream states employed to conduct espionage. PASIV is a reference to the box used in the movie to enter shared dreaming. The suite also uses a few dylibs with the moniker “Robber.dylib”, which we incorporated in the name. Below is a look at many of the main binaries and dylibs that are installed by the second PKG. We focus primarily on the three binaries that have the most interesting behavior: goed, wsus, and center.

goed

This executable is launched via LaunchDaemon after the installation of the second PKG. As seen in the diagram above, goed then executes wsus (in the same directory). The goed binary initializes the CManager class and executes the ThreadMsg() method to launch wsus while also printing its status to standard out.  

When debugging goed, we were able to confirm the fork and execution of wsus. Our analysis continues with an examination of what the wsus binary does. 

wsus

The binary launched by goed first prints out its status to standard out, and then proceeds to initialize and execute methods from the CRemoteMsgManager class. Given our prior analysis of this binary, we think wsus is primarily in charge of remote actions related to updates via FTP, uninstalls via RPC messages, etc. Below we summarize some of this functionality to help clarify the binary’s behavior.

We are most interested in the CRemoteMsgManager::Start() method, and that's where we’ll continue our analysis. Two pointers for functions related to the CRemoteMsgManagerImp class are passed to a method from the Boost library to set up a thread group. Let’s take a closer look at what these methods do. 

ThreadMsg & ThreadCheck

These two functions set up several important tasks handled by this binary at the start. Below is a summary of the key activities:

• At the start of ThreadMsg, we have a call to
  CRemoteMsgManager::CRemoteMsgManagerImp::CheckSP600Author() where a command string “ps aux | grep EESAuth” is passed to the ExecTerminal() function 
• We were unable to find what file this binary expects to run. The term SP600 is interesting since it’s similar to the build paths we found in both macOS and Windows variants, which may indicate a specific project with both SP100 and SP600

F:\\SP-100\\code\\EA-SP100\\Common\\Library\\Include\\boost/exception/detail/exception_ptr.hpp
/Users/meiya/Desktop/my_project/EA-SP100/dependence/IMKeyTool/IMKeyTool/IMKeyTool/QQHook.cpp

Looking at ThreadCheck(), we can see a query for the current user is checked against the root account by using the return from a function called GetLoginName(). GetLoginName() passes the command string:
“stat -f%Su /dev/console | tr -d \'\n\'” to an ExecTerminal() function which executes this command. The username returned by this command is then checked against the string “root.”

The next Start() method of interest is for CServerConnectMgr::Start(). This method executes the CServerConnectMgr::Init() method which results in other functions being called additional checks for connection related events. One interesting initialization that occurs due to this setup is for JsonAdapter::CClientAdapter::CClientAdapterImpl::Start() which provides details into the use of JSON and Protobuf for information sent via RPC. 

Continuing with CRemoteMsgManager::CRemoteMsgManagerImp::Init(), we want to highlight specific dylib usage that will shed light on additional functionality that is covered later. 

CRemoteMsgManager::CRemoteMsgManagerImp::InitDylib() is executed from the Init() method. 

This function creates the ‘/usr/local/lib” directory and will copy libIMKeyTool.dylib to the directory. This dylib is used later for capturing data from within Instant Messaging applications that we will detail. 

In a later section, we’ll dive further into how this dylib is used in a binary named “center.” 

Configuration Check

There are references to a file called WSUS.ini which appears to contain configuration information, including destination IP and port number. There is a check for this configuration data within CConfManager::Init(). Although we have found older .ini files on VT that are not encrypted, we do see evidence that Logs and .INI files are encrypted using TEA encryption. Fields which appear to be in this configuration file and are looked for include: Port, Ip, InstallTime, BackUpPort, and BackUpIp. 

Because this file seems to exhibit network-based behavior, we will focus on FTP and RPC communications next. 

Network Communications FTP and RPC Messaging

Inside of the function CRemoteMsgManager::CRemoteMsgManagerImp::DownUpdatePackage(), we can see a reference to obtaining FTP related information and a query to see if  /Library/protectect/wsus/bin.zip exists. FTP information is located within configuration that is loaded via a call to CConfManager::GetInstance() and stored at the address 0x1003c7cf0. We see references to this address throughout the binary for different property parsing of the configuration.

For FTP, a call to CConfManager::GetFtpInfo() is executed which returns data for the FTP server. Next, CFtpClientExportEx::DownLoad() is called, which uses the FTP setup to log in to the FTP server, pull down the ZIP file, and save it to the destination path /Library/protectect/wsus/bin.zip. After download, the update is handled by a function called
CRemoteMsgManager::CRemoteMsgManagerImp::Update(), which checks for the ZIP file and runs the unzip command to overwrite files. 

Wsus communicates via RPC and also executes some functions based on certain related strings passed as parameters. 

We will focus on two separate implementations: 

• CDynAnalyzeService
• CSystemService

Starting with CDynAnalyzeService::CDynAnalyzeServiceImpl::CDynAnalyzeServiceImpl(), we see several functions that match to RPC parameters including:

• GetSystemBaseInformation
• GetCurrentProcessInformations
• GetUninstallProgramInformations
• GetWindowServicesListInformations
• GetSystemInternetAgentInfos
• GetTopWindowsInfos
• GetNetShareInfos
• GetNetShareSessionInfos
• GetNetShareFileInfos
• GetClipboardInfos
• DynAnalyzeGetImPassword

Let’s focus our attention on the last one, DynAnalyzeGetImPassword(), since that function leads to an imported library that’s related to the extraction of keys for target Instant Messaging applications. 

DynAnalyzeGetImPassword via RPC results in the execution of
CDynAnalyzeService::CDynAnalyzeServiceImpl::ReadImPasswordInformations(). This is a long function so we will summarize what it does below. First, there is a check to see if “../Temp/IMKey.json” exists. This string is appended to the current working directory. If it does, then it reads the keys stored in this JSON file. If not, it proceeds to capture keys from popular applications used in China. Let’s look further at exactly what’s captured. 

The username is queried with the GetLoginName() function we covered previously. This is then appended with additional strings to get a target path for /Users/<username>/Library/Caches/ and /User/<username>/Library/Containers/. After this setup, plists for known IM applications are used for targets.

A file “com.tencent.qq/Data/Library/Caches/kntqq.txt” related to QQ is also targeted and then passed to a function called ReadAndUpdateIMKey() which is used to read keys from the plist files. 

These are implemented in CSystemService::CSystemServiceImpl::CSystemServiceImpl() and include:

• GetLoginVerify
• GetNetStatus
• RemoteUninstall
• SetLogLevel
• GetConnectInfo

Most of these return corresponding information stored in the configuration data. However, we will focus on the RemoteUninstall call below to see how the uninstall is handled. 

Uninstall and Cleanup Process

Within the CInstallProgress class, there is an interesting method called
CInstallProgress::CInstallProgressImp::Uninstall(), which can be used to uninstall the related binaries from the machine. 

As seen above, system() is passed rm commands to remove the plist that launches goed, and to remove the entire /Library/protect directory. This behavior continues with terminating associated processes. 

Screenshot Utility

The last wsus capability we’ll cover in this piece is the ability to take screenshots. This function is handled with the use of the CScreenShotService class and related methods. The service also appears to leverage RPC and we can see the implementation details within
CScreenShotService::CScreenShotServiceImpl::GetScreenShot().

The function first checks the value of the global variable _bRootUser to see if the user account is root. Then it executes the CScreenMonitor::CaptureScreen() function which executes the
ScreenCapture::ScreenCaptureLite::CaptureScreen() function. The Core Graphics framework is used within this function to create a capture, and is written in Objective-C. 

center

We’ll now take a deeper look into a binary called “center,” which handles many on-device actions and behaves like an agent. This binary starts out by using the std::__put_character_sequence<char>() function, which prints out several values to cout, including center “strComputerGuid:”, “center :”, “center strIP:” and others. It then initializes a class by calling
CAgentManager::Init() which calls CAgentManager::CAgentManagerImp::Init(). 

This Init() method calls Online::CQuickAnalyze::GetOperateSystemInformation() and also passes a sysctl command to popen(), and the output is used later. Let’s continue within
Online::CQuickAnalyze::GetOperateSystemInformation() to understand how it’s used. This function passes several commands for system information to a function called
Util::CallTerminal(), which uses popen() to execute the commands. 

Values captured from these commands are used later, but another command string “system_profiler SPHardwareDataType” is passed to a function called Util::GetSystemInfo(). This command is executed using another call to popen() and the string “Model Name” is used to parse the output for the endpoint model. After all this collection, it references an AgentLog file that appears to be used for logging the activity performed by this binary.

Similar to what we observed in wsus, this binary also has a class named CAgentManager showing different implementation calls, including the following interesting methods: 

• CAgentManager::CAgentManagerImp::ThreadMonitorWrap()
• CAgentManager::CAgentManagerImp::ThreadCollectWrap()
• CAgentManager::CAgentManagerImp::ThreadHeartbeatWrap()
• CAgentManager::CAgentManagerImp::InjectIMThd()
• CAgentManager::CAgentManagerImp::KillIMAndInjectIMThd()
• CAgentManager::CAgentManagerImp::ThreadSyncIMKey()
• CAgentManager::CAgentManagerImp::ThreadSyncIMKeyStatus()
• CAgentManager::CAgentManagerImp::ThreadReportTaskLogWrap()

We will provide a quick summary for most of these below. 

CAgentManager::CAgentManagerImp::ThreadMonitorWrap()

This calls the similarly named function CAgentManager::CAgentManagerImp::ThreadMonitor() 

It starts with a call to sleep() using the boost library (which is used throughout all the related binaries in this threat). The function Online::CQuickAnalyze::GetSystemStatusInformation() is then called, which uses mach ports to query virtual memory stats from the endpoint.

Values captured from this and other calls like fstat(“.”) are then written to the AgentLog using the WriteLog method previously covered. CAgentManager::CAgentManagerImp::SendComputerStatus() is then executed. This function passes certain values to the Utility::CPropertyParse::AddValue() function including CMD_COMPUTER, ComputerStatus, CaseGuid, ComputerID, etc. - which reflect the captured information. The purpose of one value queried by this function is to obtain the currently logged in user by calling the function we covered before, GetLoginName(). 

After these values are added, there is a call to CMsgCenterClient::SendData() which sets up a JSON object and communicates via RPC. The conversion of JSON objects, including system information, are passed through methods of the google::protobuf class to facilitate this communication via RPC using calls to rpc::RpcRequestControl::CallWithoutResponse().

CAgentManager::CAgentManagerImp::ThreadCollectWrap()

The most interesting activity related to this function is the use of a UTF-32 string “yacebb889c20b6e8b,” which is seen being passed to a method FileSystemPathAppend() after a call to GetCurrentDir(), appearing to indicate the creation of a file within the currently working directory of this binary. 

CAgentManager::CAgentManagerImp::ThreadHeartbeatWrap()

This wrapper function writes to the AgentLog and executes CMsgCenterClient::SendHeartbeat() which calls JsonAdapter::CClientAdapter::SendHeartbeat(). This is then used in an RPC message to send a heartbeat: {"CmdType":"CMD_HEART_CHECK"}. We document other observed Command Types below. 

CAgentManager::CAgentManagerImp::InjectIMThd()

This function’s name suggests it injects Instant Messenger apps, but let’s take a closer look at the capabilities. 

After the setup of injection-related configuration, there is a call to a function named CAgentManager::CAgentManagerImp::InjectApp(). This then uses another binary called “apse” to inject libraries into the Instant Messaging applications QQ and WeChat. 

Analysis of the apse application that came bundled into the installed package has similar code seen in https://github.com/zhangkn/insert_dylib-1. The build path for the apse binary also shows the use of this:

/Users/meiyameiya/Downloads/insert_dylib-master/insert_dylib/

Below are the target applications and the versions that are used to compare. 

• WeCom (WeChat Enterprise) - DoInjectWecomEx() - Version 3.1.19
• QQ - DoInjectQQEx() - Version 6.7.9

WeChat injection appears to be handled by targeting a framework called WCDB.framework/Versions/A/WCDB. We see a call to apse is set up and passed to a function called CAgentManager::CAgentManagerImp::DoProgramInjectCmd().

There are different apse commands depending on the target:

CAgentManager::CAgentManagerImp::DoInjectWechatEx():
%s @executable_path/../Frameworks/%s "%s" --inplace --weak --all-yes
CAgentManager::CAgentManagerImp::DoInjectQQEx():
%s @rpath/%s "%s" --inplace --weak --all-yes
CAgentManager::CAgentManagerImp::DoInjectWecomEx():
%s @rpath/%s "%s" --inplace --weak --all-yes

After the injection of target apps are completed by apse, there is a call to sign the applications,
CAgentManager::CAgentManagerImp::DoProgramSelfCodesign().

CAgentManager::CAgentManagerImp::KillIMAndInjectIMThd()

This function first creates a power notification listener using IOKit. 

The function MySleepCallBack() will execute when this listener observes a power state change. Verifying checks for certain power state responses, we can see what events lead to which behaviors. 

Setting arg3 as the iokit_common_msg variable allows us to see references to this variable and to what these events correspond by looking at the IOMessage.h header file. 

0x280 = kIOMessageSystemWillSleep

0x320 = kIOMessageSystemWillPowerOn

Most of the injection activity occurs as a result of the sleep event which matches the name of this function. When the system goes to sleep, it targets IM applications and sends the kill command, which starts an injection process after a check for a json file is completed. 

Before we wrap up the center binary, let’s revisit the libIMKeyTool.dylib related to the target applications. 

Within the CAgentManager::CAgentManagerImp::GetImKeyThd() function, there is a call to verify the status of System Integrity Protection (SIP) called CAgentManager::CAgentManagerImp::VerifySip(). This executes the command “csrutil status| grep enabled” and returns a 0 if it is enabled. 

If SIP is disabled, then it would execute the functions related to the extraction of keys. 

Each of these key related functions will call the corresponding function within the libIMKeyTool.dylib. 

CAgentManager::CAgentManagerImp::GetIMQQKey() - > _GetQQKey()
CAgentManager::CAgentManagerImp::GetIMWeChatKey() - > _GetWeChatKey()
CAgentManager::CAgentManagerImp::GetIMWeComKey() - > _GetEntWeChatKey()

Quick review of libIMKeyTool.dylib

The name of this dylib indicates it has something to do with the Instant Messaging application keys. We can see from the exports and entry related functions what this dylib handles, including a reference to frida. 

mod_init_func functions execute upon loading the library, and this dylib has three which correspond to the static initializers for each target application: WeChat, QQ, and Enterprise WeChat. 

The three target applications each have a similar setup that initializes and loads a frida script from an address in the binary. Let’s examine how the setup works for one, since it will serve as a good example for the remaining targets. 

Using WeChat as our first example, we see that a WeChatHook class is initialized. 

Next it calls the Find() method, which accepts the “WeChat” string as an argument and executes a find_pids() function, which calls _proc_listpids(, which then queries that result with _proc_pidinfo(), and executes a strcmp() function for the “WeChat” string that was passed in. A hook session is then set up by calling _frida_device_attach_sync(). 

After the Find() method returns, it executes a function called GetWeChatScrpit(), which appears to be a typo in the function name, to obtain a frida script. Looking at this function, we can see that it loads the script from an address in the binary.

This script is then loaded using a call to WeChatHook::Load(), resulting in a call to
GetWeChatMessagesLoop(). The three target application hooks are all set up similarly and each specific frida script is readable within the binary. 

Robber dylibs

There are three other stealer-related dylibs we have not yet covered:

libWXRobber.dylib
libNTQQRobber.dylib
libQQRobber.dylib

While we won’t offer too much detail about these, they’re important enough to cover briefly. 

WXRobber.dylib

This dylib targets the apwx.plist file we referenced previously and also has a call to a function named _DexorKey(). 

libNTQQRobber.dylib

This initializes a Debugger class that is then passed methods like MsgServerLoop(),
GetAllThreads(), and WriteCodeInstruct<int32_t>(). There are also references to QQ related paths.

libQQRobber.dylib

This dylib targets the apqq.plist we also previously referenced. This concludes this section on the Robbers dylibs. 

CCmdTypeMap()

The command types in the map:

Plugins Functionality

Inside of the /Library/protect/wsus/bin_arm/plugins/ directory are 28 plugins, each starting with the name “zero” and ending with a .gz file extension. These are not .gz files but are instead dynamic libraries. Inside of each of these plugins, is a function called _GetPluginName(), which we can use to categorize the plugins. 

These plugins are similar in their behavior, leveraging other imported dylibs to target specific files and parse the results depending on their file type (plist, sqlite3, etc.). Data collected by each plugin appears to be saved as a table within a sqlite3 database. Below we summarize each of these plugins and provide their target files.

Potential plugin naming scheme based on targets:

1. System OS/1st Party Software
2. System/ 3rd Party Software
3. Web Browsers
4. Chat
5. Email
6. Cloud

Additional Windows Components

Inside of the /Library/protect/wsus/Config/HtmlStyle/ChatInstall exist several files which appear to be for targeting Windows. These include a install.bat file which references a UACPrompt and appears to be related to elevating privileges. An executable named SmartViewer.exe is also observed within registry related commands and is likely for persistence. Although we were able to connect this macOS threat to a Windows targeting variant, we will not cover the Windows portion in this blog post. We have added the hashes for these files in the IOC section. 

Conclusion

The threat capabilities we observed indicate a deep understanding of macOS. Although there is a version check for systems under 14.4.1, we believe this suite of applications is actively developed and is designed to capture data from macOS systems - more specifically from communication applications commonly used in China. Given the evidence uncovered during technical analysis and OSINT research, we feel it’s possible this application suite is related to the Meiya Pico and Xiamen Huanya Zhongzhi Technology Partnership Enterprise organizations. As stated previously, we may release an update to this blog post if additional important details are uncovered.

IOCs

SHA256 sums:

0fd32b8f304531e121e19a50f64586a446bf74818caa645bad8d6b71673a350a

d82e7ae41f2ed92136343e1ee8cef780704447af476b59e2e3bdd8d1b84dbb23

203e82eb0085701598f21ef2478fad149e8e68335ce8602b118b23638be951e3

76eb3d942055e6b9bc5573cc30eef480f0cd04e4c6d5cfacda79431d5190707b

e493c30a427fbbafa0b37d8db8d2c42bfc91680402e6c174be34798fd8992b2b

f297651c58e530d8355222dccdf0bf28d341f20a8fee5038a3a49c0a4f19d0c0

76bf1e83e2c0788c98343a7b03995eaf822af7f33cd4b49e4952219dcfaa36e0

Contacted IP:
116.198.18.202

Signing Signatures:
weihu chen (QPV7YX8YQ9) - Apple Team ID Signature (Since Revoked)

Xiamen Huanya Zhongzhi Technology Partnership Enterprise - Signature Windows Component

Plugin SHA256 Hashes

72424adde8d28293e2becf48366692e4cceeebf4c8f9fe260dc8b4622b82b625

84701e24401ab07e12b78bba6ead16957f28593a4c7e64f705a01c825f3b8639

43d11551b81e2e5b9ce0701a1b2ad9d8f04b8161c135599a921ec1fbdeb5ca33

78b090dccf966d5108147b08ccbc3e64ab264632b2eb42f73fe98a4a934e743d

386759c38e672495beb2b56f53fd07b3392de59b09e818946172a321cf337e3d

6f10fb391a397eabc307df1684488c72351aa7502d93dfe78d076402b42a65b1 

c9435d5f315a27e01145494010e82f7e8d04b9379546551073401ddc0a73b253

d5b2cbf0187f10cc95a714e01a28e2ae26a3927fe09e7280e14e0a444cb69209

33bc2c5bfea02f02f7b19e68d5efe01beab80083b4d28977934677947c1a051d

6b4bd6c8ad5a17fd821f7cc6045b5d58783ce05d9a1140104cb7cc7b1e15d1cc

10a239886c93285c86debf9c2c87ecf63ea464b9b4c1dcf526c6ce666c230064 

7992280a3eeda665f024d424c6b2be2fc1ffc9977fda51e6e688bdc0dcb1facb

94420f4f9e52f1980e167a65c0a4f7c9fd3e0083e630a2a9294ac086879bfb8a

5be865ba5613b819ea10319c60eaca664e673c4c8882b5c621ba70f436585e9d

50a124e0c570e5d62e57f3d0789579aa726f77706537bbb2e80661b3489c0dc3

7d03db6386ebe43a449834d3e95749cc5359adbe079c08d7fe6caa5b69073361 

10e1770c531d231841c7e7f11bc061439ec089325747fbbbcc5ece9bbeb35c4e

696678aec46a0520f04232944ba6dd4585894c5b25c0ee28633e3716479e0470  

6ed715f9dd60d9ee6f1418005115a265c3aacc22c6dda74bef06a3b83d9f051b 

41e845c20cbd1100ef77ccd087b6edb8758b46d7b71bdc96176291da186417ed

9139cbec580f618045e113cd4cfd6f87b55f338bd6387cfd3fa362ced4556280

1376a81d8b7d04bca5de782867501e19cee579707a37eb9086ecb354631848a0

034d3cf595276d3ec5443ba84c1ffb2b7c3ae4b9986a1b4f99f3eb72a90eb465

02580be00387888e8d584d62744f6dbbdeb481367f2fad193212df8f08c1ee51

cf5ccd3f9aad801b1ad0995e773d1ef623158d28a21aeb64d3fadc4fe5d71f64  

4cc05a12cce16d2bb3232a5d4c680243cd7e972e50800ac30e3d4b2f3c416487 

e42d3ccc2d24e6d5903776ac1e4a0afc463a7655a15337400dd5dd8e94d51ab3

Windows Components Inside PKG

SmartViewer.exe
994af3a899ab607e869b5463809ce500bd7578075291a8be49d71239dc47b102

install.bat
D03d2a0f53e780be9797d252e45045ef5cd208bc093d5cdbc0c14f06f4b847a2

uninstall.bat
F335b82b5263578543cb3bd03e26fd5de246cd7b3b94cccdc44b8ed5113cc6e6

OSINT Sources

Government Restrictions

Chinese Military Sanctions Reference
https://sanctionssearch.ofac.treas.gov/Details.aspx?id=33896

Executive Order with Company Name from the Windows Signature https://ofac.treasury.gov/media/99111/download?inline 

US Treasury Notice
https://home.treasury.gov/news/press-releases/jy0538 

News Articles

https://amp.scmp.com/tech/start-ups/article/3017688/what-you-need-know-about-meiya-pico-chinas-low-profile-forensics