Research by: hasherezadeKey PointsSince early 2025, Check Point Research has been tracking JSCeal, a sophisticated cryptocurrency-focused stealer with broader credential-theft, surveillance, and traffic-interception capabilities, delivered as compiled V8 bytecode (JSC files).The payloads are protected with javascript-obfuscator, using multiple techniques including RC4-protected strings, control-flow flattening, proxy functions, and operation wrappers.Our goal was to recover the code to a level that enables detailed analysis, comparison between samples, and tracking of the malware’s evolution.CPR developed a fully static deobfuscation pipeline that transforms View8 pseudocode without executing the malware. An optional LLM-assisted renaming stage can then be used to make large, recovered codebases easier to navigate.The complete toolkit is publicly available at jsc_deobfuscator.The deobfuscated output enabled detailed analysis of JSCeal’s capabilities and their implementation, including keylogging, browser and credential theft, and HTTPS traffic interception through a local MITM proxy.We presented this research at Black Hat USA 2026. This article complements the talk by documenting the methodology in greater technical depth and providing additional examples and implementation details.We conclude with a brief look at more recent JSCeal developments, including V8 code caches generated for a newer Node.js/V8 version, an additional payload-encryption layer, and macOS targeting.IntroductionJSCeal is a stealer delivered as compiled V8 bytecode (.jsc) and executed by a bundled Node.js runtime, targeting cryptocurrency applications (other vendors also tag it with the names WEEVILPROXY or MeadowLocust). Its campaign activity dates back to March 2024 [1]; Check Point Research has been tracking the malware since early 2025. Our previous publication from July 2025 [1] focused on the campaigns, delivery chain, and targeting. In this article, we focus on the analysis problem hidden inside the final payload.Unlike ordinary JavaScript malware, JSCeal reaches the analyst after two transformations have already removed much of the information that source-oriented tools depend on. First, the JavaScript is heavily obfuscated. Then it is compiled into V8’s internal bytecode representation and shipped as cached data rather than source code. The resulting format is version-specific, poorly served by mature reverse-engineering tooling, and unsuitable for most standard JavaScript deobfuscation workflows.From the attacker’s perspective, this combination is attractive because it is inexpensive to produce. Node.js and its package ecosystem provide ready-made building blocks for complex applications, while public tools such as javascript-obfuscator [6] can add several layers of source-level obfuscation before compilation. The analyst receives only the compiled artifact.In 2024, our colleague Moshe Marelus published View8, an open-source decompiler for V8 bytecode [2]. We used it as the foundation for a static deobfuscation pipeline tailored to the patterns found in JSCeal. During this work, we extended View8 [3] to make its output reproducible and suitable for automated post-processing, and implemented dedicated passes for value propagation, string reconstruction, control-flow unflattening, proxy and operation-wrapper resolution, and additional cleanup.The goal is not perfect source recovery — V8 compilation is lossy, and the output of decompilation remains pseudocode. Instead, we aimed to recover enough structure and semantics to read the malware as code again: follow its logic, compare samples, locate capability branches, and validate behavior against concrete strings, APIs, paths, and data flow.Later in the article, we use one selected JSCeal payload as a case study and walk through portions of the recovered code, including browser and cryptocurrency theft, keylogging, screenshot capture, and a local HTTPS interception proxy.Distributed payloadsLet’s start by understanding the role of the JSC files in the whole attack chain.The payloads were delivered in campaigns that began with malvertising and were followed by multiple PowerShell scripts. The complete flow is illustrated below:Figure 1 – The final stage infection flow (image first presented in [1])The last stage consists of two ZIP archives downloaded by PowerShell:node.zip – a packaged Node.js runtimebuild.zip, containing the final payload and supporting components:winpty-agent.exe – an agent for a hidden Windows console (open source)winpty.dll – a module that allows interaction with the hidden console (open source)app.jsc – The JSCeal malware payloadpreflight.js – a decompression scriptNative .node modules (PE format) used by the payloadThe final JSC payload is distributed in Brotli-compressed [5] form and decompressed by preflight.js.The loading is triggered by the last PowerShell script in the chain, containing the command line:.\node.exe -r .\preflight.js .\app.jsc (the option -r forces Node to run a JS file before loading the main module).The size and complexity of the JSC payloads varied. They were all obfuscated with the same open-source obfuscator [6].Analysis methodologyWhile typical analysis procedures were sufficient for the earlier stages, the final JSC payload remained challenging. Because it was delivered as a V8 code cache rather than JavaScript source, conventional source-level JavaScript instrumentation was not directly applicable. Native-level hooking and dynamic binary instrumentation (DBI) could reveal process and API activity, but did not recover the payload’s JavaScript-level semantics at a useful level. Sandbox execution therefore provided mainly low-level system-interaction telemetry. To understand the payload’s logic, we turned to static analysis, which required deobfuscation.Since the JSC payload is Brotli-compressed, the first step is to remove this layer. This yields the V8 code cache, which can then be supplied to a compatible disassembler. The disassembled output is then passed to the View8-based pipeline, which includes decompilation and transformation by multiple deobfuscation passes. Each pass can be used as a self-contained script. To support modularity, we extended View8 with pickle serialization of its internal object graph. We also added function-level visibility controls and metadata annotations (details in Appendix A).Figure 2 – the pipeline demonstrating steps applied to the original JSC sampleOur toolkit is publicly available at https://github.com/hasherezade/jsc_deobfuscator [7]The following flowchart describes the major steps of the pipeline; details of each follow in subsequent sections.Figure 3 – the flowchart of the deobfuscation pipelineWe applied the pipeline to 23 JSCeal payloads collected over several months (Appendix B); it produced analyzable output in all cases.Environment SetupThe toolkit used for the main body of this research was developed on Linux.The JSCeal generation analyzed in depth in this research used a bundled Node.js runtime based on V8 10.2.154.26-node.25. The distributed app.jsc was Brotli-compressed; after decompression, the resulting file was a V8 code cache that could be supplied to a compatible disassembler.V8 cached data is version-sensitive, so before decompilation we first need to obtain a correct bytecode listing. We followed the general approach used by the View8 fork from j4k0xb [4]: build the corresponding V8 version, apply the required patches, and use a small program based directly on the V8 API to consume the cache.During this process, we encountered a bug in the original V8 code that caused a string-printing problem and corrupted some disassemblies containing wide characters. It passed a 16-bit code unit through byte-oriented printable-character handling, which could inject malformed output into string literals and break View8 downstream. We patched the printer so that printable ASCII remains literal, byte-sized non-printable values use \xNN, and wider values are emitted as \uNNNN. The patch is included in the public repository [9], and the complete build procedure is documented on the project Wiki [10].The released toolkit contains both the disassembler source and the V8 patches required for the supported generation. A prebuilt Linux disassembler is also distributed with the project [7] release.Decompiled outputOnce we have the correct disassembly, we can proceed with decompilation. However, there are some details to keep in mind.View8 does not reconstruct the original JavaScript source. It lifts V8 bytecode into pseudocode that reflects its underlying execution model.Recovered functions are represented in a form such as:function func_[name]_0x[disassembly_address]([arguments_list])The entry point is a function labeled start, for example: func_start_0x323d9daddcd9.In ordinary View8 output, the hexadecimal suffix is derived from address values emitted during disassembly. Because these values may differ between runs, our modified View8 can normalize function identifiers deterministically based on parse order. This makes the results reproducible (details: Appendix A).The pseudocode follows the underlying V8 concepts rather than ordinary JavaScript local-variable names. Each function can make use of its arguments, the accumulator, and a set of local virtual registers. It also has access to its own constant pool, global variables, and context storage exposed through Scope. Function arguments are represented as a0 to aN, while local virtual registers are printed as r0 to rN. ACCU denotes the current V8 accumulator value.Functions can declare nested functions and share values with them through their surrounding context. In View8, these relationships are visible through the declarer hierarchy and Scope[...] references. Values placed into a scope by a declarer function may later be consumed by nested functions. Reconstructing those relationships is essential for JSCeal because the obfuscator frequently moves constants, decoder offsets, proxy references, and dictionary objects through scope rather than keeping them local.As the root of the function hierarchy, the start function is the only function without a declarer. The start function also initializes the global bindings used throughout the program. In raw View8 output this is visible through DeclareGlobals, for example:ACCU = DeclareGlobals(["oQ", "kg", "xQ", func_yz_0x323d9daeb509, 893, [...] ])For readability, our modified View8 marks global identifiers explicitly with a global_ prefix. The prefix prevents collisions with local register notation and makes later propagation easier to follow.Since the original JavaScript was obfuscated before compilation, the View8 output contains artifacts introduced by the obfuscator, making the recovered pseudocode considerably harder to interpret. A detailed explanation of each obfuscation layer and the applied countermeasures is provided later in this article.For example, a single function from a JSCeal payload decompiled by View8 looks like this:function func_unknown_0x398fa079bb71(a0){ r2 = Scope[19][74][func_Ht_0x398fa0799da9(136760, "ZCe3")] r2 = r2(a0) r3 = func_Ht_0x398fa0799da9(57973, "Vbp&") r3 = (r3 + func_Ht_0x398fa0799da9(194117, "Af5z")) r3 = (r3 + func_Ht_0x398fa0799da9(86681, "XDjZ")) r1 = r2[(r3 + func_Ht_0x398fa0799da9(100990, "5Yvr"))] r1 = r1() r2 = func_Ht_0x398fa0799da9(75831, "b6Sj") r0 = r1[(r2 + func_Ht_0x398fa0799da9(49188, "Amc*"))] return r0()}This is already significant progress compared with the raw bytecode, but the remaining obfuscation still makes most of the output effectively unreadable. The rest of the pipeline progressively removes those layers and transforms the output into pseudocode suitable for practical analysis. One syntax detail is worth keeping in mind throughout the article: View8 uses its own pseudocode notation and should not be interpreted as literal JavaScript. For example, an expression such as !r6 === "0" represents the negation of the entire comparison — semantically: r6 !== "0".Obfuscation layersThe analyzed JSCeal payloads were protected with javascript-obfuscator [6]. Its configuration is highly customizable, and the exact combination varied between samples. Across the corpus, we repeatedly observed four groups of transformations:Renamed identifiers. Function and variable names are replaced with short or nonsensical identifiers.String protection. Important strings are split into chunks and reconstructed through decoder functions. In the dominant variant observed in JSCeal, the stored chunks are encoded and RC4-protected.Control-flow flattening. Selected functions are transformed into state machines whose intended block order is hidden behind a dispatcher.Proxy and operation indirection. Function calls are forwarded through proxy helpers, while simple operations such as addition, subtraction, comparison, or function invocation are wrapped in dedicated helper functions.The deobfuscation pipeline has to follow a specific order because the result of one pass can expose information required by the next. For example, string deobfuscation reveals not only the text used in the code, but also keys for dictionaries containing variables and function references.Propagating valuesBefore we can start peeling away the obfuscation layers, we need to set the stage by propagating the variables used in the code and performing all the necessary simplifications.Often, functions that we have to parse and resolve are not called directly, but through different variables: globals, scopes, or local registers. A similar problem applies to their arguments. Until we have everything filled and mapped, it won’t be possible to really understand the flow.Propagating values is non-trivial: it is done in multiple ways, at different layers of the obfuscation process. Demonstrating the full variety used would take too much space, so let’s focus on a few examples. We illustrate with string decryption functions here, but the same propagation logic applies to proxy resolution and operation inlining described later. Details on the actual string deobfuscation are given in the next section, “Reconstructing strings”.Below is a tiny function used to deobfuscate a chunk of a string. The input argument (a1) is modified by a value passed via Scope.function func_r_0x24543eceeb91(a0, a1){ r1 = (a1 - Scope[10083][2]["c"]) return func_mt_0x3120801469(r1, a0)}Without knowing the actual value, we won’t be able to do the calculation required for deobfuscation. The scope is filled by a function higher in the declaration hierarchy. Once we find the particular line, we are ready to fill it.function func_yZ_0x24543ecedfc9(a0){ [...] Scope[10083][2] = new {"c": 742} [...]After the substitution, we get:function func_r_0x24543eceeb91(a0, a1){ r1 = (a1 - 742) return func_mt_0x3120801469(r1, a0)}In this form, the function is ready to be parsed, and we can see that the value 742 is subtracted from the input argument.Another problem is that in many parts of the code, calls to interesting functions have their arguments passed via local variables. While parsing a line, it is not immediately clear what arguments are being passed.In the given example, the function deobfuscating a string chunk, func_r_0x24543eceeb91, is called with two arguments that are passed via dictionaries. We first collect those dictionaries, and then substitute their uses with corresponding values.Before: r0 = new {"c": "SwH7", "n": 84197, "x": "PEKM", "Y": 104422, ...} [...] r7 = func_r_0x24543eceeb91(r0["c"], r0["n"]) r7 = (r7 + func_r_0x24543eceeb91(r0["x"], r0["Y"]))After: r7 = func_r_0x24543eceeb91("SwH7", 84197) r7 = (r7 + func_r_0x24543eceeb91("PEKM", 104422))Once those preparations are completed, we are ready to parse the functions and resolve their outputs.Reconstructing stringsString reconstruction is the first major deobfuscation stage. Strings are valuable artifacts on their own: they expose API names, paths, commands, URLs, object fields, and targeted services. More importantly for this pipeline, they also unlock later transformations. Recovered strings become dictionary keys, property names, and control-flow order sequences used by the unflattening and proxy-resolution passes.The analyzed samples used two string-obfuscation variants provided by javascript-obfuscator [6]. We implemented [7] a separate pass for each.The simpler variant, addressed by deobf_str1.py, stores string fragments in an array and retrieves them through an index transformation. It appeared only in an older sample.The dominant variant, addressed by deobf_str2.py, adds several more layers: encoded string chunks, RC4 encryption, a large family of decoder wrappers, and arithmetic transformations of the chunk index. This is the variant described below.Details on deobfuscation modes used by each payload are listed in Appendix C.The string obfuscation rabbit-holeLet’s take a closer look at how the most common JSCeal string obfuscation is implemented. This is the mode addressed by deobf_str2.py.Just like in the simplest mode, each string is split into chunks. Then, each chunk is RC4 encrypted with a different key. The resulting content is Base64-encoded. Such obfuscated chunks are accumulated in a single array, stored inside one of the functions, and retrieved from there into a global scope. It is initialized in the start function.An example of how the function holding the array of chunks may look is given below (keep in mind that the array may contain thousands of elements):function func_KV_0x18c3e8c9a1c1(){ r0 = Scope[0] Scope[10824][2] = new ["s8ohWR3dRx8", "ffddSSo6sW", ... ]}When the program needs a string, it calls one of many decoder functions. A typical call contains a numeric value and a short RC4 key:r2 = func_xt_0x274f42c4e909(71692, "%]hf")The argument order is varied: some decoder functions receive (number, key), while others receive (key, number). The number is used to calculate the index of the chunk to be decrypted, relative to the aforementioned global list. The calculation is done inside the function.To make things more complex, deobfuscation is done not just by one function, but by many similar instances. The instances may call one another, each one of them adding or subtracting a different value to the input argument. In order to calculate the actual chunk index, we have to follow the whole chain of functions, parse them, and repeat the operations they performed. At the end of the chain there is always a strongly obfuscated parent function that contributes the final operation.The values used in calculations are not hard-coded in the function but passed via scope (details described in “Propagating values”). Example of a single deobfuscating function:function func_r_0x7b2a9768611(a0, a1){ r1 = (a1 - Scope[1][2]["V"]) return func_xt_0x274f42c4e909(r1, a0)}In the above case, the index was passed via argument a1. The value retrieved from the scope is first subtracted from it. The result, along with the argument a0 representing the RC4 key, is passed to the next deobfuscation function (func_xt_0x274f42c4e909) which performs similar operations. The chain of similar calls follows multiple layers until it reaches the parent function which adds or subtracts the final value from the index, retrieves the chunk from the global array, and performs the decryption operation.Recovering the root offsetAs mentioned earlier, at the top of the chain of different deobfuscating functions that call one another, there is always an obfuscated parent. Instead of deobfuscating it, we decided to treat it as a black box. Recovering its index shift involves several steps.The parent functions are the first string decoding functions to be declared, and in the start function, they may be called directly. Just like in the case of their children, two arguments are expected: the RC4 key, and the number used for index calculation.Once we have found the parent, we track its direct calls and collect the arguments.We know that the chunk index is obtained by an arithmetic operation (addition or subtraction) on the passed number. We can express it as:index = arg (+|-) XThe goal is to find the correct X (index shift). Since this value is used to calculate the index of the chunk, the upper bound is the number of chunks in the array (N). We test candidate shifts from 0 to N-1, apply each to the input index, and attempt to decrypt the resulting chunk. If the output looks like a valid string, we treat that X as the index shift candidate.Conceptually:for candidate_shift in 0 .. N-1: candidate_chunk = array[(input_index + candidate_shift) mod N] plaintext = RC4(candidate_chunk, key) if plaintext looks plausible: keep candidate_shiftA plausible result from a single call is not enough: an invalid chunk can occasionally produce printable text when decrypted with the given key. The implementation therefore requires at least three distinct input/output observations for the same decoder function. It computes the candidate shifts per set, intersects those sets, and accepts the value only when it produces a printable result for each. In all the analyzed payloads this condition was sufficient to find the appropriate index shift.This can be viewed as a bounded brute-force search. The implementation tests possible index shifts within the string-array length and uses multiple independent calls to eliminate candidates that do not produce consistent printable results.Once the root configuration is known, the pass propagates the index shift through the collected function graph to the callers, calculating the cumulative index delta applied by each individual decoder.Overview of the string deobfuscating passThe string deobfuscation pass requires all arguments to be filled, as described in “Propagating values”. It works in the following steps:Retrieves the start functionSearches for the function aggregating obfuscated string chunks. It is always referenced by the start function and can be spotted by a known pattern of the call. Example:ACCU = func_unknown_0x93e23cef019(func_KV_0x18c3e8c9a1c1, 940600)Follows and parses the function with chunks (in the above case: func_KV_0x18c3e8c9a1c1). Stores the list for further use.Searches all the string decoding functions, recovers the parent index shifts, and calculates the resulting index shift for each decoder function. The input arguments can be arranged in two ways: either Rc4Key, Offset or Offset, Rc4Key – this is recognized and added to the function prototype.r2 = (r2 + func_xt_0x274f42c4e909(99288, "h^gm")) //Offset, Rc4KeyAfter the first run, the deobfuscator stores parsed and calculated arguments in a CSV file. If the pass has to be re-run, the list is pre-loaded, which saves time.Example of the listing (format: function_name,index_shift,is_index_first):func_xt_0x274f42c4e909,125103,Truefunc_Et_0x1d8d5672d829,125093,Falsefunc_u_0x3fa27d771f29,125016,Truefunc_r_0x93e23cf1d91,125126,Truefunc_n_0x93e23cf22a1,126086,True...After all the deobfuscating functions have been resolved, each of their resolved occurrences is replaced with its output value. The deobfuscated chunks are then chained together to form the full string.- r5 = func_n_0x34d57d25f3b9(60787, "Bz&S") //"defau"- r4 = xF[(r5 + "lt")]+ r4 = global_xF["default"]- r5 = func_n_0x34d57d25f3b9(58819, "5C8Q") // "globa"- r5 = (r5 + func_n_0x34d57d25f3b9(17159, "SldQ")) //"lAgen"- return r4[(r5 + "t")]+ return r4["globalAgent"]After the deobfuscation is completed, the functions responsible for string decoding are no longer needed. Their representation is hidden in the code and not printed in the decompilation output.Scale and performanceFor the 23-sample dataset used in the final measurements [8], the string layer contained approximately:130,000 encoded chunks on average, with observed values from about 19,000 to 217,000;10,000 decoder configurations on average, with observed values from about 2,200 to 13,000.Measured runtime for the string stage was:modeminimummedianmaximumwithout cache0.6 min1.7 min4.6 minwith cache0.5 min1.2 min3.0 minAfter string reconstruction, the output contains both substituted plaintext and a standalone string listing. This is often the first point at which the payload starts exposing concrete artifacts such as commands, registry paths, browser targets, cryptocurrency platforms, and the attacker’s embedded public key.Artifact overviewIn addition to the main output of the pass (which is the decompiled and pickled file), the list of all the strings is dumped as text. It helps quickly give an idea of which functionalities are implemented, and to compare different payloads.Example – listing of strings extracted from a sample: e27ae65977287bdfb7b0e15fd3603f85.deobf.txt.strings.txtAmong the interesting artifacts, we can find the public key of the attackers:"\n-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtRdWl/ucoH+ZnVuxHrx2\ncTbwEY2LucyUqEJVl6trmNYaJTFX9qDYA8Z4VOaFO86MHg0cY1mJ8NALzTqDt20C\nlnqYtLEuo0Fqg9pJMhnEb078F31dilgdK+5bK7LgwXps06KQ+Dk7XxaqkbPFa7oZ\n73/q4FhrYEtBxFno0WJla7mq49/W4wJb753WYWTjRMjBKVaUIOtAtGdBp8Li2WX2\nPDqxftDcvT8hJf5H6tMJ3tQRpyHu7ljkwdivamG/labZpzKhijK7BMgrd7251sjh\n7zD6prnafayjK+nfD1dvok7Rd8TV8sa1FK8T0uMmGFdUVGK+X4f45AwNWn8OINLE\nVwIDAQAB\n-----END PUBLIC KEY-----"There are strings related to deploying hidden PowerShell scripts and running content from a Base64-encoded blob:"powershell -NoProfile -WindowStyle Hidden -Command \"""Invoke-Expression ([System.Text.Encoding]::"".GetString([System.Convert]::FromBase64String($_.unattend.Extensions."Multiple strings suggest that the malware enumerates installed browsers, and tries to query the saved secrets, cookies, OAuth tokens, and other data:"iterInstalledBrowsers""getCookies""application""launch""values""createBrowserContext""newPage""setCookie""getPasswords""div[data-identifier=\"""findInstalledBrowser""--user-data-dir=""--profile-directory=""withCreateProcessUser""user_id""oauth_token""google""saveOAuthToken""/oauth2/:version/token?grant_type=authorization_code&client_id="It also queries all installed applications and targets Telegram accounts:"listTelegramSessions""listInstalledApplications"To achieve its goals, it uses the capability to spawn additional processes:"Process exited with code "spawnIt creates a local proxy server with its own certificate:"address"close"listen""127.0.0.1""createServer"pkirsa"generateKeyPair""createCertificate""publicKey""serialNumber""certificateToPem"Some strings are fragments of URLs for particular cryptocurrency vaults and are related to checking account balances:".phantom-labs.vault.""totalBalanceInUSDT""free_margin_usd""floating_usd""historical_balances_per_asset_category""total_usd_market_value""customer_account_USDT_balance_available""binance"Many of the deobfuscated strings come from Node.js modules bundled into the payload and give an idea of what functionality to expect.Comprehensive analysis of all the artifacts is beyond this short overview. You can find the extracted strings from all analyzed samples in the directory with additional materials [8].Control flow unflatteningSome of the most important functions of the malware are obfuscated using Control Flow Flattening (CFF).To resolve this layer, we must make sure that all strings are deobfuscated and propagated, because they are crucial for the execution logic. In the listing produced by the previously described filter, we find some strings in the format [number0]|[number1]|[number2]... for example: “3|2|1|0|4”. Such strings denote an order of chunks to be executed.Typically, CFF is implemented as a state machine. We can see it represented by a while loop. In each iteration of the loop, the number is fetched from the list. This number is further checked against nested if statements, directing to the chunk of code to be executed. In the simplest form, a chunk ends with continue, causing the loop to progress to another case.Example (from: 03f4e47b9c2283c32bb8f8f042ce6e41):function func_Mz_0x6035be98311(a0){ r5 = Scope[0] r2 = func_r_0x6035be98a69 Scope[6705][2] = new {"w": 1342} r6 = new {"jGBGz": null, "hBPBb": null, "qbyOP": null, "ykkYm": null, "SeAyf": null, "yHrsY": null, "umIdy": null, "RBgqe": null} r6["jGBGz"] = "3|2|1|0|4" r6["hBPBb"] = func_hBPBb_0x6035be990e9 r6["qbyOP"] = "wss" r6["ykkYm"] = func_ykkYm_0x6035be991e9 r6["SeAyf"] = func_SeAyf_0x6035be992e9 r6["yHrsY"] = "https" r6["umIdy"] = "http" r6["RBgqe"] = "Invalid protocol" r1 = r6 r7 = r1["jGBGz"] r6 = r7["split"] r3 = r6("|") r4 = 0 while (true) { r7 = Number(r4) r4 = (Number(r4) + 1) r6 = r3[r7] if (!r6 === "0") { if (!r6 === "1") { if (!r6 === "2") { if (!r6 === "3") { if (!r6 === "4") { continue } r7 = r1["hBPBb"] r10 = r1["qbyOP"] if (r7(a0, r10)) { r7 = global_Tb["default"] return r7["globalAgent"] } continue } r7 = r1["ykkYm"] if (r7(a0, "ws")) { r7 = global_Nb["default"] return r7["globalAgent"] } continue } r7 = r1["SeAyf"] r10 = r1["yHrsY"] if (r7(a0, r10)) { r7 = global_Tb["default"] return r7["globalAgent"] } continue } r7 = a0["split"] r7 = r7(":") a0 = r7[0] r7 = r1["hBPBb"] r10 = r1["umIdy"] if (r7(a0, r10)) { r7 = global_Nb["default"] return r7["globalAgent"] } continue } r8 = r1["RBgqe"] ACCU = Error ACCU = Error(r8) break } return undefined}We start the deobfuscation by identifying the beginnings and ends of each code chunk. For example, to find the chunk number 0, we first need to identify the if statement that actually checks against the negation of this condition: if (!r6 === "0"). Once we find the statement, we have to skip the body under it (since it is a negation) and find the first closing bracket with the same indentation as the statement itself. This is where the chunk indexed as 0 actually starts.Once we have all the chunks mapped, we rearrange them by the order defined by the string, adjusting their indentations.The same function, unflattened:function func_Mz_0x6035be98311(a0){ r5 = Scope[0] r6 = new {"jGBGz": null, "hBPBb": null, "qbyOP": null, "ykkYm": null, "SeAyf": null, "yHrsY": null, "umIdy": null, "RBgqe": null} r6["hBPBb"] = func_hBPBb_0x6035be990e9 r6["qbyOP"] = "wss" r6["ykkYm"] = func_ykkYm_0x6035be991e9 r6["SeAyf"] = func_SeAyf_0x6035be992e9 r6["yHrsY"] = "https" r6["umIdy"] = "http" r6["RBgqe"] = "Invalid protocol" r1 = r6 r4 = 0 r7 = a0["split"] r7 = r7(":") a0 = r7[0] r7 = r1["hBPBb"] r10 = r1["umIdy"] if (r7(a0, r10)) { r7 = global_Nb["default"] return r7["globalAgent"] } r7 = r1["SeAyf"] r10 = r1["yHrsY"] if (r7(a0, r10)) { r7 = global_Tb["default"] return r7["globalAgent"] } r7 = r1["ykkYm"] if (r7(a0, "ws")) { r7 = global_Nb["default"] return r7["globalAgent"] } r7 = r1["hBPBb"] r10 = r1["qbyOP"] if (r7(a0, r10)) { r7 = global_Tb["default"] return r7["globalAgent"] } r8 = r1["RBgqe"] ACCU = Error ACCU = Error(r8) return undefined}For the sake of comparison, let’s see it with further deobfuscation filters applied:function func_Mz_0x6035be98311(a0){ r4 = 0 r7 = a0["split"] r7 = r7(":") a0 = r7[0] if (a0 === "http") { return global_Nb["default"]["globalAgent"] } if (a0 === "https") { return global_Tb["default"]["globalAgent"] } if (a0 === "ws") { return global_Nb["default"]["globalAgent"] } if (a0 === "wss") { return global_Tb["default"]["globalAgent"] } ACCU = Error ACCU = Error("Invalid protocol") return undefined}At this point the function’s intention becomes clear. It performs a lookup that returns the appropriate globalAgent for a given protocol.The caveatsSometimes, the chunks of code that are executed in each state are decompiled in a way that makes them difficult to separate cleanly. Let’s take a look at the following example:while (true) //The dispatcher loop{ r15 = Number(r4) r4 = (Number(r4) + 1) r14 = r3[r15] if (!r14 === "0") { // Other chunks... // [...] } // Chunk 0: r15 = r2["Uugef"] if (r15(r11, r12)) { ACCU = 0 continue ///