-
Notifications
You must be signed in to change notification settings - Fork 1
/
plugin.json
25 lines (25 loc) · 8.84 KB
/
plugin.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
{
"pluginmetadataversion": 2,
"name": "Blackfin Architecture Plugin",
"author": "sen",
"type": [
"architecture"
],
"api": [
"python3"
],
"description": "A Binary Ninja architecture plugin for the AD Blackfin architecture",
"longdescription": "## Analog Devices Blackfin Architecture Plugin\nA Binary Ninja architecture plugin for the AD Blackfin architecture. It includes a standalone disassembler, and fairly robust lifting capabilities.\n\n## Disassembler\nThe disassembler used in this plugin (relagated to the disassembler/ subdirectory) can be used as a standalone decomposer/disassembler, and is not tied to the binaryninja API. It outputs tokenized structures representing each parsed machine code instruction, which can be parsed as desired by the disassembler frontend.\n| ![Disassembly](images/disasm.png) |\n|:--:|\n| *Yes, this is disassembly, not LLIL -- Blackfin uses arithmetic syntax for assembly* |\n### Instruction Support\nDisassembly of all instructions defined in the Blackfin Processor Programming Reference (Rev 2.2) is implemented. Additionally, a set of `pseudo_` instructions are implemented based on the libopcodes blackfin instruction parser, though these instructions do not appear in the above reference manual.\n\nThis disassembler supports only the Blackfin ISA, and _not_ the Blackfin+ superset used on BF7xx processor models. In addition to several new instructions, the Blackfin+ ISA also features a number of additional registers, and support for and usage of 64 bit instructions. At a minimum, support for detecting 64 bit instructions is planned, which would at least allow for disassembly of Blackfin compatible instructions in a Blackfin+ image.\n\n## Lifter\n| ![HLIL](images/hlil.png) |\n|:--:|\n| *HLIL output example* |\n\nThe lifter is mostly complete, with all standard operations supported, but lacking in support of some of the more complex/unusual DSP instructions and operating modes, including operations which saturate rather than overflow, and things like add with reverse bit carry that are complicated to implement correctly in BNIL. Additionally, some vector operations have yet to be implemented.\n\n## Architecture Misc.\n- Currently one standard calling convention (used by the bfin-* compilers, on uCLinux) and one system calling convention (same compilers) are defined.\n- Extremely rudimentary ELF relocation handling is implemented via BlackfinElfRelocationHandler, and this handler is registered to the BinaryNinja Elf view with machine_id == 106.\n- Equally rudimentary bFLT relocation handling is implemented via BlackfinBFLTRelocationHandler. Most of the heavy lifting for this handler is implemented in the bFLT view plugin.\n\n## Known Limitations\n- No lifting support for some DSP operatations\n - Proper handling of flags: In most cases, conditionals are evaluated based on a manually set CC flag. However in some cases, the dedicated flags (AZ, AC, etc.) are used via the CCFlag instruction -- this instruction is not currently lifted, and flags are not set by operations presently.\n - DSP multiplication operations, with/without fractionality, with/without saturation\n - DSP vector shift operations\n - PACK operation\n - ABS operation\n - DSP 'to reg from accumulator' move operations (saturation, fractionality)\n - Accumulator/accumulator arithmetic\n - DIVQ and DIVS division primitives\n - ROT instruction edge cases; common cases handled by lifter\n - Vector addition/subtraction edge cases; common cases handled by lifter\n - EXTRACT instruction\n - SIGNBITS instruction\n - ALIGN8, ALIGN16, ALIGN32 instruction\n - DSP LSHIFT operation\n- Out-of-spec handling of 16 bit immediate loads\n - A common pattern observed in a number of sample binaries was the usage of a `reg.h = imm16; reg.l = imm16` idiom for loading a 32 bit immediate into a full width register. In most cases, the high load immediately precedes the low load, and as such the lifter combines the two operations into a single 32 bit load, which improves the resulting IL. However, in some cases the two operations are split up, and the resulting IL becomes messy, and breaks Binary Ninja's Value Set Analysis (VSA). In order to combat this, the lifter currently interprets a lone load high instruction as a 32 bit load to the full width register, assuming that the low bytes will be overwritten by a load low at some point before the register is read. This has been true in all cases observed during the development of this plugin, but _does not follow the Blackfin spec_ and technically produces incorrect IL. So far, the risk of occasional incorrect IL is outweighed by the greatly improved IL in the majority of cases, but be warned.\n- No support for parallel execution\n - Blackfin ISA supports the parallel execution of up to three instructions at once. This is not implemented in the disassembler or lifter at present, and input machine code is treated as entirely sequential. As a consequence, under very specific circumstances the resulting disassembly may be misinterpreted -- for example, when one instruction in the parallel issued set sets a register, and the next in the set uses that same register as a source. In reality, because the instructions are being executed in parallel, the value of the register used in the latter operation will not have been updated at execution time, but the disassembly output will indicate that this _is_ the case.",
"license": {
"name": "GPL-3.0",
"text": "Copyright 2022 sen\n\nThis program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.\n\nThis program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.\n\nYou should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>."
},
"platforms": [
"Linux"
],
"installinstructions": {
"Linux": "##Installing\nCopy the libarch_blackfin.so binary to the binaryninja plugin directory.\n## Building From Source (Adapted from Vector35/arch-armv7)\nBuilding the architecture plugin requires `cmake` 3.9 or above. You will also need the\n[Binary Ninja API source](https://github.com/Vector35/binaryninja-api).\n\nFirst, set the `BN_API_PATH` environment variable to the path containing the\nBinary Ninja API source tree.\n\nRun `cmake`. This can be done either from a separate build directory or from the source\ndirectory. If your app is installed in a non-default location, set BN_INSTALL_DIR in your\ncmake invocation, like `cmake -DBN_INSTALL_DIR=/Applications/BinaryNinjaDEV.app/'.`\nOnce that is complete, run `make` in the build directory to compile the plugin.\n\nThe plugin can be found in the root of the build directory as `libarch_blackfin.so`,\n`libarch_blackfin.dylib` or `arch_blackfin.dll` depending on your platform.\n\nYou can copy the plugin into the user plugins directory (you can locate this by using the \n'Open Plugin Folder' option in the Binary Ninja UI).\n\n## Build Example\n\n### acquire repositories\n```\nmkdir ~/repos/vector35\ncd ~/repos/vector35\ngit clone git@github.com:Vector35/binaryninja-api.git\ngit clone git@github.com:git@github.com:Ethan-ks/arch-blackfin.git\n```\n### environment variables\n\n`export BN_API_PATH=~/repos/vector35/binaryninja-api`\n\n### cmake, make\n```\ncd arch-blackfin\nmkdir build\ncd build\ncmake ..\nmake\n```\n## Build Troubleshooting\n\n### example\n\n CMake Error at CMakeLists.txt:8 (message):\n Provide path to Binary Ninja API source in BN_API_PATH\n resolution:\n ensure BN_API_PATH is in your environment\n\n### example\n\n CMake Error at /Users/andrewl/repos/vector35/binaryninja-api/CMakeLists.txt:53 (message):\n Binary Ninja Core Not Found\n resolution:\n ensure BN_INSTALL_DIR is supplied at command line invocation of cmake\n ensure some bad directory is not cached in CMakeCache.txt\n\n### example\n\n cmake seems to ignore your setting of BN_INSTALL_DIR and other cmake variables\n resolution:\n rm CMakeCache.txt\n\n### example\n\n undefined symbols at link time, like:\n Undefined symbols for architecture x86_64:\n '_BNClearUserVariableValue', referenced from:\n BinaryNinja::Function::ClearUserVariableValue(BinaryNinja::Variable const&, unsigned long long) in libbinaryninjaapi.a(function.cpp.o)\n resolution:\n ensure that your api repo is on the same channel and at the same commit as the libbinaryninjacore you're linking against\n eg: binaryninja is on dev update channel and is up-to-date and binaryninja-api repo is on branch dev with latest pulled"
},
"version": "0.1.1",
"minimumbinaryninjaversion": 3
}