Reverse Engineering: An In-Depth Analysis of the Bagle (Beagle) Virus

The paper is available here: http://rozinov.sfs.poly.edu/papers/b...ysis_v.1.0.pdf

The goal of this paper is to try to answer the following three questions:
1. How do you reverse engineer a virus?
2. Can reverse engineering a virus lead to better ways of detecting, preventing, and recovering from a virus and its future variants?
3. Can reverse engineering be done more efficiently?

The paper is organized into five sections and two appendixes. Section 1 is the introduction. Section 2 reviews basic x86 concepts, including registers, assembly, runtime data structures, and the stack. Section 3 gives a brief introduction to viruses, their history, and their types. Section 4 delves into the Bagle virus disassembly, including describing the techniques and resources used in this process as well as presenting a high level functional flow of the virus. Section 5 presents the conclusions of this research. Appendix A provides a detailed disassembly of the Bagle virus, while Appendix B presents the derived source code of the Bagle virus, as a result of this research.

The paper is available here: http://rozinov.sfs.poly.edu/papers/b...ysis_v.1.0.pdf

Please comment on it! I appreciate all feedback.

Thanks,
Konstantin Rozinov

Nicely written and coherent. As to your method of using the RCE approach to stop viruses, it's intriguing. Would other processes need to stop or be slowed down if an antivirus program is trying to identify viruses on a machine?

Hi

Interesting paper - well written and complete. Congratulations.

I completely agree that R[C]E is a very useful mean to gain a better
understanding of mechanisms of viri/worms. Actually, I am a bit
surprised that this seems to be presented as something new (no offense,
see below).

I also agree that a FFSig might be a generic characteristica of
a certain type of viri/worms, and that this can be used for a better
detection, prevention and recovery.

But - there is one point I think I misunderstand. Do you plan to
use these FFSig's on the end-users box (for "realtime"-scanning)?
I am really not sure how you would like to do that. In order to get the
FFSig of a certain file (potentially virus/worm), the scanning process
takes much more time than checking for "old-fashioned" signatures.
It might be, that for, as you mention, 90% of viri/worms
which are not packed/encrypted, this is a feasible process, however,
what about the remaining 10%? You need to run them on a virtual machine in order
to inverse the process of packing/encryption to be able to obtain the FFSig
easily. Right? Or is here something I did not get?

And - assume you know how the executable was packed (UPX, ...) and you know
an efficient way to obtain the FFSig nevertheless - THEN I guess that developers
of viri/worms will work on their own packing/encryption mechanism, which might
be altered easily, and I don't think that you will be able to get some
generic method. Hence, we are back at the previous situation.

Still - maybe I misunderstood that issue, so sorry about the crap I've written.
But I would be very interested to understand the details I didn't get.
For sure, R[C]E is useful and, in my opinion, mandatory in the process of
the analysis. But, of course, manpower is always limited.

Thanks&
Cheers

Quote:

---

Originally posted here by hard candy
Nicely written and coherent. As to your method of using the RCE approach to stop viruses, it's intriguing. Would other processes need to stop or be slowed down if an antivirus program is trying to identify viruses on a machine?

---

Hi. Thanks for the feedback! As for your question, I don't see a reason why other processes would need to be stopped. As far as slowdowns, I imagine it would have some impact. I believe the process of looking at function calls is being used nowadays in some AV products. Some vendors call it heuristics. Some vendors emulate a real CPU and allow the virus to run in virtual sandbox in order to determine if it really is a virus. But as you can imagine, this slows down things. I'm not sure about the actual performance hit, though. I recall seeing tools that hook the Windows API and allow you to see the function calls being made in realtime. The FFSig concept can be done by following a similar method. But then the question becomes, what sequence of functions is considered "viral"?

Konstantin Rozinov

Quote:

---

Interesting paper - well written and complete. Congratulations.

---

Thanks!

Quote:

---

But - there is one point I think I misunderstand. Do you plan to
use these FFSig's on the end-users box (for "realtime"-scanning)?
I am really not sure how you would like to do that. In order to get the
FFSig of a certain file (potentially virus/worm), the scanning process
takes much more time than checking for "old-fashioned" signatures.
It might be, that for, as you mention, 90% of viri/worms
which are not packed/encrypted, this is a feasible process, however,
what about the remaining 10%? You need to run them on a virtual machine in order
to inverse the process of packing/encryption to be able to obtain the FFSig
easily. Right? Or is here something I did not get?

---

Yes, the intention is to have FFSig analysis done in realtime. For unencrypted virii this could be done relatively easily using API hooks (after all you need admin access in any case to install the AV product, so hooking into the API could be part of installation). For encrypted/polymorphic/packed virii, this would be a bit more involved, since like you said, we'd need to decrypt/unpack the virus. However, some vendors already have (decent?) solutions for this, i.e. McAfee's scan engine.

Quote:

---

And - assume you know how the executable was packed (UPX, ...) and you know
an efficient way to obtain the FFSig nevertheless - THEN I guess that developers
of viri/worms will work on their own packing/encryption mechanism, which might
be altered easily, and I don't think that you will be able to get some
generic method. Hence, we are back at the previous situation.

---

Yep, they're already doing that to defeat virtual CPUs, sandboxes, etc. Polymorphic viruses keep changing and can easily switch their functional flows (within reason). FFSig is far from perfect as is anything related to AV, and could have high false positives. I just don't know at this point. I'll be working on an implementation for this in the next few months, time permitting. :)

Konstantin Rozinov