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

r2: expending a file don't seem to work as expected #23475

Open
afiskon opened this issue Oct 14, 2024 · 3 comments
Open

r2: expending a file don't seem to work as expected #23475

afiskon opened this issue Oct 14, 2024 · 3 comments

Comments

@afiskon
Copy link

afiskon commented Oct 14, 2024

Environment

eax@z930:~$ date
Mon Oct 14 15:00:03 MSK 2024

eax@z930:~$ r2 -v
radare2 5.9.7 32724 @ linux-x86-64
birth: git.5.9.6-5-g1cbab0f485 2024-10-14__14:39:51
commit: 1cbab0f48541e30a975154e953fb2fc9852263bb
options: gpl -O? cs:5 cl:2 make

eax@z930:~$ uname -ms
Linux x86_64

Description

I'm using r2 as a simple hex editor. While doing so I noticed that expending a binary file with r and checking the result with px shows that the file size was not affected. The w command doesn't seem to be aware of the additionally allocated space too. If I quit with q and open the same file again I see that the size was changed correctly. Truncating the file with r seems to work properly.

Test

echo aaa > test.bin

r2 -w test.bin

[0x00000000]> px 010
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  6161 610a ffff ffff                      aaa.....
[0x00000000]> px 0x10
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  6161 610a ffff ffff ffff ffff ffff ffff  aaa.............
[0x00000000]> r 0x10
[0x00000000]> r
16
[0x00000000]> px 0x10
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  6161 610a ffff ffff ffff ffff ffff ffff  aaa.............
[0x00000000]> wx 11 22 33 44 55
[0x00000000]> px 0x10
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  1122 3344 ffff ffff ffff ffff ffff ffff  ."3D............
[0x00000000]> q

r2 -w test.bin

[0x00000000]> px 0x10
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  1122 3344 0000 0000 0000 0000 0000 0000  ."3D............
@afiskon
Copy link
Author

afiskon commented Oct 14, 2024

wen command has the same problem

@trufae
Copy link
Collaborator

trufae commented Oct 14, 2024

Resizing the underlying fd doesnt imply syncing it up with the map. Those are different io layers, you can disable io.va with the e command or use omr manually. And i think omfg also updated map sizes not just perms but im just answering from memory. Maybe @condret knows more ways to achieve the same

@condret
Copy link
Member

condret commented Oct 27, 2024

There exists a feature called map tying in r_io, for specifying if and how map and file resizing should or should not affect each other. play around with the omt commands. Let me know if you want more options here
ksnip_20241027-194100

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

No branches or pull requests

3 participants