You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Capturing static features of a malware instance has always been rather awkward and indirect via the Bundle/Objects approach. As such, given the changes proposed in #104 and #108, we should consider adding a "Static_Features" field directly on the Malware_Subject, used for capturing any PE header information, strings, etc. that were found for the malware instance, through the use of Object_References.
@gtback the main difference is that it allows you to granularly link the results of a particular static analysis to its output. E.g., for a PEFile dump you could just create a single Object, same for a strings analysis, etc. It also allows you to continuously add this data as further static analyses are performed. Having all of it live under the Malware_Instance_Object_Attributes, while cleaner and less verbose, makes this much more difficult to do.
Are you saying there could be more than one Object_Reference inside Static_Features (or more than one Static_Features)? If so, then this makes more sense.
@gtback yup (to the former)! My thought was that multiple Object_Reference fields can exist inside of the Static_Features, each referencing some particular static finding:
Capturing static features of a malware instance has always been rather awkward and indirect via the Bundle/Objects approach. As such, given the changes proposed in #104 and #108, we should consider adding a "Static_Features" field directly on the Malware_Subject, used for capturing any PE header information, strings, etc. that were found for the malware instance, through the use of Object_References.
Thus, it would look something like:
The text was updated successfully, but these errors were encountered: