__int64 __fastcall sub_140085138(void **a1)
{
  __int64 result; // rax
  void *v3; // rdi
  HANDLE ProcessHeap; // rax

  result = 1892604534;
  while ( 1 )
  {
    while ( result > 640601083 )
    {
      if ( result == 640601084 )
      {
        a1[2] = 0;
        goto LABEL_13;
      }
      if ( result == 916669954 )
      {
        result = 2948659664LL;
        if ( !*a1 )
          result = 640601084;
      }
      else
      {
        result = 916669954;
        if ( !a1 )
          result = 4136723569LL;
      }
    }
    if ( result == -1783324655 )
      return result;
    if ( result == -1346307632 )
    {
      v3 = *a1;
      ProcessHeap = GetProcessHeap();
      HeapFree(ProcessHeap, 0, v3);
      *a1 = 0;
      result = 640601084;
    }
    else
    {
LABEL_13:
      result = 2511642641LL;
    }
  }
}

# Malware Static Analysis Report

## 1. Functionality Description

This function is a **memory deallocation/cleanup routine** that frees a heap-allocated buffer and clears its associated pointer/state.

Decoding the control flow (which is deliberately scrambled via a state-machine pattern):

- **Input:** `a1` — a pointer to an array/structure of `void*` (effectively a small wrapper struct).
- **Logic (cleaned up):**
  ```c
  void cleanup(void **a1)
  {
      if (a1 != NULL)            // result == 916669954 check
      {
          if (*a1 != NULL)       // a1[0] holds a heap pointer
          {
              void *p = *a1;
              HeapFree(GetProcessHeap(), 0, p);  // free the buffer
              *a1 = NULL;        // null out the pointer
          }
          a1[2] = NULL;          // clear a length/secondary field
      }
      // return
  }
```

**Summary:** A safe "free and zero" helper. It checks the wrapper pointer is non-NULL, checks the inner buffer is non-NULL, frees it on the process heap, and zeroes both the buffer pointer (`a1[0]`) and an associated field (`a1[2]` — likely a size or capacity counter).

## 2. Well-Known Algorithms

**None.** No cryptographic, hashing, or compression algorithms are present. This is plain Win32 heap management (`GetProcessHeap` + `HeapFree`).

The large "magic" constants (e.g., `1892604534`, `640601083`, `916669954`) are **not** algorithm constants — they are opaque dispatch values used by a **control-flow flattening** state machine.

## 3. Indicators of Compromise (IOCs)

| Type | Value |
|------|-------|
| File paths | None |
| IP addresses / domains | None |
| Registry keys | None |
| Commands / scripts | None |

This particular snippet contains **no extractable IOCs**. It is an internal utility routine.

## 4. MITRE ATT&CK Mapping

| Technique ID | Name | Evidence / Justification |
|--------------|------|--------------------------|
| **T1027** | Obfuscated Files or Information | The function uses control-flow flattening with opaque numeric constants driving a `while/switch`-style dispatcher instead of straightforward logic — a hallmark of obfuscated/protected binaries. (Observed) |
| **T1140** (weak/indirect) | Deobfuscate/Decode Files or Information | *Inferred only* — heap free-and-zero routines frequently accompany code that decrypts/decodes buffers and wipes them after use. Not provable from this snippet alone. |

> Note: The function itself does not perform any inherently malicious ATT&CK behavior (no exec, no network, no persistence). The only directly supportable mapping is the **obfuscation** of the code.

## 5. Obfuscation / Evasion Techniques

**Observed:**
- **Control-Flow Flattening:** The original `if/else` logic is converted into a dispatcher loop (`while(1)`) governed by a `result` state variable. Execution jumps between states via comparisons against large pseudo-random constants (`640601084`, `916669954`, `-1346307632`, etc.).
- **Opaque/magic constants:** Negative-signed comparisons (`-1783324655`, `-1346307632`) and large 64-bit literals (`2948659664LL`, `4136723569LL`) are used purely as state labels to defeat readability and complicate static reconstruction.
- **Dead/unreachable transitions:** Some state values (e.g., the `-1783324655` early-return, `-1346307632` free path) are reachable only through specific state values, padding the CFG.

This pattern is consistent with a **commercial protector / obfuscator** (e.g., VMProtect-style or a custom CFG-flattener) applied across the whole binary.

## 6. Facts vs. Inferences

**Observed facts (directly from code):**
- The function takes a pointer-to-pointer (`void **a1`).
- It calls `GetProcessHeap()` and `HeapFree()` on `*a1`.
- It sets `*a1 = 0` and `a1[2] = 0` after freeing.
- It performs NULL checks on `a1` and `*a1`.
- The code is control-flow flattened with opaque constants.

**Inferred behavior (reasoning):**
- `a1` is likely a small struct/object where index 0 is a heap-allocated buffer and index 2 is its size/length — i.e., a "managed buffer" destructor.
- The presence of this cleanup helper *suggests* the malware allocates and later wipes sensitive in-memory data (decrypted strings, payloads, configs), but this snippet does **not** prove that.
- The obfuscation suggests the surrounding binary is intentionally hardened against analysis; this routine is benign in isolation but part of a protected (likely malicious) sample.

**Conclusion:** This is an obfuscated, benign-in-isolation memory cleanup helper. Its primary forensic value is as a **fingerprint of the obfuscation toolchain** (T1027) rather than as a source of IOCs or malicious behavior.