search

radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.29k stars 2.97k forks source link

Load tricore .hex files. #15215

Open ghost opened 4 years ago

ghost commented 4 years ago

Environment information

Describe the bug

Tricore files do not seem to be loaded correctly. I have a tricore .hex file that I open using the ihex:// input. Then, in cutter, it displays only "FF", it does not find any functions, and it even does not find strings. I tried converting the .hex file to a binary file using s_record before, which resulted in a multi-GB file. However, this file also exhibited the same behavior (but "00"s instead of "FF").

To Reproduce Steps to reproduce the behavior:

  1. Get some hexfile, I finally found a public one: http://git.edi.lv/vitalijs.fescenko/Erika_OS_Aurix_TC29x_port/raw/5517d045a617cde6fa17eb19d6ac2e7045474aba/Port_To_TC297_Guide/Tricore_TC297B_Multicore/Debug/tc27x_multicore.hex

  2. load it into cutter using ihex:// and select tricore architecture

  3. wait (or disable auto-analysis and wait less)

karliss commented 4 years ago

There were some recent ihex fixes in r2. I think those happened right after 1.9 release see the issue referenced in radareorg/cutter#1745 . Without those it will read almost correct data making you very confused.

A build from latest master will still show you a bunch of 0xff at the start of file, but that's because the file you linked doesn't map anything at 0x00000000. The interesting part is at 0x80000000 and 0x80020000 . I am guessing that long analysis and lack of functions is due to r2 being silly and searching for code in the big empty regions. It probably needs some hints about regions which need to be analyzed.

XVilka commented 4 years ago

It probably should create corresponding maps when loading ihex files

On Tue, Sep 24, 2019, 3:01 AM karliss notifications@github.com wrote:

There were some recent ihex fixes in r2. I think those happened right after 1.9 release see the issue referenced in radareorg/cutter#1745 https://github.com/radareorg/cutter/issues/1745 . Without those it will read almost correct data making you very confused.

A build from latest master will still show you a bunch of 0xff at the start of file, but that's because the file you linked doesn't map anything at 0x00000000. The interesting part is at 0x80000000 and 0x80020000 . I am guessing that long analysis and lack of functions is due to r2 being silly and searching for code in the big empty regions. It probably needs some hints about regions which need to be analyzed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/radareorg/cutter/issues/1785?email_source=notifications&email_token=AABRT7KVXYNJZT4LK57WAHTQLEHA7A5CNFSM4IZKPGL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7L5HDQ#issuecomment-534238094, or mute the thread https://github.com/notifications/unsubscribe-auth/AABRT7KJLP6VMNHMKSKJZ4TQLEHA7ANCNFSM4IZKPGLQ .