Consider adding heapstring characteristic?

[mbevilacqua]

Summary

Thought this was a stackstring fail but it seems to be a heapstring? not sure if this is prevalent enough but feature extraction could be nice.

Ref: 0d37ad7dcfd65456d7079793b2fe3f737ceccfbecc88e69f6528d1d3922b0b88@40B4EA

.text:000000000040B4E5                 mov     edi, offset ssl_x ; filename
.text:000000000040B4EA                 mov     cs:ssl_x, 2Fh ; '/'
.text:000000000040B4F1                 mov     cs:ssl_x+1, 75h ; 'u'
.text:000000000040B4F8                 mov     cs:ssl_x+2, 73h ; 's'
.text:000000000040B4FF                 mov     cs:ssl_x+3, 72h ; 'r'
.text:000000000040B506                 mov     cs:ssl_x+4, 2Fh ; '/'
.text:000000000040B50D                 mov     cs:ssl_x+5, 73h ; 's'
.text:000000000040B514                 mov     cs:ssl_x+6, 68h ; 'h'
.text:000000000040B51B                 mov     cs:ssl_x+7, 61h ; 'a'
.text:000000000040B522                 mov     cs:ssl_x+8, 72h ; 'r'
.text:000000000040B529                 mov     cs:ssl_x+9, 65h ; 'e'

[mike-hunhoff]

nice catch - I wonder if we should consider rebranding characteristic: stack string as something like characteristic: dynamic string or characteristic: obfuscated string:

pros:

• cover more cases, like this, or .NET obfuscated strings

cons:

• overloading the meaning may cause confusion (potentially not specific enough)
• rules must be updated

[williballenthin]

import floss

agree it would be nice to catch this, and we probably could relax the stackstring detection logic to detect this global dynamic string (and also heap strings). only counterpoint (from my perspective) is implementation complexity, so lets just be sure to manage that.

i also like the idea of generalizing the stackstring characteristic, or even better, slowly deprecating it for a more general characteristic that we can use in parallel.