Cross references are broken in rebased binaries

[oddcoder]

$> r2 challenge1.exe
[]>aaa
[]>iz ~pass                                                                                                                                                   
vaddr=0x0040d198 paddr=0x0000bf98 ordinal=001 sz=18 len=17 section=.rdata type=ascii string=Enter password:\r\n                                                      
vaddr=0x0040d1b8 paddr=0x0000bfb8 ordinal=003 sz=17 len=16 section=.rdata type=ascii string=Wrong password\r\n  
[]>axt 0x0040d198                                                                                                                                              
data 0x40144e push str.Enter_password:_r_n in sub.KERNEL32.dll_GetStdHandle_420  

$ r2 -B 0xfd0000 challenge1.exe
[]>aaa
[]>iz ~pass                                                                                                                                                   
vaddr=0x00fdd198 paddr=0x0000bf98 ordinal=001 sz=18 len=17 section=.rdata type=ascii string=Enter password:\r\n                                                           
vaddr=0x00fdd1b8 paddr=0x0000bfb8 ordinal=003 sz=17 len=16 section=.rdata type=ascii string=Wrong password\r\n 
[]>axt 0x00fdd198

this is the used binary
challenge1.exe.zip

[radare]

i think @ret2libc fixed this, can you confirm?

[ret2libc]

I'm honestly not sure I did... or when. But please re-test the reproducer :)

[oddcoder]

nope, not fixed, actually addresses failed to relocate and triggered an issue in afta as well

➜  Downloads r2 -B 0xfd0000 challenge1.exe
[0x00fd170d]> aaa
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze function calls (aac)
[x] Analyze len bytes of instructions for references (aar)
[Stack isn't initialized.s for all functions (aaft)
Try running aei and aeim commands before aft for default stack initialization
Stack isn't initialized.
[.. bunch of failing to initialize stacks ...]
Try running aei and aeim commands before aft for default stack initialization
Stack isn't initialized.
[x] Type matching analysis for all functions (aaft)
[x] Use -AA or aaaa to perform additional experimental analysis.
[0x00fd170d]> iz~pass
001 0x0000bf98 0x0040d198  17  18 (.rdata) ascii Enter password:\r\n
003 0x0000bfb8 0x0040d1b8  16  17 (.rdata) ascii Wrong password\r\n
[0x00fd170d]> axt 0x0040d1b8
[0x00fd170d]> axt 0x00fdd198

[radare]

is this bini relocatable? anyway, -B doesnt seems to work fine with strings, so the strings flags are not relocated at all

…

On 18 Mar 2019, at 17:07, Ahmed Abd El Mawgood ***@***.***> wrote: nope, not fixed, actually addresses failed to relocate and triggered an issue in afta as well ➜ Downloads r2 -B 0xfd0000 /bin/ls [0x00fd5310]> aaa [x] Analyze all flags starting with sym. and entry0 (aa) [x] Analyze function calls (aac) [x] Analyze len bytes of instructions for references (aar) [x] Type matching analysis for all functions (aaft) [x] Use -AA or aaaa to perform additional experimental analysis. [0x00fd5310]> q ➜ Downloads r2 -B 0xfd0000 challenge1.exe [0x00fd170d]> aaa [x] Analyze all flags starting with sym. and entry0 (aa) [x] Analyze function calls (aac) [x] Analyze len bytes of instructions for references (aar) [Stack isn't initialized.s for all functions (aaft) Try running aei and aeim commands before aft for default stack initialization Stack isn't initialized. [.. bunch of failing to initialize stacks ...] Try running aei and aeim commands before aft for default stack initialization Stack isn't initialized. [x] Type matching analysis for all functions (aaft) [x] Use -AA or aaaa to perform additional experimental analysis. [0x00fd170d]> iz~pass 001 0x0000bf98 0x0040d198 17 18 (.rdata) ascii Enter password:\r\n 003 0x0000bfb8 0x0040d1b8 16 17 (.rdata) ascii Wrong password\r\n [0x00fd170d]> axt 0x0040d1b8 [0x00fd170d]> axt 0x00fdd198 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5905 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3-lqdOgXlzO-glSDvzDzUevMmbjAe0ks5vX7nfgaJpZM4KNEpc>.

[radare]

Will be fixed with #13753. Do you wanna work on it? or at least write some tests when its implemented?

[oddcoder]

sure I can unit test it once it is implemented just mention me in the PR, right now I can't see a pr for it

[radare]

enotime for this rls

[radare]

can you provide a test?

[oddcoder]

I have a trigger explained above ^ and the binary file as well

[radare]

cc @yossizap

[yossizap]

Will look into it

[radare]

@yossizap 12h left for the release. any update on this?

[yossizap]

Sorry, didn't have a ton of time. This is a PE specific issue.

radare2/libr/bin/format/pe/pe.c

Lines 341 to 348 in 35b05d8

	imageBase = bin->nt_headers->optional_header.ImageBase;
	if (!imageBase) {
	//this should only happens with messed up binaries
	//XXX this value should be user defined by bin.baddr
	//but from here we can not access config API
	imageBase = 0x10000;
	}
	return imageBase;

It uses the baddr from the header instead of using the actual binaddr. Attempting to fix.

[radare]

thanks

[yossizap]

That was a separate issue that was misleading. Can't really find any other differences specific to PEs that deal with baddr. This will require more time, maybe I'll be able to find something tomorrow morning.

Not an issue in debug rebase btw, just with this type of rebase.

EDIT: Also, not an issue with other windows binaries. This seems to be specific to something in that binary.

[radare]

see the new rb command (needs to implement anal things)