VMRay and dynamic improvements #2537
Conversation
| assert (sv2p.pid, sv2p.monitor_id, sv2p.origin_monitor_id) == ( | ||
| vmray_monitor_process.pid, | ||
| vmray_monitor_process.monitor_id, | ||
| vmray_monitor_process.origin_monitor_id, | ||
| ) |
There was a problem hiding this comment.
thoughts on being even more lenient here and not asserting this but just reporting it?
I'm encountering more inconsistencies between the two files, e.g., the monitor_id not being set
There was a problem hiding this comment.
so we could do the check and just log it
There was a problem hiding this comment.
I'm hesitant to be lenient here because we rely on sane process and thread monitor IDs for indexing. I'd consider differences between SummaryV2.json and flog.xml to be VMRay bugs and, if true, can we trust capa's results at that point?
There was a problem hiding this comment.
Right, let's leave as is until we find more samples that fail.
| assert (sv2p.pid, sv2p.monitor_id, sv2p.origin_monitor_id) == ( | ||
| vmray_monitor_process.pid, | ||
| vmray_monitor_process.monitor_id, | ||
| vmray_monitor_process.origin_monitor_id, | ||
| ) |
There was a problem hiding this comment.
I'm hesitant to be lenient here because we rely on sane process and thread monitor IDs for indexing. I'd consider differences between SummaryV2.json and flog.xml to be VMRay bugs and, if true, can we trust capa's results at that point?
| assert (sv2p.pid, sv2p.monitor_id, sv2p.origin_monitor_id) == ( | ||
| vmray_monitor_process.pid, | ||
| vmray_monitor_process.monitor_id, | ||
| vmray_monitor_process.origin_monitor_id, | ||
| ) |
There was a problem hiding this comment.
Right, let's leave as is until we find more samples that fail.
| @@ -276,7 +276,7 @@ class ElfFileHeader(BaseModel): | |||
|
|
|||
| class ElfFile(BaseModel): | |||
| # file_header: ElfFileHeader | |||
| sections: Optional[list[ElfFileSection]] = None | |||
| sections: list[ElfFileSection] = [] | |||
There was a problem hiding this comment.
incidentally, is this the correct way to set the default value, particularly as a list? i see this pattern used throughout the file.
my worry is that the default value = [] uses the same instance of a mutable list, rather than copies of it. sorta like when you have a kwarg parameter def foo(bar=[]).
in the past, i've used pydantic.Field for these. but maybe pydantic is extra smart and doesn't require this. @mr-tz @mike-hunhoff
There was a problem hiding this comment.
hm, great question, this is how mypy accepted the change and I saw the pattern throughout. Other files use Optional[list[<foo>]] = None or Field, we should cleanup the inconsistencies (separately).
There was a problem hiding this comment.
My understanding is that pydantic handles this correctly (i.e. deep copy) for non-hashable default values (i.e. lists). source: https://docs.pydantic.dev/latest/concepts/models/#fields-with-non-hashable-default-values
There was a problem hiding this comment.
whoa that's cool!
so, looks good to me. and maybe we can update our remaining code to use this pattern.
A few improvements based on analysis of around 200 random VMRay archives.
Checklist