[Advanced] “Does that function really just copy?” 🕵️‍♂️ Catching Covert Subroutines Missed by Analysts, with AI

Hello, security researchers who aim for in-depth analysis! 🦅

What is the most common mistake we make when analyzing malware? It’s “Assumption”.

In the main function, we encounter countless CALL instructions. “Hmm, FUN_00401200? Looking inside, it takes two parameters and loops? It’s probably just a string copy function like strcpy or memcpy. Pass!”

…The moment you pass it by, you might have fallen into the malware author’s trap. 😱 Malware authors often hide decryption logic or anti-debugging code inside ‘seemingly simple subroutines’ that analysts might skip out of laziness.

Today, we will practice an advanced technique to uncover the hidden claws of subroutines that analysts often overlook, through cross-validation with AI.

---

1. The Subroutine Dilemma: “Do I have to look at all of this?” 😫

Malware consists of hundreds, even thousands, of functions. It’s impossible to dissect each one. So, we empirically judge by looking at ‘patterns’.

• Pattern A: Loops and counts until 0 -> It’s strlen (string length calculation). (Skip)
• Pattern B: Moves bytes from source to destination -> It’s memcpy (memory copy). (Skip)

But what if that function is copying and simultaneously decoding malicious shellcode? 💣

---

2. Practice Scenario: Disguised Function FUN_CopyOrNot 🎭

Let’s assume you found the following C pseudocode in Ghidra.

// Code easily mistaken by analysts as 'simple copy'
void FUN_CopyOrNot(byte *dest, byte *src, int length) {
  int i;
  for (i = 0; i < length; i = i + 1) {
    byte bVar1 = src[i];
    // ... some complex variable assignment ...
    if ((i % 5) == 0) {
        // A conditional statement an analyst might casually overlook
        dest[i] = bVar1 ^ 0x41; 
    } else {
        dest[i] = bVar1;
    }
  }
  return;
}

A quick glance by human eyes makes it look like a copy function that moves src to dest. There’s an if statement in the middle, but it’s easy to just pass it off as “oh, it’s probably just padding or encoding.”

However, hidden within it is a deobfuscation logic that performs XOR 0x41 (Key ‘A’) on every 5th byte. If you miss this, you’ll see incorrect data in the subsequent code.

---

3. AI Cross-Validation: “Suspect, and Suspect Again” 🧐

Now, let’s throw this code at AI and attempt cross-validation. The important thing here is not to ask “summarize this simply,” but to ask “find anything unusual.”

❌ Bad Prompt (General Summary)

“What does this function do?” -> AI Answer: “This function copies a source array to a target array for a given length. Specific conditions change values.” (Too generic to sense danger)

✅ Good Prompt (For Cross-Validation)

[Role Assignment]

You are a security analysis expert who finds hidden techniques in malware.

>

[Goal]

The code below looks like a simple memory copy function (memcpy). However, I suspect this function has ‘side effects’.

>

[Request]

>

1. Precisely point out how this function differs in its outcome from standard library functions (strcpy, memcpy, etc.).

2. If there are lines where data is modified, find them and interpret their meaning (XOR, Shift, etc.).

3. Infer what purpose this technique is typically used for in malware.

>

[Code] (Paste the code above)

---

4. AI Analysis Result: “Busted!” 🚨

When given a proper prompt, AI dissects the code like a microscope.

🤖 AI Analysis Report

>

1. Anomaly Detection This function is not a simple memcpy. Standard copy functions transfer data as-is, but this function performs conditional data modification.

>

2. Core Logic Analysis

>

– if ((i % 5) == 0): A branch occurs every time the index is a multiple of 5.

– dest[i] = bVar1 ^ 0x41;: An XOR 0x41 operation is performed. This is not a simple copy, but an ‘inline decryption’ process.

>

3. Analyst Advice The data (dest) after passing through this function will have different content from the original data (src). If src was encrypted shellcode, dest will contain executable attack code. You must never label this function as ‘simple copy’ and move on!

---

5. Our Response: Renaming the Function 🏷️

Thanks to AI, we avoided the trap. Now, back in Ghidra, there’s only one thing to do.

1. Right-click on function name FUN_CopyOrNot
2. Click Rename Function
3. Change to Decryption_Copy_XOR_41

Now, everywhere this function is called, it will be intuitively clear: “Ah! That was for decrypting!” Properly analyzing just one subroutine can magically unravel the flow of the entire program. 🗝️

---

💡 Today’s Tip (Takeaway)

• Don’t ignore subroutines: The devil is in the details (Helper Function).
• Compare with standard functions: Ask AI, “Is this 100% identical to strcpy?”
• Look for magic numbers: If constants like 0x41, 0xFF suddenly appear in the middle of the code, always be suspicious.
• Use AI as a ‘Red Team’: Ask inverse questions like, “Did I miss any vulnerabilities or tricks?”

May your analysis vision become wider and deeper with AI! Next time, we’ll return with the pinnacle of analysis, “Automating Analysis Reports.”

Happy Reversing! 💻✨

---