A200K
commented
1 year ago Hey there,
I played around a bit with some ARMv7 binary and it seems that indeed operands are not converted into wildcards, if that's what you mean (take a look at this example):
The signatures work just fine, but will probably be broken on the next compile of the binary.
To be honest though, I don't have much experience with ARM, I can't seem to understand what part of the bytecode is the actual operand (here: __snprintf_chk):
.text:0023B130 8F 78 FA EB BL __snprintf_chk ; Branch with Link
_snprintf_chk is located at:
.plt:000D9374 ; int __fastcall _snprintf_chk(_DWORD, _DWORD, _DWORD)
8F 78 FA EB is the bytecode.
What part of 8F 78 FA EB is pointing to D9374? It does not seem to be a relative offset based on the virtual adresses either.
The IDA Plugin API basically says at that point that the operand offset is unknown (both offb and offo are 0):
It manages to extract "D9374" as the operand value though. The API does not provide any further info about this, so based on this, I have no way of elegantly wildcarding operands for ARM code (yet).
I noticed though that BL instructions always look like XX XX XX EB. The previous 3 bytes might be some sort of index for some variable table, or some offset? Operand offset 0 actually makes sense then, but the ida documentation says otherwise. Either way, I could try to implement a workaround for this. I would have to find the operand length though in some way.
I'll take a deeper look at how ARM bytecode actually works. I would have preferred it if the IDA plugin api actually provided more info on this (e.g. operand length) but I'll see what I can do. Thanks for letting me know :)
i want use it with arm v7 but its take all the bytes , can you make it support arm v7