functions broken when analyzing file opened with ihex://

[haystack-ia]

This template is meant for bug reports, if you have a feature request, please be as descriptive as possible and delete the template

Make sure you are testing using the latest git version of radare2 before submitting any issue.

If you would like to report a bug, please fill the template below

Work environment

Questions	Answers
OS/arch/bits (mandatory)	Mac OS 10.14.5 x86_64
File format of the file you reverse (mandatory)	intel hexdump of firmware blob
Architecture/bits of the file (mandatory)	ARM Cortex-M3
r2 -v full output, not truncated (mandatory)	radare2 3.7.0-git 22245 @ darwin-x86-64 git.3.6.0-14-g4a1392932
commit: 4a13929 build: 2019-06-27__13:02:04

Expected behavior

When I load ihex file (attached) via r2 ihex://example.hex, p=e should show the entropy of various blocks. p=i should show number of invalid commands per block. Dumping the contents of the hex file into binary (via s 0x8000000;wtf! example.bin) should produce a valid binary file that matches the contents of the .hex.

Actual behavior

I converted example.hex into binary using the 010 hex editor and p=i and p=e commands' output does not match output when ran on the hex file opened w/ ihex.

When attempting to dump contents of ihex as binary (via s 0x8000000;wtf! example.bin as above), it wrote the first 0x100 bytes over and over rather than reproducing the contents of the hex file.

Steps to reproduce the behavior

Hex file is here: hex_file.zip

Load into r2 and run p=e, p=i (with various archs), wtf! thing.bin @ 0x8000000 to see what I mean.

[radare]

dupe of #8512 i think

…

On 27 Jun 2019, at 20:23, haystack-ia ***@***.***> wrote: This template is meant for bug reports, if you have a feature request, please be as descriptive as possible and delete the template Make sure you are testing using the latest git version of radare2 before submitting any issue. If you would like to report a bug, please fill the template below Work environment Questions Answers OS/arch/bits (mandatory) Mac OS 10.14.5 x86_64 File format of the file you reverse (mandatory) intel hexdump of firmware blob Architecture/bits of the file (mandatory) ARM Cortex-M3 r2 -v full output, not truncated (mandatory) radare2 3.7.0-git 22245 @ darwin-x86-64 git.3.6.0-14-g4a1392932 commit: 4a13929 <4a13929> build: 2019-06-27__13:02:04 Expected behavior When I load ihex file (attached) via r2 ihex://example.hex, p=e should show the entropy of various blocks. p=i should show number of invalid commands per block. Dumping the contents of the hex file into binary (via s 0x8000000;wtf! example.bin) should produce a valid binary file that matches the contents of the .hex. Actual behavior I converted example.hex into binary using the 010 hex editor and p=i and p=e commands' output does not match output when ran on the hex file opened w/ ihex. When attempting to dump contents of ihex as binary (via s 0x8000000;wtf! example.bin as above), it wrote the first 0x100 bytes over and over rather than reproducing the contents of the hex file. Steps to reproduce the behavior Hex file is here: hex_file.zip <https://github.com/radare/radare2/files/3336115/hex_file.zip> Load into r2 and run p=e, p=i (with various archs), wtf! from 0x8000000 (wtf! example.bin @ 0x8000000 doesn't seem to work either, which is strange) to see what I mean. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14439>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG75FWRY6QVRW3I4PGHTRDP4UAR7ANCNFSM4H367D2Q>.

[haystack-ia]

I don't think so. If I'm reading it right, the issues w/ #8512 stem from io.0xff settings, which only affects addresses that the .hex file doesn't define. The issue I'm running into concerns areas that the .hex file does define.

Definitely with the wtf! thing.bin @ 0x8000000 command I mentioned, the issue isn't that undefined areas are filled in with 0xff instead of 0. The issue is that it writes the same block (0x8000000->0x8000100) over and over.