Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strings do not appear to be properly handled in IDA #1

Closed
mspublic opened this issue Jul 8, 2016 · 5 comments
Closed

Strings do not appear to be properly handled in IDA #1

mspublic opened this issue Jul 8, 2016 · 5 comments
Labels

Comments

@mspublic
Copy link

mspublic commented Jul 8, 2016

When loading an elf that has strings - such as the QSR_STRING section. The ASCII strings are not properly detected - and do not appear to show up as ASCII when trying to select as string. Not sure the cause...

@mspublic mspublic changed the title Strings do not appear to be properly handled. Strings do not appear to be properly handled in IDA Jul 8, 2016
@schomatis
Copy link

Hi @mspublic, thank you for the feedback, you're right, this is currently a limitation in the IDA proc. module.

The strings in the binary, shown in the Strings windows in IDA (Shift + F12), in order to be recognized as string objects in the IDA View (e.g., .rodata:0000D462 aArithmeticErro:db "arithmetic error" in the factorial_example.elf provided in this repo), a data reference has to be made to it (by the proc. module).

The data reference feature was disabled because it was not working correctly (we're working on it), it causes IDA to sometimes try to disassemble unaligned addresses (probably due to a logic error in the proc. module) which resulted in much longer analysis times by IDA.

I've now enabled it with the use of an environment variable: IDP_ENABLE_DATA_REFS (which should be set before starting IDA). You may try it to see if it suits your needs and doesn't increase the analysis time too much.

Also, I've removed a proc. module option (XlatAsciiOutput) which might have been causing IDA to distort the ascii strings in the binary.

If you have a particular binary that you can share I'll be glad to take a look at it.

@schomatis schomatis added the bug label Jul 9, 2016
@mspublic
Copy link
Author

mspublic commented Jul 9, 2016

Sure - if you download the "Hexagon SDK v2.0" (2.0 is important) from https://developer.qualcomm.com/software/hexagon-dsp-sdk/tools

You will find some .elf files in there - thats what I was testing one.

Im testing to new version now - will let you know how it goes.

@schomatis
Copy link

Great, the factorial_example.elf binary (in which I was testing the previous 2 commits) was an example built from that SDK, so the data references will probably work for you too.

@mspublic
Copy link
Author

mspublic commented Jul 9, 2016

Just tested the new version. Much better in regards to strings! Standard sting references are now picked up just fine. As for performance - during initial loading of the IDB I don't tend to pay too much attention as it takes a while either way.

I am using M8974AAAAAAAAQ1234.elf from the SDK.

The only side note - the QString references would probably be a nice feature to add - its a reference to a struct/array that references the string.

@schomatis
Copy link

Good to know. Thanks again for the feedback.

I'm closing this issue, the more general data references issue will be handled separately in #2. Feel free to open a new issue to discuss QString reference support, I'm gonna need more context (I'm not familiar with QStrings) to asses how hard it would be to implement that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants