Added ESP Unpacker #412
Added ESP Unpacker #412
Conversation
| LOGGER = logging.getLogger(__name__) | ||
|
|
||
| ESP_BINARY_MAGIC = 0xE9 | ||
| ESP8266V2_BINARY_MAGIC = 0xEA # In the esptool.py code, but haven't seen it in the documentation |
There was a problem hiding this comment.
I'm not sure about this, 0xE9 and 0xEA will match a lot of arm instructions, we might just have to tag manually if there isn't a larger magic we can find.
There was a problem hiding this comment.
I was concerned about that as well. I could implement a more heuristic based approach. Byte 2 (zero index) is the flash mode which is always 0,1, 2, or 3 and the lower half of byte three is always 0, 1, 2, or 0xf. If you think that would narrow it down enough I can implement that. If we go the manual tagging route, do I just remove the identify function?
There was a problem hiding this comment.
The more constraints, the better.
If manual tagging turns out to be the only way to avoid a very high false positive ID rate, then the Identifier component as a whole can be removed.
| ) | ||
|
|
||
|
|
||
| # TODO: Program or Generic Binary? Not sure... |
There was a problem hiding this comment.
I think Program is indeed appropriate here. If it's something can can be broken up into memory sections, it usually makes sense as a Program.
Another related consideration is whether it has an entry point - this isn't part of the Program at the moment, but it's something I think would make sense to add to the general model of what a Program is. So I'm curious about this case, does ESP32 define and entry point?
| return False if image.wp_pin == image.WP_PIN_DISABLED else True | ||
| return None | ||
|
|
||
| # TODO: Probably useful to display chip name but not sure where to put it atm |
There was a problem hiding this comment.
For things like this, it makes sense to add attributes to the ESP class and split the logic to parse these out into an analyzer. Sometimes there is overlap with the unpacking logic, and that's okay: the unpacker can call the analyzer and the code doesn't need to be duplicated.
One sentence summary of this PR (This should go in the CHANGELOG!)
Added an ESP unpacker to support unpacking Espressif binaries.
Link to Related Issue(s)
#410
Please describe the changes in your request.
Added esp.py to ofrak_core/ofrak/core which contains multiple resource view for ESP binaries as well as identification and unpacking. Uses ESPTool.py for most of the work.
Anyone you think should look at this, specifically?
@rbs-jacob
There are multiple "TODO:"s located in the code, a few of which are notes for things I'm unsure about, and the rest are questions that I couldn't find answers to in the contribution guidelines.