Thank you for contributing an issue!

Welcome to the EMBA firmware analysis community!

We are glad you are here and appreciate your contribution. Please keep in mind our contributing guidelines here and here.
Also, please check existing open issues and consider to open a discussion in the dedicated discussion area.
Additionally, we have collected a lot of details around EMBA, the installation and the usage of EMBA in our Wiki.

If you like EMBA you have the chance to support us by becoming a Sponsor or buying some beer here.

To show your love for EMBA with nice shirts or other merch you can check our Spreadshop.

This is an automatic message. Allow for time for the EMBA community to be able to read the issue and comment on it.

Hi @B1TC0R3

good to hear you are working on EMBA stuff. Looking forward to the results.

I would recommend to build a S-module. Looks as you are doing some further python analysis. Probably the easiest way would be to integrate it into the already available python module (S21) as dedicated function. If your module is getting bigger a dedicated module would be another option. The next available number would be S28.

You have already found the contribution docs. We are currently refactoring EMBA to name all local variables in the format lVAR_NAME -> see the l as first letter. You should always ensure your code passes the strict mode (start firmware analysis with -S parameter) and test it with multiple linters via check_project.sh.

If you have further questions feel free to open issues or use this one

Now I have seen your module and you should use a dedicated module for such a runner.

btw good idea to build such a python runner

Thank you!

Should I still add it as an "S" module?

There's a lot of bench-marking necessary before I can tell whether Bash or Python is more viable for my use case,
but I plan on adding more emulation/dynamic analysis on top of this, primarily checks with PEASS-ng, Metasploits exploit suggester and some more optional NMAP scans.

In case Bash is marginally faster, I will add these other changes separately in the "L" or "Q" category tho.

As you are poking with the emulation engine you need to move your modules to the L(ive testing) area (after L10 which is doing the main emulation stuff). If you plan modules which are working on the filesystem (no system emulation) you need to add S modules.

Some of your mentioned checks are already available:

• Metasploit in L35
• Nmap integrated in L10 and in L15

Makes sense.

In this case I will add the current code for the python runner as "S28" and see whether and how I can add
python scripts to live testing later on.

I still need to verify my code with strict mode and check_project anyways.

@m-1-k-3
Hello again.

The changes are almost done, I am currently verifying the last few things.
Meanwhile, I have tried to figure out how to contribute to the wiki in order to add documentation for the new feature,
only to find out that this is rather difficult/not supported on Github.

What would be the best option to provide you with my doc files once the patch is fully ready?

What would be the best option to provide you with my doc files once the patch is fully ready?

Yea ... The Github wiki is a bit ugly in collaborating. Probably the easiest way would be to write the doc into a comment here and I will transfer it to the wiki and add you as author.

I understand.

I will see that I get the bigger changes and documentation written until the end of the month.