File write does not work in windows

[f4grx]

using packaged radare2 0.9.6 in win7

radare2 myfile.exe works

radare -w myfile.exe says:

PRIV ENABLED
CreateFile: Le processus ne peut pas accÚder au fichier car ce fichier est utilisÚ par un autre processus.

CreateFile: Le processus ne peut pas accÚder au fichier car ce fichier est utilisÚ par un autre processus.

CreateFile: Le processus ne peut pas accÚder au fichier car ce fichier est utilisÚ par un autre processus.

CreateFile: Le processus ne peut pas accÚder au fichier car ce fichier est utilisÚ par un autre processus.

PRIV ENABLED
 -- Sniff your favorite libusb-based application with LD_PRELOAD=/usr/lib/libusbsniff.so ./your-program
[0x00000000]>

The message is: the process cannot access the file because it is used by another process.

using radare2 -w win32://file

PRIV ENABLED
PRIV ENABLED
 -- Set e bin.dwarf=true to load dwarf information at startup
[0x00000000]>

No messages, but it does not work either.

I suspect that in https://github.com/radare/radare2/blob/master/libr/io/p/io_w32.c , around line 50 in function w32__open, FILE_SHARE_WRITE is probably not really working, nor useful, when opening in write mode. I cannot recompile easily right now, but would be happy to try an updated binary.

[f4grx]

I know, it's really radare2 -w w32://file.exe, not win32://file.exe

[condret]

update your r2 version. use it from git and tell us if the bug still occurs

[radare]

Works for me in GIT, i get some PRIV ENABLED and sharing violation warnings, but the write works fine

[XVilka]

@f4grx try this version http://bin.rada.re/radare2-w32-0.9.8.git.zip

[f4grx]

Note: --enable-w32 and --disable-gui, as specified in http://maijin.github.io/radare2book/introduction/windows_compilation.html , do not exist, and should be --with-windows --without-pic (which does not seem to work btw since a lot of files are still built with -fPIC)

it started well, but failed building this (list is not complete):

u:\perso\radare2\shlr\sdb\src-native/sdb.c:576: undefined reference to `sdb_now'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:576: undefined reference to `sdb_now'
sdb.o: In function `sdb_set_owned':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:368: undefined reference to `ht_delete_entry'
sdb.o: In function `sdb_hook_call':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to `sdb_now'
sdb.o: In function `sdb_set_owned':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to `sdb_now'
sdb.o: In function `sdb_exists':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:282: undefined reference to `sdb_hash'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:283: undefined reference to `ht_lookup'
sdb.o: In function `sdb_set_internal':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:339: undefined reference to `sdb_check_key'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:342: undefined reference to `sdb_check_value'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:346: undefined reference to `sdb_hash'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:347: undefined reference to `cdb_findstart'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:348: undefined reference to `ht_search'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:350: undefined reference to `cdb_findnext'
sdb.o: In function `sdb_exists':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:287: undefined reference to `cdb_findstart'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:288: undefined reference to `cdb_findnext'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:290: undefined reference to `cdb_read'
sdb.o: In function `sdb_set_internal':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:385: undefined reference to `ht_insert'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:368: undefined reference to `ht_delete_entry'
sdb.o: In function `sdb_hook_call':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to `sdb_now'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to `sdb_now'
sdb.o: In function `sdb_hook_free':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:679: undefined reference to `ls_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:679: undefined reference to `ls_free'
sdb.o: In function `sdb_fini':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:110: undefined reference to `cdb_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:113: undefined reference to `sdb_ns_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:117: undefined reference to `ls_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:118: undefined reference to `ht_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to `sdb_lock_file'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to `sdb_unlock'
sdb.o: In function `sdb_hook_free':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:679: undefined reference to `ls_free'
sdb.o: In function `sdb_fini':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:110: undefined reference to `cdb_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:113: undefined reference to `sdb_ns_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:117: undefined reference to `ls_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:118: undefined reference to `ht_free'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to `sdb_lock_file'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to `sdb_unlock'
sdb.o: In function `sdb_dump_dupnext':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:529: undefined reference to `cdb_getkvlen'
sdb.o: In function `sdb_foreach':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:408: undefined reference to `sdb_hash'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:409: undefined reference to `ht_search'
sdb.o: In function `unset_cb':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:718: undefined reference to `sdb_match'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:718: undefined reference to `sdb_match'
u:\perso\radare2\shlr\sdb\src-native/sdb.c:718: undefined reference to `sdb_match'
sdb.o: In function `sdb_file':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:104: undefined reference to `sdb_lock'
sdb.o: In function `sdb_unlink':
u:\perso\radare2\shlr\sdb\src-native/sdb.c:701: undefined reference to `sdb_disk_unlink'
u:/tdm-gcc-32/bin/../lib/gcc/mingw32/4.8.1/../../../libmingw32.a(main.o):main.c:
(.text.startup+0xa7): undefined reference to `WinMain@16'
collect2.exe: error: ld returned 1 exit status
<builtin>: recipe for target 'sdb' failed
mingw32-make[5]: *** [sdb] Error 1
mingw32-make[5]: Leaving directory 'u:/perso/radare2/shlr/sdb/src-native'
Makefile:42: recipe for target '../../../libr/../shlr/sdb/sdb' failed
mingw32-make[4]: *** [../../../libr/../shlr/sdb/sdb] Error 2
mingw32-make[4]: Leaving directory 'u:/perso/radare2/libr/syscall/d'
Makefile:17: recipe for target 'do' failed
mingw32-make[3]: *** [do] Error 2
mingw32-make[3]: Leaving directory 'u:/perso/radare2/libr/syscall'
Makefile:61: recipe for target 'syscall' failed
mingw32-make[2]: *** [syscall] Error 2
mingw32-make[2]: Leaving directory 'u:/perso/radare2/libr'
Makefile:26: recipe for target 'all' failed
mingw32-make[1]: *** [all] Error 2
mingw32-make[1]: Leaving directory 'u:/perso/radare2/libr'
Makefile:28: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
user@host /u/perso/radare2 (master)

[XVilka]

@f4grx try just run:

./configure
make
make w32dist

from the mingw32 console - it should work

[f4grx]

It obviously need a configure command :) And failed as before, since nothing changed.

BTW, which version did you want me to try? You did not include any link. I'm using git head.

[XVilka]

@f4grx sorry, forgot to paste link http://bin.rada.re/radare2-w32-0.9.8.git.zip

[XVilka]

And can you please give me the full configure + make log

[radare]

if you are on linux and want to crosscompile to windows just use sys/mingw32.sh

[radare]

oh wait, that looks like a cygwin shell, not a mingw32 one. I didnt tested on cygwin recently. xvilka did iirc

On 09/05/2014 02:22 PM, f4grx wrote:

Note: --enable-w32 and --disable-gui, as specified in http://maijin.github.io/radare2book/introduction/windows_compilation.html , do not exist, and should be --with-windows --without-pic (which does not seem to work btw since a lot of files are still built with -fPIC)

it started well, but failed building this (list is not complete):

u:\perso\radare2\shlr\sdb\src-native/sdb.c:576: undefined reference to |sdb_now' u:\perso\radare2\shlr\sdb\src-native/sdb.c:576: undefined reference to|sdb_now' sdb.o: In function |sdb_set_owned': u:\perso\radare2\shlr\sdb\src-native/sdb.c:368: undefined reference to|ht_delete_entry' sdb.o: In function |sdb_hook_call': u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to|sdb_now' sdb.o: In function |sdb_set_owned': u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to|sdb_now' sdb.o: In function |sdb_exists': u:\perso\radare2\shlr\sdb\src-native/sdb.c:282: undefined reference to|sdb_hash' u:\perso\radare2\shlr\sdb\src-native/sdb.c:283: undefined reference to |ht_lookup' sdb.o: In function|sdb_set_internal': u:\perso\radare2\shlr\sdb\src-native/sdb.c:339: undefined reference to |sdb_check_key' u:\perso\radare2\shlr\sdb\src-native/sdb.c:342: undefined reference to|sdb_check_value' u:\perso\radare2\shlr\sdb\src-native/sdb.c:346: undefined reference to |sdb_hash' u:\perso\radare2\shlr\sdb\src-native/sdb.c:347: undefined reference to|cdb_findstart' u:\perso\radare2\shlr\sdb\src-native/sdb.c:348: undefined reference to |ht_search' u:\perso\radare2\shlr\sdb\src-native/sdb.c:350: undefined reference to|cdb_findnext' sdb.o: In function |sdb_exists': u:\perso\radare2\shlr\sdb\src-native/sdb.c:287: undefined reference to|cdb_findstart' u:\perso\radare2\shlr\sdb\src-native/sdb.c:288: undefined reference to |cdb_findnext' u:\perso\radare2\shlr\sdb\src-native/sdb.c:290: undefined reference to|cdb_read' sdb.o: In function |sdb_set_internal': u:\perso\radare2\shlr\sdb\src-native/sdb.c:385: undefined reference to|ht_insert' u:\perso\radare2\shlr\sdb\src-native/sdb.c:368: undefined reference to |ht_delete_entry' sdb.o: In function|sdb_hook_call': u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to |sdb_now' u:\perso\radare2\shlr\sdb\src-native/sdb.c:667: undefined reference to|sdb_now' sdb.o: In function |sdb_hook_free': u:\perso\radare2\shlr\sdb\src-native/sdb.c:679: undefined reference to|ls_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:679: undefined reference to |ls_free' sdb.o: In function|sdb_fini': u:\perso\radare2\shlr\sdb\src-native/sdb.c:110: undefined reference to |cdb_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:113: undefined reference to|sdb_ns_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:117: undefined reference to |ls_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:118: undefined reference to|ht_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to |sdb_lock_file' u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to|sdb_unlock' sdb.o: In function |sdb_hook_free': u:\perso\radare2\shlr\sdb\src-native/sdb.c:679: undefined reference to|ls_free' sdb.o: In function |sdb_fini': u:\perso\radare2\shlr\sdb\src-native/sdb.c:110: undefined reference to|cdb_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:113: undefined reference to |sdb_ns_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:117: undefined reference to|ls_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:118: undefined reference to |ht_free' u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to|sdb_lock_file' u:\perso\radare2\shlr\sdb\src-native/sdb.c:112: undefined reference to |sdb_unlock' sdb.o: In function|sdb_dump_dupnext': u:\perso\radare2\shlr\sdb\src-native/sdb.c:529: undefined reference to |cdb_getkvlen' sdb.o: In function|sdb_foreach': u:\perso\radare2\shlr\sdb\src-native/sdb.c:408: undefined reference to |sdb_hash' u:\perso\radare2\shlr\sdb\src-native/sdb.c:409: undefined reference to|ht_search' sdb.o: In function |unset_cb': u:\perso\radare2\shlr\sdb\src-native/sdb.c:718: undefined reference to|sdb_match' u:\perso\radare2\shlr\sdb\src-native/sdb.c:718: undefined reference to |sdb_match' u:\perso\radare2\shlr\sdb\src-native/sdb.c:718: undefined reference to|sdb_match' sdb.o: In function |sdb_file': u:\perso\radare2\shlr\sdb\src-native/sdb.c:104: undefined reference to|sdb_lock' sdb.o: In function |sdb_unlink': u:\perso\radare2\shlr\sdb\src-native/sdb.c:701: undefined reference to|sdb_disk_unlink' u:/tdm-gcc-32/bin/../lib/gcc/mingw32/4.8.1/../../../libmingw32.a(main.o):main.c: (.text.startup+0xa7): undefined reference to `WinMain@16' collect2.exe: error: ld returned 1 exit status : recipe for target 'sdb' failed mingw32-make[5]: * [sdb] Error 1 mingw32-make[5]: Leaving directory 'u:/perso/radare2/shlr/sdb/src-native' Makefile:42: recipe for target '../../../libr/../shlr/sdb/sdb' failed mingw32-make[4]: * [../../../libr/../shlr/sdb/sdb] Error 2 mingw32-make[4]: Leaving directory 'u:/perso/radare2/libr/syscall/d' Makefile:17: recipe for target 'do' failed mingw32-make[3]: * [do] Error 2 mingw32-make[3]: Leaving directory 'u:/perso/radare2/libr/syscall' Makefile:61: recipe for target 'syscall' failed mingw32-make[2]: * [syscall] Error 2 mingw32-make[2]: Leaving directory 'u:/perso/radare2/libr' Makefile:26: recipe for target 'all' failed mingw32-make[1]: * [all] Error 2 mingw32-make[1]: Leaving directory 'u:/perso/radare2/libr' Makefile:28: recipe for target 'all' failed mingw32-make: * [all] Error 2 user@host /u/perso/radare2 (master) $

— Reply to this email directly or view it on GitHub https://github.com/radare/radare2/issues/1292#issuecomment-54618102.

[XVilka]

@f4grx and please, run 'git clean -xdf' before configure, to remove old object files

[f4grx]

yep, I'm not using cygwin but msys. I'm in windows 7. It worked after a clean git clone. No idea why... each of my earlier attempts was also done after a clean git clone!

[f4grx]

hmm build is ok, but not execution.

U:\radare2\radare2-w32-0.9.8.git>radare2.exe -version
PRIV ENABLED
radare2 0.9.8.git @ windows-little-x86-32 git.0.9.8-rc3-561-g68e78ae
commit: 68e78aef7c843f8867c25d2197c30c7467128bbc build: 2014-09-05

U:\radare2\radare2-w32-0.9.8.git>radare2 C:\folder\target.exe
PRIV ENABLED
 -- I love gradients.
[0x00701da0]> pd
            ;-- entry0:
            <some disassembly, as expected>
[0x00701da0]> q

U:\radare2\radare2-w32-0.9.8.git>radare2 -w C:\folder\target.exe
PRIV ENABLED
CreateFile: Le processus ne peut pas accÚder au fichier car ce fichier est utilisÚ par un autre processus.

 -- I script in C, because fuck you.
[0x00000000]> q

I'm going to mess around with the code.

[Maijin]

@f4grx \o/ Electrolab people are using Radare2, you should join #radare @ freenode ;-)

[f4grx]

Oh, nice! But today they were using hammers, paintbrushes and screwdrivers :)

I will join!

Sebastien

Le 2014-09-06 18:49, Maijin a écrit :

@f4grx [1] o/ Electrolab people are using Radare2, you should join #radare @ freenode ;-)

Reply to this email directly or view it on GitHub [2].

Links:

[1] https://github.com/f4grx [2] https://github.com/radare/radare2/issues/1292#issuecomment-54720249

[radare]

any update on the issue?

[f4grx]

sorry, not yet!

[XVilka]

xvilka ~/radare/radare2/radare2-w32-0.9.8.git
$ ./radare2.exe -w rarun2.exe
PRIV ENABLED
Unable to open file: rarun2.exe
r_io_create: Permission denied.
Cannot open 'rarun2.exe' for writing.

[XVilka]

Ok, got error, when running Mingw32 compiled radare2 from mingw32 shell:

$ ./radare2.exe -w rarun2.exe
PRIV ENABLED
CreateFile: ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє, Єръ ъръ ¤ЄюЄ Їрщы чрэ Є фЁєушь яЁюЎхёёюь.

 -- Please register your copy of r2 today! Only ┬г29.90!
[0x00000000]>

[radare]

Which language is this?

On 13 Sep 2014, at 15:41, Anton Kochkov notifications@github.com wrote:

Ok, got error, when running Mingw32 compiled radare2 from mingw32 shell:

$ ./radare2.exe -w rarun2.exe PRIV ENABLED CreateFile: ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє, Єръ ъръ ¤ЄюЄ Їрщы чрэ Є фЁєушь яЁюЎхёёюь.

-- Please register your copy of r2 today! Only ┬г29.90! [0x00000000]> — Reply to this email directly or view it on GitHub.

[XVilka]

That's Bokken Russian dialect

[radare]

What does it mean in english?

On 13 Sep 2014, at 16:53, Anton Kochkov notifications@github.com wrote:

That's Bokken Russian dialect

— Reply to this email directly or view it on GitHub.

[deeso]

All you are base belong to radare?

[f4grx]

Okay first thing first, I now understand that radare2 builds ok in msys, but fails to do so in MsysGit...

[f4grx]

Now I opened the file in RW mode without error.

[XVilka]

@f4grx what error you have in MsysGit?

[f4grx]

the same as in my previous comment:

collect2.exe: error: ld returned 1 exit status

: recipe for target 'sdb' failed mingw32-make[5]: **\* [sdb] Error 1 mingw32-make[5]: Leaving directory 'u:/perso/radare2/shlr/sdb/src-native' Makefile:42: recipe for target '../../../libr/../shlr/sdb/sdb' failed mingw32-make[4]: **\* [../../../libr/../shlr/sdb/sdb] Error 2 mingw32-make[4]: Leaving directory 'u:/perso/radare2/libr/syscall/d' Makefile:17: recipe for target 'do' failed mingw32-make[3]: **\* [do] Error 2 mingw32-make[3]: Leaving directory 'u:/perso/radare2/libr/syscall' Makefile:61: recipe for target 'syscall' failed mingw32-make[2]: **\* [syscall] Error 2 mingw32-make[2]: Leaving directory 'u:/perso/radare2/libr' Makefile:26: recipe for target 'all' failed mingw32-make[1]: **\* [all] Error 2 mingw32-make[1]: Leaving directory 'u:/perso/radare2/libr' Makefile:28: recipe for target 'all' failed mingw32-make: **\* [all] Error 2 user@host /u/perso/radare2 (master) but msysgit is just a way to compile git, I don't think we should expect that to work as a build environment for random software. I guess it's because this env uses mingw32-make and tdm-gcc in my setup, while msys uses a make and another toolchain. There may be some subtle incompatibility here.

[f4grx]

The real issue is that wx and wa do not work. px still shows the same bytes. Do I need a command to sync the radare view with the disk?

[radare]

it was working in the test i did.. but maybe i didnt fixed all cases.

the ‘w’ works, but the problem should be only in ‘syncing’ the changes into the view. that requires fixing the perms.

also ive noticed that the debugger on w32 has been broken recently. i’ll try to bisect for the offending commit, but it will be probably more productive to just fix it. That will be done for the release.

On 15 Sep 2014, at 18:04, f4grx notifications@github.com wrote:

The real issue is that wx and wa do not work. px still shows the same bytes. Do I need a command to sync the radare view with the disk?

— Reply to this email directly or view it on GitHub.

[f4grx]

It seems that any file loading operation now fails. Entry point is zero and reading only shows zero bytes

$ radare2.exe -version radare2 0.9.8.git @ windows-little-x86-32 git.0.9.8-rc3-720-geffa16c commit: effa16c871d9532d2c4a85af8848d32a11f78f54 build: 2014-09-17

[f4grx]

and if I explicitly prefix my path with w32:// I get:

$ radare2.exe -w w32://D:/path/target.exe WARNING: bin_strings buffer is too big at 0x00000000

[0x00000000]> which I don't get when running: $ radare2.exe -w D:/path/target.exe [0x00000000]> I get the same without -w

[radare]

what happens if you open the file directly from the same directory like this:

radare2.exe -w target.exe

maybe its a problem with DOS paths

On 17 Sep 2014, at 11:25, f4grx notifications@github.com wrote:

and if I explicitly prefix my path with w32:// I get:

$ radare2.exe -w w32://D:/path/target.exe WARNING: bin_strings buffer is too big at 0x00000000

[0x00000000]>

which I don't get when running:

$ radare2.exe -w D:/path/target.exe

[0x00000000]>

I get the same without -w

— Reply to this email directly or view it on GitHub.

[f4grx]

Will do that.

Meanwhile, tracing in GDB after putting a breakpoint in w3__open all calls seem to be ok except:

main (argc=3, argv=0x573970, envp=0x571de0) at radare2.c:493 493 if (run_anal>0) { (gdb) s 495 if (!rabin_th) (gdb) s 498 const char *filepath = NULL; (gdb) s 499 if (debug) { (gdb) n 505 if (r.file && r.file->desc && r.file->desc->name ) (gdb) n 506 filepath = r.file->desc->name; (gdb) n 508 if (!r_core_bin_load (&r, filepath, baddr)) (gdb) n WARNING: bin_strings buffer is too big at 0x00000000 518 if (!quiet && r_cons_is_utf8 ()) { (gdb)

[f4grx]

target in the same directory: does not change anything. Paths are okay, since giving a wrong path results in failure to open the file. I believe the raw file is read ok but there is a parsing problem.

Does it help if I send you the compilation result and the target? Not here of course.

[f4grx]

Can anyone else try to reproduce the issue, so I'm convinced this is not entirely a pebkac issue? :/

[radare]

Iirc defragger was able to reproduce the same issue, he'll probably look into it when he have some time. He have fixed the debugger already. Also dso pointed out some related io lroblems in his refactorings, so thats a regression and will be fixed soon.

Sorry for the delay. We just need a windows maintainer/developer to priorize such bugs.

On 17 Sep 2014, at 11:46, f4grx notifications@github.com wrote:

Can anyone else try to reproduce the issue, so I'm convinced this is not entirely a pebkac issue? :/

— Reply to this email directly or view it on GitHub.

[f4grx]

Absolutely not a problem. I'm sorry I can't help you with the coding here. So I'll be patient and help you the best I can with reports. Please ask me to test, anytime.

[f4grx]

Testing this afternoon, I still get the "bin_strings buffer is too big at 0x00000000" when using a w32:// file URL, and no message at all (and no better effect) using a direct file path.

[f4grx]

Wait I noticed something totally different.

I had doubts about file validity, so I reacquired my target from a clean source. The clean source can be opened in write mode. disassembly works, etc. Then, I could patch the exe file. After this, the "bug" appeared.

also, before writing with radare2, objdump shows a valid PE executable headers, and after, the file format is not detected.

Using radiff2 I noticed that the intended change (with wx) had occurred at file offset zero! That's why I can't open the file again: it's not detected as a valid PE file.

So my question is: when using wx, is the offset specified by s taken into account, or do I have to specify a @ offset in all cases? Because it totally looks like wx does not write where it should! I just tested it, and @ 0xOffset does not seem to produce any additional effect.

weird...

[radare]

the @ char is used to perform temporal seeks, the write ops should be performed at the current seek (or where the visual cursor points to).

opening a unknown file type should work too. sorry im not a windows user and i m pretty busy maintaining ios, android, linux and osx. that’s why i cant priorize this task more.

thats a very anoying issue, mostly because its prety basic functionality. hopefully will have some free time this week to check it

On 22 Sep 2014, at 18:07, f4grx notifications@github.com wrote:

Wait I noticed something totally different.

I had doubts about file validity, so I reacquired my target from a clean source. The clean source can be opened in write mode. disassembly works, etc. Then, I could patch the exe file. After this, the "bug" appeared.

also, before writing with radare2, objdump shows a valid PE executable headers, and after, the file format is not detected.

Using radiff2 I noticed that the intended change (with wx) had occurred at file offset zero! That's why I can't open the file again: it's not detected as a valid PE file.

So my question is: when using wx, is the offset specified by s taken into account, or do I have to specify a @ offset in all cases? Because it totally looks like wx does not write where it should! I just tested it, and @ 0xOffset does not seem to produce any additional effect.

weird...

— Reply to this email directly or view it on GitHub.

[f4grx]

As I said, I'm ok with this delay, i'm just using this page as a log of my activities trying to understanding the issue. it may be useful later.

[f4grx]

OK, when I dont prefix with w32://, the io_default.c io plugin is used instead of io_w32.c

[f4grx]

I think I hold it

I put a breakpoint in r_io_write to see what happens when i run "wx" I was not disappointed!

After a long road I found that the function that does the writing job is r_file_mmap_write in util/file.c This function opens the file, then maps it into the address space through : ut8 *obuf = MapViewOfFile (fm, FILE_MAP_WRITE, 0, 0, len);

And then it memcpy the incoming buffer into obuf, then closes everything.

However, IIUC, obuf points to the first byte in the file. Any current offset defined via seeks is not used here. So any write will occur at file offset zero, which is what I observe.

Now, I have no idea how the current file offset should be passed to this routine. Is that the "addr" parameter? this one isnt used in the windows branch of this routine Then at line 385 of this file, memcpy (obuf+addr, buf, len); should fix the issue.

WHY the hell is this so complex ? a seek/write would do it since mingw has a posix api! But no, you prefer playing with hardcoded 4k page sizes and modulos in the unix branch of this routine!

I saw a rawio flag in the RIOMMapFileObj struct defined in io_default.c that should do that, but this flag is only set in r_io_def_mmap_refresh_def_mmap_buf (GG for the name!) if (r_file_size (mmo->filename)> ST32_MAX) { // Do not use mmap if the file is huge mmo->rawio = 1; } (I dont know how this could be called)

and again in r_io_def_mmap_create_new_file if (!r_io_def_mmap_refresh_def_mmap_buf (mmo)) { mmo->rawio = 1; (wtf! try again if called routine did not do it before?)

Seriously guys, I really can't understand what this whole code is doing. From a totally exterior point of view, this part of the code seems over engineered. Yeah, I know, it's easy to tell, and I'm the noob.

Really, in practice, I feel that there are only two different IO methods to access local files: -win32api for compilation with visual studio -posix for anything else than visual studio why do you even attempt to mmap() things?

Well, I hope the technical info in the beginning of this post was helpful.

[f4grx]

And FAIL, this "addr" param in r_file_mmap_write receives exactly zero, not the current file position, so my fix does nothing. Written data still lands at offset 0x00000000, so the problem started a few functions before. However a printf confirmed that this function is what really writes to the file, NOT any code in ANY IO plugin.

I'm going to use an hex editor. Recompiling takes 3 minutes 22 sec, even for a single line of code changed, I can't do that :(

[radare]

im away of that overengineering and it was caused by some refactorings that happened at the begining of the year. i have pushed a fix for this, simplifiying that function because we dont really need to use mmap to write in there. at least for 99% of cases.

let me know if its fine now for you. and sorry for the delay again O:) this issue was reproducible and easy to fix with wine.

On 22 Sep 2014, at 21:32, f4grx notifications@github.com wrote:

I think I hold it

I put a breakpoint in r_io_write to see what happens when i run "wx" I was not disappointed!

After a long road I found that the function that does the writing job is r_file_mmap_write in util/file.c This function opens the file, then maps it into the address space through : ut8 *obuf = MapViewOfFile (fm, FILE_MAP_WRITE, 0, 0, len);

And then it memcpy the incoming buffer into obuf, then closes everything.

However, IIUC, obuf points to the first byte in the file. Any current offset defined via seeks is not used here. So any write will occur at file offset zero, which is what I observe.

Now, I have no idea how the current file offset should be passed to this routine. Is that the "addr" parameter? this one isnt used in the windows branch of this routine Then at line 385 of this file, memcpy (obuf+addr, buf, len); should fix the issue.

WHY the hell is this so complex ? a seek/write would do it since mingw has a posix api! But no, you prefer playing with hardcoded 4k page sizes and modulos in the unix branch of this routine!

I saw a rawio flag in the RIOMMapFileObj struct defined in io_default.c that should do that, but this flag is only set in r_io_def_mmap_refresh_def_mmap_buf (GG for the name!) if (r_file_size (mmo->filename)> ST32_MAX) { // Do not use mmap if the file is huge mmo->rawio = 1; } (I dont know how this could be called)

and again in r_io_def_mmap_create_new_file if (!r_io_def_mmap_refresh_def_mmap_buf (mmo)) { mmo->rawio = 1; (wtf! try again if called routine did not do it before?)

Seriously guys, I really can't understand what this whole code is doing. From a totally exterior point of view, this part of the code seems over engineered. Yeah, I know, it's easy to tell, and I'm the noob.

Really, in practice, I feel that there are only two different IO methods to access local files: -win32api for compilation with visual studio -posix for anything else than visual studio why do you even attempt to mmap() things?

Well, I hope the technical info in the beginning of this post was helpful.

— Reply to this email directly or view it on GitHub.

[f4grx]

I pulled your changes and rebuilt.

Note: I just want to change that byte at offset 0x00b049c8 from 3 to 42.

Starting program: u:\perso\radare2\radare2-w32-0.9.8.git/radare2.exe -w U:/target.exe
[New Thread 4588.0x13f4]
[New Thread 4588.0x6e0]
 -- Set 'e bin.dwarf=true' to load dwarf information at startup.
[0x00701da0]> s 0xb049c8
[0x00b049c8]> px
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00b049c8  0300 0000 ffff ffff 0100 0000 0100 0000  ................
(...)
0x00b04ab8  0000 0000 0000 34c0 0000 0000 0000 0040  ......4........@
[0x00b049c8]> wx 2a

Program received signal SIGSEGV, Segmentation fault. 
0x7681deef in WriteFile () from C:\Windows\syswow64\KernelBase.dll
(gdb) bt
#0  0x7681deef in WriteFile () from C:\Windows\syswow64\KernelBase.dll
#1  0x0fc4229a in ?? ()
#2  0x00000000 in ?? ()

This backtrace seems pretty invalid. Is that a buffer overflow?

[f4grx]

Better with a breakpoint, now that I know the function :)

$ gdb --args radare2.exe -w U:/target.exe
GNU gdb (GDB) 7.6.1
Reading symbols from u:\perso\radare2\radare2-w32-0.9.8.git\radare2.exe...done.
(gdb) break r_file_mmap_write
Function "r_file_mmap_write" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (r_file_mmap_write) pending.
(gdb) run
Starting program: u:\perso\radare2\radare2-w32-0.9.8.git/radare2.exe -w U:/target.exe
[New Thread 3288.0x374]
[New Thread 3288.0xf48]
 -- Choose your architecture by typing: 'e asm.arch=<arch>'
[0x00701da0]> s 0xb049c8
[0x00b049c8]> px
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00b049c8  0300 0000 ffff ffff 0100 0000 0100 0000  ................
...
0x00b04ab8  0000 0000 0000 34c0 0000 0000 0000 0040  ......4........@
[0x00b049c8]> wx 2a

Breakpoint 1, 0x0034ef3c in r_file_mmap_write ()
   from u:\perso\radare2\radare2-w32-0.9.8.git\libr_io.dll
(gdb) n
Single stepping until exit from function r_file_mmap_write,
which has no line number information.
r_file_mmap_write (
    file=0x65a150 "U:/target.exe",
 addr=14235192363905864, buf=0x511bc0 "*ð­º\220««««««««þîþîþîþîþîþ", len=1)
    at file.c:361
361     R_API int r_file_mmap_write(const char *file, ut64 addr, const ut8 *buf,
 int len) {
(gdb) n

Breakpoint 1, r_file_mmap_write (
    file=0x65a150 "U:/target.exe",
 addr=3164616, buf=0x511bc0 "*ð­º\220««««««««þîþîþîþîþîþ", len=1)
    at file.c:364
364             if (r_sandbox_enable (0)) return -1;
(gdb) n
365             fh = CreateFile (file, GENERIC_READ|GENERIC_WRITE,
(gdb) n
368             if (fh == INVALID_HANDLE_VALUE) {
(gdb) n
394             SetFilePointer (fh, addr, NULL, FILE_BEGIN);
(gdb) n
395             if (!WriteFile (fh, buf, len, NULL, NULL)) {
(gdb) print fh
$1 = (HANDLE) 0xd8
(gdb) print addr
$2 = 3164616
(gdb) print buf
$3 = (const unsigned char *) 0x511bc0 "*ð­º\220««««««««þîþîþîþîþîþ"
(gdb) print len
$4 = 1
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x7681deef in WriteFile () from C:\Windows\syswow64\KernelBase.dll
(gdb) bt
#0  0x7681deef in WriteFile () from C:\Windows\syswow64\KernelBase.dll
#1  0x5e1c5a5c in ?? ()
#2  0x00000000 in ?? ()
(gdb)

addr = $2 = 3164616 = 0x3049C8, which looks like the offset I'm trying to write, but not exactly (that was 0x00b049c8=11553224) The difference is exactly 0x800000. the star at the beginning of the buffer at 0x511bc0 is \x2A, which is what I'm trying to write.

[radare]

i cant reproduce the crash it is still hapening? because it works fine for me. to write on va or non-va bins

On 23 Sep 2014, at 12:12, f4grx notifications@github.com wrote:

Better with a breakpoint, now that I know the function :)

$ gdb --args radare2.exe -w U:/target.exe GNU gdb (GDB) 7.6.1 Reading symbols from u:\perso\radare2\radare2-w32-0.9.8.git\radare2.exe...done. (gdb) break r_file_mmap_write Function "r_file_mmap_write" not defined. Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (r_file_mmap_write) pending. (gdb) run Starting program: u:\perso\radare2\radare2-w32-0.9.8.git/radare2.exe -w U:/perso /ownCloud/documents/Security/work/QuickFilter42.exe [New Thread 3288.0x374] [New Thread 3288.0xf48] -- Choose your architecture by typing: 'e asm.arch=' [0x00701da0]> s 0xb049c8 [0x00b049c8]> px

• offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0x00b049c8 0300 0000 ffff ffff 0100 0000 0100 0000 ................ ... 0x00b04ab8 0000 0000 0000 34c0 0000 0000 0000 0040 ......4........@ [0x00b049c8]> wx 2a

Breakpoint 1, 0x0034ef3c in r_file_mmap_write () from u:\perso\radare2\radare2-w32-0.9.8.git\libr_io.dll (gdb) n Single stepping until exit from function r_file_mmap_write, which has no line number information. r_file_mmap_write ( file=0x65a150 "U:/target.exe", addr=14235192363905864, buf=0x511bc0 "ð­º\220««««««««þîþîþîþîþîþ", len=1) at file.c:361 361 R_API int r_file_mmap_write(const char file, ut64 addr, const ut8 *buf, int len) { (gdb) n

Breakpoint 1, r_file_mmap_write ( file=0x65a150 "U:/target.exe", addr=3164616, buf=0x511bc0 "_ð­º\220««««««««þîþîþîþîþîþ", len=1) at file.c:364 364 if (r_sandbox_enable (0)) return -1; (gdb) n 365 fh = CreateFile (file, GENERIC_READ|GENERIC_WRITE, (gdb) n 368 if (fh == INVALID_HANDLE_VALUE) { (gdb) n 394 SetFilePointer (fh, addr, NULL, FILE_BEGIN); (gdb) n 395 if (!WriteFile (fh, buf, len, NULL, NULL)) { (gdb) print fh $1 = (HANDLE) 0xd8 (gdb) print addr $2 = 3164616 (gdb) print buf $3 = (const unsigned char *) 0x511bc0 "_ð­º\220««««««««þîþîþîþîþîþ" (gdb) print len $4 = 1 (gdb) n

Program received signal SIGSEGV, Segmentation fault. 0x7681deef in WriteFile () from C:\Windows\syswow64\KernelBase.dll (gdb) — Reply to this email directly or view it on GitHub.