Open nicole-ashley opened 5 years ago
Do you know of any tool that extracts the elf file from the .bin image? I'm seeing 7 segments and will probably end up dumping all of them, but I was just wondering if there is a ready made tool that does this already.
@mpsOxygen isn't it other way around? The firmware bin image should be a pure executable (just machine code + program data). ELF format defines a container for linkable execs (more or less) which is much more than what you have in the bin file. Microcontrollers usually don't use ELF, just pure machine code, as the entry point to the application is predetermined depending on the µC used.
He explains it better than I can: https://www.youtube.com/watch?v=w4_3vwN_2dI
So the initial app is just an elf then that gets converted to esp32 binary format. They also wrote a tool, you can find it here: https://github.com/tenable/esp32_image_parser
Haven't used it yet.
OK, it's more like a conversion between formats than extraction. The main issue is the lack of support for raw image format in the IDA Xtensa module. In addition to their tool there's also a custom IDA loader which is actually able to load raw image directly, without the manual conversion to ELF (it's mentioned briefly in the video at ~5:24): https://github.com/jrozner/esp-image-ida
I am using Ghidra and tried with this: https://github.com/tslater2006/esp32_flash_loader But it did not work. The image parser does not work either. I am starting to run out of ideas...
Do you also have this module? https://github.com/yath/ghidra-xtensa It's needed for Ghidra to understand ESP32 machine code.
@yawor Yes I have the xtensa CPU extension added.
@rezmus Did you pull the firmware of the device or downloaded it from the cloud? I think this bin only contains a sort of diff to be updated and not the full firmware.
Can I also get the file?
it's just ota, i don't have this model.
Thanks for the file. This a content of an application partition (doesn't matter if it's a factory, OTA1 or OTA2, the application format itself is the same). It means it's a complete executable running on the device, so it should be possible to disassemble it, but it's going to require some work. I'll look into it.
I've been able to convert the app image into ELF format after fixing the image2elf
function a little (I've just had to add a single line) and calling it from another python file instead of using their command line parser and logic. The Ghidra loads the file and is able to analyse it.
The problem is that during the build process, when ESP-IDF generates bin image from compiled elf files, the symbol table is dropped, so function positions, variables, labels etc are lost. All you get is a lot of Xtensa assembler and few functions which Ghidra tried to decompile back into C.
Looks like the yath Xtensa Processor for Ghidra is a bit lacking. Using this one I've had way better results: https://github.com/Ebiroll/ghidra-xtensa
Also use this svd loader plugin with the esp32.svd file in order to get all the peripherals: https://github.com/leveldown-security/SVD-Loader-Ghidra
Also using the C header files from esp-idf with Parse C source helps with some of the types.
Unfortunately there are so many functions and no names that it is really hard to pick out the ones that handle IR. :(
A lot of the code is from stdlib and ESP-IDF. Quite large part is the FreeRTOS code, which implement multi-threading. But recognising which parts of the binary contain what may be quite difficult task for sure.
I have a model of the Xiaomi IR remote that reports as
chuangmi.remote.h102a03
. It works fine when capturing and replaying those captured raw commands, but any commands converted from Pronto do nothing - no flashing light, no response from the target device, but - quite puzzlingly - anok
response from the device's API.Here is the device on Ali Express.
Here are some examples:
Unfortunately I don't have a clue where to start, or I'd tinker with the code myself. I'm happy to work with you if you need to test things on my device.