Reverse Engineering: An In-Depth Analysis of the Bagle (Beagle) Virus
Results 1 to 5 of 5

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

  1. #1
    Junior Member
    Join Date
    Nov 2004
    Posts
    3

    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

  2. #2
    Member
    Join Date
    Feb 2004
    Posts
    33
    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?

  3. #3
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    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
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  4. #4
    Junior Member
    Join Date
    Nov 2004
    Posts
    3
    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

  5. #5
    Junior Member
    Join Date
    Nov 2004
    Posts
    3
    Interesting paper - well written and complete. Congratulations.
    Thanks!


    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.

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •