Search memory for little-endian value

[comex]

What is the feature you'd like to have? In the Find dialog, when searching for a hex string, I'd like some kind of option to byteswap the value.

For example, suppose there's data or code at address 0x12345, and I think there might be a pointer to it in a data segment somewhere which hasn't been analyzed (and thus doesn't show up in the xrefs list). To find this, as far as I know, I would need to open the Find dialog and type 452301 (maybe with some zeroes following it to avoid false positives). But byteswapping in my head is annoying, so I'd like to be able to type 12345 and have Binary Ninja byteswap it for me.

Are any alternative solutions acceptable? In the case of pointers, some kind of "search for pointers to this address" command would be even easier; beyond that, auto-identifying pointers based on heuristics (#1189) or relocations (#3371) would make manual searches less necessary.

But pointers aren't the only use case; this would also be useful when searching for integer constants.

Additional Information: In IDA, if I recall correctly, sequences of hex digits not separated by spaces are automatically byteswapped when analyzing little-endian images. For example, 1234 5678 would be equivalent to 34 12 78 56. Binary Ninja seems to not treat spaces as meaningful.

[psifertex]

Constant search might help with this as that should account for the platform endianness, but there might be some cases where that doesn't work so I still think this is a worth while requets. Search in general needs another round of features, tagging this as related to #2788 so we can take a look at it when we swing by that code next.

Thinking about it some more, changing behavior based on spaces or not seems a bit dangerous from a principle of least surprise so we probably wouldn't implement it that way.

And after a bit more thought, switching to disassembly view and doing a constant search there might indeed solve most use cases except for situations where you're mixing patterns/wildcards?

[0bs3n]

Regarding your suggestion of using constant search above, I don't believe this works in the case above, since "in a data segment somewhere which hasn't been analyzed" is specified. In that scenario there would be no constant value in disassembly or any other view. This also breaks if instead of direct pointers to data, the data is referenced as an offset from the start of some table.

For example, a scenario where I ran into this and wished the behavior existed was when trying to figure out the format/location of a symbol table in an embedded firmware file. I knew where the string table was, but didn't know where the symbol table that referenced the string table was located and no part of it had been marked by automatic analysis. By searching for a hex string matching the locations of strings in the string table, I was able to find where those locations were referenced as pointers and eventually the symbol table. Doing this required that I had to manually swap the endianess of the string table addresses when searching, and because neither the symbol or string table had been identified by automatic analysis (and were not referenced in the code except as table + offset) no search other than hex string search returned any results.

[plafosse]

"Constant" search searches the text only. It gets each tokenized line and finds tokens whose .value property matches the specified constant.