radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset

Home Page:https://www.radare.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Piped input in Windows fails on first 1A byte (EOF) for Rasm2.

travisgoodspeed opened this issue · comments

When reading a file from standard input on Windows, rasm2 mistakenly treats the first 1A byte as the end of input. This is inconvenient when trying to pipe binaries into the executable for disassembly without first making a temporary file.

Also, this tool is great and I miss R2Con.

Environment

Latest binary Radare2 release on Windows 11.

2024-07-04
C:\tmp>r2 -v
radare2 5.9.2 1 @ windows-x86-64
birth: git.5.9.2 Mon 05/20/2024__23:16:31.82
commit: aea5c93a8f5a6ed360ea21d6a4e36f00accb8b7d
options: gpl -O? cs:5 cl:1 meson

Description

With a parameter or filename of -, rasm2 supports reading from standard input. This is useful when calling out to the disassembler, as tools can pass code to it through a pipe rather than make (and destroy) a temporary file. On Unix, this works as expected.

In Windows, the byte 1A is interpreted as an end-of-file (EOF) marker by rasm2. This means that the tool will exit a disassembly early on the first instance of 1A.

Here is a concrete example from MaskRomTool, in which a GameBoy's ROM disassembly ends early on the first 1A byte. This bug does not present on Unix.

image

Test

From an 8-byte file containing 31feff1a twice, we see that reading the file by name provides the proper 8-byte disassembly. Reading the same file piped through stdin gives only the first three bytes, and everything thereafter is lost.

C:\tmp>REM This will work because we use a filename.

C:\tmp>rasm2 -DAB -a gb -f smallrom.bin
0x00000000   3                   31feff  ld sp, 0xfffe
0x00000003   1                       1a  ld a, [de]
0x00000004   3                   31feff  ld sp, 0xfffe
0x00000007   1                       1a  ld a, [de]

C:\tmp>REM This will fail because we pipe through standard input.

C:\tmp>rasm2 -DAB -a gb -  <smallrom.bin
0x00000000   3                   31feff  ld sp, 0xfffe

MAME's Unidasm does not have this same problem. It correctly interprets 1A as a byte and disassembles the whole file.

C:\tmp>unidasm -arch lr35902 - < smallrom.bin
0: 31 fe ff  ld   sp,$FFFE
3: 1a        ld   a,(de)
4: 31 fe ff  ld   sp,$FFFE
7: 1a        ld   a,(de)

Should be fixed in #23094 i didnt tested but the bug was clear to me after reading the unix-centric implementation of that function. Thanks for reporting and happy to help!

PD: hope to rearrange enough motivation to organize the r2con again anytime soon ^^