Missing Architecture QCOM DSP6

[jlucius]

Is your feature request related to a problem? Please describe.
When analyzing Android images that run on Qualcomm CPUs there might be libraries and code that run on the Qualcomm Hexagon DSP. https://en.wikipedia.org/wiki/Qualcomm_Hexagon

Currently this architecture is not supported, so emba returns error messages for these files:

Something went wrong ... no supported architecture available

[-] Tested binary: /logs/firmware/patool_extraction/lib/

[-] Please open an issue at https://github.com/e-m-b-a/emba/issues

File output:
ELF 32-bit LSB shared object, QUALCOMM DSP6, version 1 (SYSV), dynamically linked, no section header

Describe the solution you'd like
Support to analyze Hexagon files, which would mean to introduce an additional architecture in emba. objdump probably does not support the hexagon architecture so far I only found references to the Qualcomm SDK which is not freely available, but radare2 should support it.

Additional context
I can put some work into this, if this is of interest for the emba project. In case there is interest an idea where to start would be great.

[m-1-k-3]

This would be great to integrate into EMBA. Looks like objdump does not support it by default. Could you do a double check on this?
Usually we need to adjust/check multiple areas in EMBA to integrate a new architecture:

• Helper

  emba/helpers/helpers_emba_prepare.sh

  Line 154 in 20ca024

  architecture_check()

• Helper

  emba/helpers/helpers_emba_dependency_check.sh

  Line 540 in 20ca024

  architecture_dep_check() {

• S14 - radare support
• S115 - qemu user mode support (see Hexagon support #467)
  - [ ] S13 - objdump support -> currently not supporte from objdump
  - [ ] l10 - qemu system mode support -> not supported from qemu-system

I can give further support on every step.
Could you share the firmware you are working on?

[jlucius]

Will have a look at it, no unfortunately I cannot share this firmware, but all mobile phone android systems for Qualcomm should have this, will also look if I find some freely available firmware.

[m-1-k-3]

Keep us updated and if you need some help ping me

[m-1-k-3]

I have introduced a basic detection in #399
Could you do a quick check?

[jblu42]

Seems to work so far:

[[0;33m*[0m] Architecture auto detection (could take some time)

[0;33mArchitecture  Count[0m
[0;33mARM           493[0m
[0;33mARM64         713[0m
[0;33mQualcom DSP6  15[0m

[jblu42]

@m-1-k-3 : I wanted to add the QCOM6 to the radare2 analysis, I have two questions about this:

• in MIPS the command has an additional "s", is this intentional or a copy&paste error?
  r2 -e io.cache=true -e scr.color=false -q -c 'pI $ss' "$BINARY_"
  all other:
  r2 -e io.cache=true -e scr.color=false -q -c 'pI $s' "$BINARY_"
• It seems the code for checking is always the same, independent of the arch with only exception COUNT_MMAP_OK. Would it make sense to just do one function and just set the MMAP according to arch?
• It seems this is overall running very slow as many commands are executed, although I did not find a concrete spot, I think there is room for improvement
• I also did see, that the radare2 should be skipped if already tested by objdump. This has never worked for me, as I run it multithreaded and both checks run in parallel. Any idea about this?

[m-1-k-3]

Hi @jblu42,

thank you for your effort. I will try to answer your questions:

• -e io.cache=true -e scr.color=false -q -c 'pI $ss'

looks like this is a typo. Could you fix this in your upcoming PR

• It seems the code for checking is always the same, independent of the arch with only exception COUNT_MMAP_OK. Would it make sense to just do one function and just set the MMAP according to arch?

There are some little differences:

PPC32:
r2 -e io.cache=true -e scr.color=false -q -c 'pI $s' "$BINARY_" | grep -E -A 2 -B 20 "bl.*$FUNCTION"
vs MIPS:
r2 -e io.cache=true -e scr.color=false -q -c 'pI $ss' "$BINARY_" | grep -A 20 -B 25 "^l[wd] .*$FUNCTION""(gp)"

• looks as we are missing -E here
• -A 20 could be changed to -A 2
• as we have seen in your first question we can change $ss to $s

vs x86:
r2 -e io.cache=true -e scr.color=false -q -c 'pI $s' "$BINARY_" | grep -E -A 2 -B 20 "call.*$FUNCTION"

But as far as I can see it looks like as we are able to create a function for populating the NETWORKING variable.
The mmap handling at all is nearly not implemented. It was an idea a while ago but never gets finished.

• It seems this is overall running very slow as many commands are executed, although I did not find a concrete spot, I think there is room for improvement

The r2 command is much slower compared to objdump. This is the reason we are primarly using objdump and just in case objdump is not able to handle a binary we bring r2 in place.

• I also did see, that the radare2 should be skipped if already tested by objdump. This has never worked for me, as I run it multithreaded and both checks run in parallel. Any idea about this?

This

emba/modules/S14_weak_func_radare_check.sh

Line 35 in 74fdf92

if [[ -f "$MAIN_LOG" ]]; then

and this

emba/modules/S14_weak_func_radare_check.sh

Line 43 in 74fdf92

if [[ -f "$MAIN_LOG" ]]; then

should ensure that module s12 and s13 should run before s14. Proably the || true causes issues. If something happens to the grep command it results in zero and passes this loop. As far as I can see we have solved this a bit different in other modules like the s116:

emba/modules/S116_qemu_version_detection.sh

Line 29 in 74fdf92

while [[ $(grep -c "S115_usermode_emulator finished" "$LOG_DIR"/"$MAIN_LOG_FILE" || true) -ne 1 ]]; do

To do this in a consistent way I will create helper function to handle this always the same way.

[github-actions]

This issue is stale because it has been open for 28 days with no activity.

[m-1-k-3]

While reading an article for a different topic I have seen that Qemu supports this architecture with the qemu-hexagon(-static) user mode emulator. Probably we can easily integrate support for this :)