Do we Call this Recipe App TamperedChef also?
Inside CookUp: A Suspicious Server-Gated Installer and In-Memory Loader
CookUp is a recipe application distributed by an installer that also contains a suspicious, server-controlled remote-loading workflow. The installer drops/installs cookup.exe, a .NET recipe application with a limited JSON-based recipe database; in the observed installation, that application appeared functional and benign. The separate Go-based installer can activate a downloader and contains code for processing and loading native PE modules. No authentic second-stage payload was recovered, and malicious activity has not been established.
1. Research scope and evidence boundaries
The subject was a Windows installer named cookup-setup.exe, associated with a CookUp recipe application. Analysis focused on a secondary workflow that contacts applicensingstudio.com. All controlled activation and framing experiments routed this hostname to a localhost HTTPS listener rather than intentionally obtaining a live second-stage payload. Later follow-up work added pass-through live-server Fiddler observations; see Section 10 for the separate evidence boundary.
Evidence is separated into observed behavior and static code capabilities. The installer creates or installs cookup.exe, a .NET recipe application containing a small JSON-based recipe database. The application itself appeared benign/legitimate during examination; this is distinct from the suspicious downloader capability in the installer. Neither the downloader code nor its ability to map PE modules is proof that a malicious second stage was delivered or executed.
The contacted domain applicensingstudio.com was newly registered on October 16, 2026, approximately 13 days before this October 29 analysis. A recently registered domain is a relevant contextual indicator, not independently evidence of maliciousness.
2. Screenshots from the investigation
Images are embedded directly in this HTML file for offline reading and blog preparation. The screenshot showing the green progress UI was captured during the even-token activation test.
3. Remote activation is controlled by response content
The installer sent an HTTPS request resembling:
GET /?ver=9de1&chan=2d6&lang=f24&arch=23a&build=301&init=prep HTTP/1.1
Host: applicensingstudio.comThe sinkhole returned 32 hexadecimal-looking ASCII characters. The controlled tests modified only the final character while keeping the response status and listener configuration consistent:
| Token suffix | Decimal digit sum | Green update UI | FetchRemoteBlob |
|---|---|---|---|
…7D8D | 91 (odd) | No | Not observed |
…7D81 | 92 (even) | Yes | Entered (~31.6s with token-only fin responses) |
…7D82 | 93 (odd) | No | Not observed |
…7D83 | 94 (even) | Yes | Entered (~31.6s with token-only fin responses) |
These four tests strongly support a decimal-digit-sum parity gate: even sums entered the downloader while odd sums continued into the ordinary setup flow. The token content may serve other purposes, but the gate itself is experimentally reproducible. No claim is made that all possible tokens behave this way.
The full even-token example was DD8CCF3E63FD7D2B8CD9986124FF7D81 (digit sum 92). The original response used DD8CCF3E63FD7D2B8CD9986124FF7D8D (digit sum 91).
4. Reverse engineering the download-response frame
When the sinkhole returned the same 32-character token for every init=fin request, CookUp retried with approximately 5-, 10-, and 15-second intervals. The FetchRemoteBlob trace lasted about 31.6 seconds and did not enter RunRemoteChain.
The assembly after FUN_004F6740 at 00501130–0050119C tests for an error, requires a body longer than four bytes, then compares the trailing 32-bit little-endian value to response_length - 4. Expressed as pseudocode:
valid = (err == nil) and (len(body) > 4) and \
(little_endian_uint32(body[-4:]) == len(body) - 4)To verify that condition without introducing an executable, the listener responded differently depending on the request phase:
init=prep → DD8CCF3E63FD7D2B8CD9986124FF7D81
init=fin → 54 45 53 54 04 00 00 00
T E S T <uint32le 4>The eight-byte init=fin body passed the framing check and caused an immediate transition into the next-stage function. It was not a PE and could not satisfy the later executable-container requirements.
5. Most compelling dynamic evidence: the guarded handoff
The decisive run produced the following events (UTC, 2026-10-29):
| Time | Observation |
|---|---|
| 11:42:05.915 | Initial init=prep receives even-sum token |
| 11:42:07.521 | Frida records entry to FetchRemoteBlob |
| 11:42:09.050 | Installer issues first init=fin GET |
| 11:42:09.077 | Sinkhole returns 8-byte inert framed response |
| 11:42:09.079 | FetchRemoteBlob returns (~1.6 seconds) |
| 11:42:09.080 | RunRemoteChain entered; guard fires |
[cookup-fn] {"type":"leave","function":"FetchRemoteBlob","duration_ms":1558,"eax":"0x1","edx":"0x8"}
[cookup-fn] {"type":"enter","function":"RunRemoteChain","pc":"0xd711d0"}
[cookup-guard] {"event":"STOP_BEFORE_EXECUTION","function":"RunRemoteChain","address":"0xd711d0"}Both RunRemoteChain and memload.Load guards reported being armed before execution. The trace therefore confirms function entry and the guard event, not execution of a real second-stage DLL. Earlier runs with token-only responses took ~31.6 seconds before FetchRemoteBlob returned, with no downstream entry.
6. Static findings: multi-stage native loader
6.1 Programmed progress rather than download percentage
FUN_004F79E0 invokes a progress callback before and after FUN_004F7B20. Caller-provided floating-point progress ranges include 0.10–0.15 and 0.15–0.72. That aligns with the observed green screen stalling at 72%, indicating a scripted workflow milestone rather than reliable evidence of 72% of bytes received.
6.2 Real HTTP response-body collection
FUN_004F7B20 handles request/response operations and distinguishes HTTP status 200–299. Its downstream routine FUN_004F8A90 reads a response body in 0x2000-byte (8 KiB) chunks into a growing buffer and returns a Go-style byte slice/error result. This is capable of retrieving substantially more than the initial 32-byte activation token.
6.3 A second, much larger payload gate
At the beginning of FUN_005012F0, the code repeats length-trailer validation and then checks (response_length >> 2) >= 0x10000. The effective threshold is at least 262,144 total response bytes to continue past that gate. Our eight-byte synthetic response necessarily fails here; the test was only designed to validate the preceding handoff.
6.4 Bitwise payload transformation
FUN_005026E0 iterates across individual bits with an initial 32-bit state 0x95000000, calculates a parity-like feedback bit, shifts the state, and changes the buffer in place. The design is consistent with LFSR-like data scrambling. The exact feedback polynomial and complete container format have not been independently validated against a recovered live payload.
6.5 Manual PE mapping and executable permissions
FUN_004FDA40 is a native PE memory loader. The code parses headers, sizes an image, allocates memory with MEM_RESERVE | MEM_COMMIT (0x3000) and PAGE_READWRITE (0x04), copies image data, and invokes follow-on image initialization helpers. One branch tests IMAGE_FILE_DLL (0x2000). FUN_00500350 appears to apply PAGE_EXECUTE_READWRITE (0x40) and flush the instruction cache; the API identities are strongly suggested by arguments but should be confirmed from import-pointer resolution.
6.6 Export lookup and indirect invocation
FUN_004FE430 looks up a module in an internal registry and delegates to FUN_004FF940, which walks PE export structures. Assembly at 00501773 invokes this resolver, tests the error, preserves the returned pointer in local_f4, and passes that pointer to FUN_00502D90 at 00501880. The latter function is an indirect-call wrapper.
00501773 CALL FUN_004FE430 ; export resolution
00501778 MOV EAX,[ESP+0x10] ; error
0050177C MOV ECX,[ESP+0x0C] ; resolved pointer
00501780 TEST EAX,EAX
00501788 MOV [ESP+local_f4],ECX
...
0050185F MOV EBP,[ESP+local_f4]
00501866 MOV [ESP],EBP
00501880 CALL FUN_00502D90 ; indirect-call wrapperThe requested three-character export name is obfuscated with a single-byte XOR. Its source bytes are 39 22 6B; XOR 5A yields cx1. The sample's static path thus looks for this unusually short custom export name. This is a candidate hunting pivot, not a reliable standalone detection signature.
7. Reconstructed workflow and confidence levels
init=prep → 32-character responseFetchRemoteBlob → init=fin HTTP responseRunRemoteChain [guarded entry observed]memload.Load → native PE mapping [static]cx1 → invoke indirect callback [static]The code also contains a second memload.Load call on a later path. That suggests support for further in-memory stages, but no live payload was recovered to establish their real-world contents or behavior.
8. Network and technical hunting pivots
| Indicator | Use / caveat |
|---|---|
applicensingstudio.com | Observed hostname contacted by installer; network indicator, not by itself a maliciousness verdict |
init=prep, init=fin | Distinct request phases; combine with other attributes for higher fidelity |
DD8CCF3E63FD7D2B8CD9986124FF7D81 | Researcher-crafted activation token; NOT a confirmed live-server IOC |
cx1 | Three-character export searched by loader; useful with PE/manual-map context, weak alone |
0x95000000 | Bit-scrambler initial state; a candidate static-search feature |
0x3000 → 0x04 → 0x40 | Image allocation/protection sequence; generic manual-loader behavior, not unique |
cookup-setup.exe | Observed sample filename; not a robust file-identifying IOC without a cryptographic hash |
The analyzed executable SHA-256 was subsequently established as e7bc65daf98767646cb1a0e8c3d19cf0db0dce4618a9bcd2d287426cfd2c9034. See Section 10 for dated Retrohunt observations and confidence boundaries.
10. Follow-up findings — October 29, 2026
10.1 Live-server behavior and Fiddler SAZ evidence
Later testing used Fiddler AutoResponder to substitute a researcher-created even-parity token for the initial init=prep response, while allowing subsequent requests to pass through to the live server. The recorded sequence was an initial activation request, another init=prep, four init=fin attempts with changing uid values, and a final init=prep on the failure path. The four download attempts received HTTP 200 responses with no decoded response body. The operation repeatedly stalled near the programmed 15% progress milestone and exited.
| Exchange | Observation | Interpretation |
|---|---|---|
First init=prep | 32-character researcher-controlled even-parity token in AutoResponder | Activation was induced locally; not a server-provided activation decision. |
Second init=prep | 32-character server response | Downloader initialization continued. |
Four init=fin attempts | HTTP 200, decoded body length 0 | No payload supplied in the captured transactions. |
Last init=prep | 32-character server response | Consistent with observed failure/reporting path; precise server-side semantics unknown. |
Two responses displayed five bytes at the raw transfer-encoding level: 30 0D 0A 0D 0A (0\r\n\r\n), the terminator for an empty HTTP chunked response. This is not a five-byte stage or error message. The SAZ did not contain a nonempty init=fin payload.
10.2 Frida V3–V7: actual token consumption
The response handler (FUN_004F7B20) returned a 32-byte token buffer; a copy was observed from 0x038945C0 into a local stack region at approximately 0x038A3E98. An optimized 16-byte movdqu read at Ghidra address 00463CDA participated in that copy. The higher-level conversion function was identified as FUN_0044F330, with an initial-response call returning to 004F7903. The memory addresses are run-specific; the Ghidra offsets identify the analyzed build.
The more selective V7 probe succeeded after multi-instruction V6 hooking caused early termination. V7 recorded 33 visits to the loop head at 004F7957—an initial entry followed by 32 character-processing iterations. Observed EBX values advanced from 0 to 31, EDX tracked a count through 32, and EBP held the corresponding ASCII character from the 32-byte activation token (for example D,D,8,C,C,F,3,E at the beginning). This independently confirms that the response is traversed character-by-character. The specific arithmetic and conditional branch responsible for the previously demonstrated parity-based activation have not been instruction-by-instruction proven.
Initial token (research fixture): DD8CCF3E63FD7D2B8CD9986124FF7D81
Token length: 32 ASCII bytes
Observed loop: Ghidra 004F7957
Iterations: 32 character-processing steps (plus initial loop-head entry)
Status: token traversal confirmed; validator calculation not fully reconstructed10.3 Parser and memory-loader evidence
Analysis of FUN_00501030 (FetchRemoteBlob) identified a four-byte little-endian trailing-length requirement before downstream processing. Inert framed test bytes reached FUN_005011D0 (RunRemoteChain). A larger synthetic container of 262,148 bytes reached additional decoding operations but failed the next decoded-length constraint; it was not an authentic payload and did not demonstrate stage execution.
The container parser FUN_005012F0 applies a bitwise descrambling routine FUN_005026E0 with a reported 0x95000000 starting state and bit-feedback behavior; static code analysis also identifies FUN_004FDA40 (memload.Load) as a manual PE32 mapper, with an eventual cx1 export lookup. These are loader capabilities, not confirmation that a second-stage DLL was received or run.
10.4 Malware hunting and attribution boundaries
VirusTotal observations showed applicensingstudio.com registered on October 16, 2026, with CookUp as the only referring file seen during this research. This describes the research snapshot, not an exhaustive historical inventory. The analyzed CookUp sample SHA-256 is e7bc65daf98767646cb1a0e8c3d19cf0db0dce4618a9bcd2d287426cfd2c9034.
A preliminary Retrohunt on the string/function FetchRemoteBlob surfaced three files within approximately six weeks: CookUp and two files identified as Velum Setup.exe (one approximately 11.42 MB, one approximately 120.67 MB). An observed Velum URL, https://securedocinstaller.com/?ver=c2c5b822&appid=89852170&init=prep, shares ver and init=prep parameter naming but uses a different query structure. Both Velum installers were observed to be .NET executables, with the smaller protected by .NET Reactor; CookUp is Go. No shared implementation, second-stage module, or actor attribution has been demonstrated. These are unconfirmed hunting leads, and a generic-function-name YARA match alone is insufficient to define a family.
10.5 Current limitations and recommended next research
The live infrastructure has not delivered a second-stage body in any captured init=fin response. The clearest remaining path is offline correlation: compare distinctive loader instructions, Go build paths and the custom decoder across independently obtained samples, or identify an authentic container from a separate capture. Do not infer malicious second-stage behavior from loader capability alone. Runtime strings captured using Process Hacker may include Windows components, proxy settings, instrumentation artifacts and inherited environment variables; those are not automatically attributable to CookUp. A manually supplied --check-update argument is explicitly excluded from malware findings.
9. What is still unknown?
- What the real server returns when it elects to activate the remote branch.
- Whether the actual second stage is malicious, benign, or selectively delivered.
- The complete encoding, packing, and validation format for a payload larger than 256 KiB.
- The purpose of the
cx1export and the behavior of any additional mapped PE stages. - Whether the same infrastructure serves different modules based on host, campaign, or environment.
Earlier planned experiment (subsequently completed in part; see Section 10)
The next investigation will use the existing isolated sinkhole and focused instrumentation to record each request phase, response, validation result, memory-loading attempt, and any resulting artifacts. A real-server response can be recorded only if the server independently chooses to return one; changing the locally fabricated response does not force a remote server to deliver a payload. If an authentic payload is obtained in an authorized setting, it should be retained as bytes for offline inspection before being allowed to execute.
Conclusion
CookUp should currently be described as suspicious rather than confirmed malicious. The Go-based installer installs a .NET application, cookup.exe, which provides a limited JSON recipe database and appears benign/legitimate based on the observed functionality. Separately, the installer has a reproducible server-gated downloader branch and implements custom payload framing, transformation, manual PE mapping and indirect code invocation. The contacted domain was newly registered on October 16, 2026. These findings justify further investigation, but all observed live init=fin responses were empty and no authentic second-stage payload was recovered. Accordingly, neither malicious payload execution nor the intended purpose of a potential second stage has been established.
Research note: function names and addresses reflect one analyzed 32-bit build and Ghidra image base. No actual remote second-stage executable was run during the guarded proof-of-concept test. Local hostnames/response tokens and synthetic TEST frame were part of a controlled experiment.
Comments
Post a Comment