radare2
radare2 copied to clipboard
radareorg
r2 gdb:// doesn't work with winedbg --gdb --no-start
[fedora@localhost malware]$ winedbg --gdb --no-start shylock_d.exe 003e:003f: create process 'Z:\home\fedora\malware\shylock_d.exe'/0x1106e8 @0x4044b0 (0<0>) 003e:003f: create thread I @0x4044b0 target remote localhost:44840 003e:003f: loads DLL C:\windows\system32\KERNEL32.dll @0x7b810000 (0<0>) 003e:003f: loads DLL C:\windows\system32\ntdll.dll @0x7bc10000 (0<0>) 003e:003f: loads DLL C:\windows\system32\advapi32.dll @0x7ec70000 (0<0>) 003e:003f: loads DLL C:\windows\system32\gdi32.dll @0x7ece0000 (0<0>) 003e:003f: loads DLL C:\windows\system32\version.dll @0x7eaf0000 (0<0>) 003e:003f: loads DLL C:\windows\system32\user32.dll @0x7eb10000 (0<0>) 003e:003f: loads DLL C:\windows\system32\rpcrt4.dll @0x7e880000 (0<0>) 003e:003f: loads DLL C:\windows\system32\ole32.dll @0x7e900000 (0<0>) 003e:003f: loads DLL C:\windows\system32\msacm32.dll @0x7e840000 (0<0>) 003e:003f: loads DLL C:\windows\system32\winmm.dll @0x7ea40000 (0<0>) 003e:003f: loads DLL C:\windows\system32\winscard.dll @0x7e830000 (0<0>) 0000003e:0000003f: exception code=0x80000003
[fedora@localhost malware]$ r2 gdb://localhost:44840 r_debug_select: 6 6 p/debug_native.c:2382 debug_init_maps: /proc: No such file or directory r_debug_select: 146750248 6 r_debug_reg: error reading registers pid=146750248 r_debug_reg: error reading registers pid=146750248 -- Use hasher to calculate hashes of portion blocks of a file r_debug_reg: error reading registers pid=146750248 [0x00000000]>
Different register profile maybe?
On 21 May 2014, at 22:46, Anton Kochkov [email protected] wrote:
@rlaemmert - that may be related to the libgdbr
— Reply to this email directly or view it on GitHub.
Try adding -D gdb
On 21 May 2014, at 22:44, Anton Kochkov [email protected] wrote:
[fedora@localhost malware]$ winedbg --gdb --no-start shylock_d.exe 003e:003f: create process 'Z:\home\fedora\malware\shylock_d.exe'/0x1106e8 @0x4044b0 (0) 003e:003f: create thread I @0x4044b0 target remote localhost:44840 003e:003f: loads DLL C:\windows\system32\KERNEL32.dll @0x7b810000 (0) 003e:003f: loads DLL C:\windows\system32\ntdll.dll @0x7bc10000 (0) 003e:003f: loads DLL C:\windows\system32\advapi32.dll @0x7ec70000 (0) 003e:003f: loads DLL C:\windows\system32\gdi32.dll @0x7ece0000 (0) 003e:003f: loads DLL C:\windows\system32\version.dll @0x7eaf0000 (0) 003e:003f: loads DLL C:\windows\system32\user32.dll @0x7eb10000 (0) 003e:003f: loads DLL C:\windows\system32\rpcrt4.dll @0x7e880000 (0) 003e:003f: loads DLL C:\windows\system32\ole32.dll @0x7e900000 (0) 003e:003f: loads DLL C:\windows\system32\msacm32.dll @0x7e840000 (0) 003e:003f: loads DLL C:\windows\system32\winmm.dll @0x7ea40000 (0) 003e:003f: loads DLL C:\windows\system32\winscard.dll @0x7e830000 (0) 0000003e:0000003f: exception code=0x80000003
[fedora@localhost malware]$ r2 gdb://localhost:44840 r_debug_select: 6 6 p/debug_native.c:2382 debug_init_maps: /proc: No such file or directory r_debug_select: 146750248 6 r_debug_reg: error reading registers pid=146750248 r_debug_reg: error reading registers pid=146750248 -- Use hasher to calculate hashes of portion blocks of a file r_debug_reg: error reading registers pid=146750248 [0x00000000]>
— Reply to this email directly or view it on GitHub.
It worksif run it as r2 -a x86 -b 32 gdb:// but when loaded it shows only zeroes in p* output
Rio is broken now for debuggers. Current issue is not gdb specific
On 24 May 2014, at 00:26, Anton Kochkov [email protected] wrote:
It worksif run it as r2 -a x86 -b 32 gdb:// but when loaded it shows only zeroes in p* output
— Reply to this email directly or view it on GitHub.
The r_io should be fixed now. use -D too, this will enable the io.raw=true and cfg.debug=true Please verify
Hm nothing gdb specific seems to work now. Just tested the connection to my qemu win8 x64 instance...
I cant manage to get --no-start or --gdb working beside iits listed in winedbg help.
We need a gdbserver implementation in r2. Anyone? :)
On 26 May 2014, at 20:44, Rene Laemmert [email protected] wrote:
Hm nothing gdb specific seems to work now. Just tested the connection to my qemu win8 x64 instance...
— Reply to this email directly or view it on GitHub.
We need a fully working debuggin facility first :P Write registers would be nice
On Tue, May 27, 2014 at 6:19 PM, radare [email protected] wrote:
I cant manage to get --no-start or --gdb working beside iits listed in winedbg help.
We need a gdbserver implementation in r2. Anyone? :)
On 26 May 2014, at 20:44, Rene Laemmert [email protected] wrote:
Hm nothing gdb specific seems to work now. Just tested the connection to my qemu win8 x64 instance...
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHubhttps://github.com/radare/radare2/issues/955#issuecomment-44298737 .
This was workinf in the previous implementation :p
On 27 May 2014, at 18:28, Rene Laemmert [email protected] wrote:
We need a fully working debuggin facility first :P Write registers would be nice
On Tue, May 27, 2014 at 6:19 PM, radare [email protected] wrote:
I cant manage to get --no-start or --gdb working beside iits listed in winedbg help.
We need a gdbserver implementation in r2. Anyone? :)
On 26 May 2014, at 20:44, Rene Laemmert [email protected] wrote:
Hm nothing gdb specific seems to work now. Just tested the connection to my qemu win8 x64 instance...
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHubhttps://github.com/radare/radare2/issues/955#issuecomment-44298737 .
— Reply to this email directly or view it on GitHub.
Dont think so :P
On Tue, May 27, 2014 at 6:43 PM, radare [email protected] wrote:
This was workinf in the previous implementation :p
On 27 May 2014, at 18:28, Rene Laemmert [email protected] wrote:
We need a fully working debuggin facility first :P Write registers would be nice
On Tue, May 27, 2014 at 6:19 PM, radare [email protected] wrote:
I cant manage to get --no-start or --gdb working beside iits listed in winedbg help.
We need a gdbserver implementation in r2. Anyone? :)
On 26 May 2014, at 20:44, Rene Laemmert [email protected] wrote:
Hm nothing gdb specific seems to work now. Just tested the connection to my qemu win8 x64 instance...
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub< https://github.com/radare/radare2/issues/955#issuecomment-44298737> .
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHubhttps://github.com/radare/radare2/issues/955#issuecomment-44302033 .
All debuggrrs only work if loaded with -n. Will look at this bug later, but the io seems to work better now
On 27 May 2014, at 18:45, Rene Laemmert [email protected] wrote:
Dont think so :P
On Tue, May 27, 2014 at 6:43 PM, radare [email protected] wrote:
This was workinf in the previous implementation :p
On 27 May 2014, at 18:28, Rene Laemmert [email protected] wrote:
We need a fully working debuggin facility first :P Write registers would be nice
On Tue, May 27, 2014 at 6:19 PM, radare [email protected] wrote:
I cant manage to get --no-start or --gdb working beside iits listed in winedbg help.
We need a gdbserver implementation in r2. Anyone? :)
On 26 May 2014, at 20:44, Rene Laemmert [email protected] wrote:
Hm nothing gdb specific seems to work now. Just tested the connection to my qemu win8 x64 instance...
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub< https://github.com/radare/radare2/issues/955#issuecomment-44298737> .
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHubhttps://github.com/radare/radare2/issues/955#issuecomment-44302033 .
— Reply to this email directly or view it on GitHub.
Faced with similar problem
> r2 -v
radare2 4.1.0-git 23412 @ linux-x86-64 git.4.0.0-153-ge0b197766
commit: e0b197766811db0952d243b2df36969d34cee36e build: 2019-11-29__14:23:07
> winedbg --gdb --no-start ViPNet_CSP_RUS_4.2.8.51670.exe
0038:0039: create process ''/0x110968 @0x42d3d5 (0<0>)
0038:0039: create thread I @0x42d3d5
target remote localhost:51607
r2 -a x86 -b 32 -D gdb gdb://127.0.0.1:51607
gdb.io.open: Cannot connect to host.
[r] Cannot open 'gdb://127.0.0.1:51607'
Thanks for providing the pcap file! Had a more indicative error in winedbg when I was looking into it recently so I'll take another look. Didn't think anyone uses it until now..
According to Wine devs, the gdb implementation isn't really in use so there might also be some issues on their side. Have you tried debugging wine processes with regular gdb? It should be possible.
Have you tried debugging wine processes with regular gdb? It should be possible.
Yes, gdb works well. At least I can use breakpoints.
Great! Will still look into it but at least you have other options for now :) Just use gdbserver with r2 instead of gdb.