Armv7: Instruction Disassembly/Lifting Completion #3968
Comments
|
asr r2, r2, r8 is incorrectly lifted to r2 = r2 s>> 0 |
Fixed in dev |
|
Just wondering, any idea when lifting will be finished for parsed instructions? I was looking at something that used these instructions and had a bunch of "unimplemented" warnings in the low and medium level IL view:
|
|
A few more thumb2 examples where lifting is unimplemented as of 1.1.1461-dev: The corresponding |
|
A few thumb examples where lifting is unimplemnted as of 1.1.1344: |
|
Found some more armv7 examples that are not disassembled or lifted.
Digging deeper and it looks like all the aes instructions are missing, so the list above is incomplete. Additionally, there are some vector instructions that don't show the proper disassembly (operands are missing).
|
the table says mla is lifted but 1.2.1968-dev build shows it as unimplemented |
I can confirm, and it causes serious issues with any dataflow analysis that may be dependent on those unlifted instructions without any way to tell from IL that a dependent value may be invalid. I guess the dataflow analysis has no way to detect that there was an unlifted instruction in the dataflow somewhere, so I can't even check if this is happening without writing some architecture-specific code. |
|
Is there any prospect of having these revisited soon? I'm starting to contemplate hacking up my own arch plugin to implement a number of these to avoid situations where looking at dataflow leads me down the wrong path due to the unlifted instructions. |
|
Could you share a binary that has missing instructions to serve as a bench mark? |
|
When I see these, it tends to be in batches of one or two instructions per firmware I look at, so I don't have anything I'd consider a good benchmark for "completion". I'm happy to DM binaries/bndbs that I can share as I hit them, though - I just hit one that uses |
|
Priority list from 3pidemix |
|
PSP and MSP MSRs are incorrectly disassembled as APSR(_nzcvq) in Thumb2 mode. Assemble with e.g. Edit: Same deal for the PRIMASK register |
|
A few of these these I've implemented lifting support by my own plugin (using Capstone as the instruction decoder as I understand the internal decoder is not exposed by the API) but I'm still missing a ton of these. (dumped essentially via grep) I would add lifting support (obviously 100% coverage isn't needed but I prefer to have less unimplemented :P) , but I believe BN is missing support for vector instructions in #1213. Obviously not all of them are the same priority :) |
At least for now, you can lift most vector operations as a series of scalar operations. e.g. a The simple stuff like vector-width moves/loads/stores can be lifted simply using wide registers -- binja doesn't mind if you define a 128-bit register. Some of those basic operations are lifted in x86_64 for example. |
|
unimplemented {umull r3, r6, r2, r3} |
|
Still stays unimplemented for v* and few s* instructions [SAD] |
|
For MRS/MSR, you could probably just convert them into some kind of intrinsic for the most part. |
fuzyll
added
Component: Architecture
plafosse
added
the
Impact: Medium
xusheng6
added
the
Type: Enhancement
The following is the list of instructions which we currently disassemble and lift (Fully or Partially). If you have any instructions which differ from this table, there is likely a bug or a documentation failure, please let us know (also if you could provide the opcodes that would be great).
The text was updated successfully, but these errors were encountered: