It's very possible. Recently I had to manually patch code that was (in assembly) a conditional jump on conditions that at runtime were always true or always false, so the "conditional" part was a red herring.
The fact that the conditional was there confused IDA such that it miscalculated the stack usage for many of the functions in the binary and refused to designate them as procedures (which can be decompiled).
The telling part was that these conditionals had no other purpose other than to confuse IDA, so you could see the intent was malicious.
That's just one example. You REALLY have to know what's going on with the hardware and the intentions of malware authors so you don't blindly accept what your tools are telling you. That's what makes the difference between someone who can do reverse engineering for a living and someone who is good at it.
EDIT: One more thing...debugging malware is a last resort; it's very easy to behave one way for a debugger while doing something completely different elsewhere. If you start with automated detection/debugging tools you spend most of your time working around debug detection.
If you'd like to know more my email address is in my profile.
That's very interesting. Thank you for correcting me. I'd like to know more, but everyone else probably would, too. Personally, I'm curious about the backstory behind that particular piece of software, and also about any other tricks you've noticed.
The backstory is pretty simple; I analyze malware and this was a sample. It's difficult to talk about publicly because if you reveal too much, it's a chance for the malware authors to recognize they've been made and change what they're doing.
What's interesting is that if you've seen enough samples, you can make educated guesses about the authors, their intentions, and level of competence. In this case, the authors were obviously aware that someone might try to reverse engineer the software so they threw that little red herring in. I have no idea why, and it was only in certain functions and not others. But you do know the authors had a clue about IDA and similar static analysis tools and were trying to make it more painful to analyze. It certainly wasted a couple of hours of my time.
Fortunately the obfuscations make software like that easier to detect, so it's a balancing act the author has to play.
If I ever stop analyzing malware there might be a very interesting blog series on all the boneheaded mistakes malware authors make when they obfuscate their code. I could teach a six-month course on what not to do with crypto just from all the approaches I've seen.
I played around in the cheat scene as a kid and what you are describing sounds like someone who didn't know what they were doing either a) copy-pasting from or b) using a toolkit provided by someone that did.
The fact that the conditional was there confused IDA such that it miscalculated the stack usage for many of the functions in the binary and refused to designate them as procedures (which can be decompiled).
The telling part was that these conditionals had no other purpose other than to confuse IDA, so you could see the intent was malicious.
That's just one example. You REALLY have to know what's going on with the hardware and the intentions of malware authors so you don't blindly accept what your tools are telling you. That's what makes the difference between someone who can do reverse engineering for a living and someone who is good at it.
EDIT: One more thing...debugging malware is a last resort; it's very easy to behave one way for a debugger while doing something completely different elsewhere. If you start with automated detection/debugging tools you spend most of your time working around debug detection.
If you'd like to know more my email address is in my profile.