Disassembly is not 32bit and imports are not loaded when debugging 32bit binary on 64bit system

[debuhr]

Sample: http://pastebin.com/DWeqcs4V

Binary used: http://www.reversing.be/easyfile/file.php?show=20080713151812213

On irc pancake suggested

e asm.bits=32
.!rabin2 -risv yourfile

which seemed to work at first glance but when you try to step:

[0x080485d4]> ds
trace_pc: cannot get opcode size at 0x0

and rip of 0x0

[debuhr]

% r2 -b 32 -d ./keygenme
Process with PID 24742 started...
PID = 24742
io_redirect: ptrace://24742
r_debug_select: 24742 -1
[0x00000200]> e asm.bits=32
[0x00000200]> .!rabin2 -risv keygenme
[0x00000200]> db 0x080485d4          #bp on main
[0x00000200]> dc
trace_pc: cannot get opcode size at 0x0
[R2] Breakpoint recoil at 0x0 = 0
r_debug_select: 24742 0
[0xffffffff]> 

[XVilka]

Bug is still here, see debugging 32bit elf on 64bit fedora 19 (example file is on http://pof.eslack.org/tmp/IOLI-crackme.tar.gz bin-linux/crackme0x03)

r2 -d ./crackme0x03
Process with PID 25728 started...
PID = 25728
r_debug_select: 25728 25728
 -- Use -j in rabin2 to get the information of the binary in JSON format
[0x00000000]> db sym.
sym.__CTOR_LIST__            sym.__DTOR_LIST__            
sym.__JCR_LIST__             sym.p.0                      sym.completed.1              
sym.__do_global_dtors_aux    sym.frame_dummy              sym.__CTOR_END__            
sym.__DTOR_END__             sym.__FRAME_END__            sym.__JCR_END__              
sym.__do_global_ctors_aux    sym._GLOBAL_OFFSET_TABLE_    sym.__init_array_end        
sym.__init_array_start       sym._DYNAMIC                 sym.data_start              
sym.__libc_csu_fini          sym._start                   sym._fp_hw                  
sym._fini                    sym._IO_stdin_used           sym.__data_start            
sym.__dso_handle             sym.__libc_csu_init          sym.test                    
sym.__i686.get_pc_thunk.bx   sym.shift                    sym.main                    
sym._init                    sym.imp.__gmon_start__       sym.imp.__libc_start_main    
sym.imp.scanf                sym.imp.strlen               sym.imp.printf              
[0x00000000]> db sym.main
[0x00000000]> dc
[R2] Breakpoint recoil at 0x0 = 0
r_debug_select: 25728 0
[0xffffffff]> dr
eip = 0xffffffff
oeax = 0x00000000
eax = 0x00000000
ebx = 0x00000000
ecx = 0x00000000
edx = 0x00000000
esp = 0x00000000
ebp = 0x00000000
esi = 0x00000000
edi = 0x00000000
eflags = 0x00000000
[0xffffffff]>

[jvoisin]

$ r2 -b 32 -d ./keygenme
Process with PID 30730 started...
PID = 30730
r_debug_select: 30730 30730
[0xf77030d0]> pD 100
zsh: segmentation fault (core dumped)  r2 -b 32 -d ./keygenme
$

[radare]

damn regressions :(

On 06 May 2014, at 17:07, jvoisin notifications@github.com wrote:

$ r2 -b 32 -d ./keygenme
Process with PID 30730 started...
PID = 30730
r_debug_select: 30730 30730
[0xf77030d0]> pD 100
zsh: segmentation fault (core dumped) r2 -b 32 -d ./keygenme
$
—
Reply to this email directly or view it on GitHub.

[jvoisin]

I can't reproduce the issue on latest git \o/

[radare]

Dont worry. I'm sure the bug will appear again sooner or later :p

On 08 Jun 2014, at 03:45, jvoisin notifications@github.com wrote:

I can't reproduce the issue on latest git \o/

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

[jvoisin]

Then we'll open a new issue :)