Fix: format PE32+ baddr

[chr-chr]

I got a PE32+ binary with baddr = 0x0 which is not "messed up".

I see no reason to set this to 0x10000

rz-bin -H myfile
paddr      name                                    vaddr      comment    
-------------------------------------------------------------------------
...
0x00000e88 ImageBase                               0x00000e88 0x00000000

Work environment

Questions	Answers
OS/arch/bits (mandatory)	Debian arm 64, Ubuntu x86 32
File format of the file you reverse (mandatory)	PE32+
Architecture/bits of the file (mandatory)	ARM64
rizin -v full output, not truncated (mandatory)	rizin 0.3.1 @ linux-x86-64 commit: 6ef55aa63a563864774f4777dcd1a69933b62a72, build: 2021-11-24__12:29:16

Expected behavior

rz-bin -I myfile
[Info]
arch     arm
cpu      N/A
baddr    0x00000000
binsz    0x000a0000
bintype  pe
bits     64
retguard false
class    PE32+
...

o myfile

[0x00001000]> om
 1 fd: 3 +0x00001000 0x00001000 - 0x00083fff r-x fmap..text

Actual behavior

rz-bin -I myfile
[Info]
arch     arm
cpu      N/A
baddr    0x00010000
binsz    0x000a0000
bintype  pe
bits     64
retguard false
class    PE32+
...

[0x00011000]> om
 1 fd: 3 +0x00001000 0x00011000 - 0x00092fff r-x fmap..text

Steps to reproduce the behavior

• rz-bin -H is correct
• rz-bin -I is not
• rizin "o myfile" mapping gets messed

Additional Logs, screenshots, source code, configuration dump, ...

if (!imageBase) { //this should only happens with messed up binaries

Well, myfile is not messed up at all.

[XVilka]

Can you share the file?

[chr-chr]

Can you share the file?

no

[XVilka]

See also https://reverseengineering.stackexchange.com/questions/6242/windows-why-is-the-imagebase-default-0x400000

[ret2libc]

I still need to understand what is the real problem with your binary. Can you show me the problem?

[chr-chr]

I still need to understand what is the real problem with your binary. Can you show me the problem?

My binary got this problem:

Having 0x0 as ImageBase it gets relocated by rizin to 0x10000 which is wrong.

Manually using -B is bugged (project saving) also using 'o ' does not work in case baddr=0x0

also see

https://github.com/rizinorg/rizin/pull/2641

[ret2libc]

I still need to understand what is the real problem with your binary. Can you show me the problem?

My binary got this problem:

Having 0x0 as ImageBase it gets relocated by rizin to 0x10000 which is wrong.

What is wrong exactly? Is your binary relocatable? I think UEFI app are, as they could be loaded at different addresses based on several things. So, in theory, i think there should be no problems with the binary being moved to 0x10000. Do you see some wrong value? Could you share at least part of the disassembly you see wrong?

[chr-chr]

What is wrong exactly?

I have several PE32+binaries from an UEFI arm64 bootloader.

Their fields clearly say: ImageBase = 0x0 which is correct.

Is there any reason to add 0x10000 ? This way they all load incorrect. Also "o file 0x0" does not work!

Looong answer: https://github.com/rizinorg/rizin/pull/2641

[ret2libc]

I understand that image base says 0. I also understand that there should be a way to have an address different from 0x10000, if one wants so.

However you keep not answering the question. What is wrong with your binaries exactly? Assume for a moment that they are loaded at an addr!=0(which actually is the case because UEFI app should be relocated and could be/are loaded at a different addresses each time). Is there anything wrong with the disassembly?

[chr-chr]

However you keep not answering the question.

You set me up.

I briefly described this Problem. Look at "Actual behavior" and "Expected behavior".

There is nothing wrong with my binaries.

rizin is loading with an offset which is just wrong !!

This was discussed here: https://github.com/rizinorg/rizin/pull/2641

[chr-chr]

I reworked the patches according to comments

[ret2libc]

However you keep not answering the question.

rizin is loading with an offset which is just wrong !!

What I am saying is that unless there are other bugs in the PE code, you should not see any problem whether rizin loads the UEFI app at 0x10000, 0, 0x3000000 or 0xcafe0000, because the UEFI system can (and does AFAIK) load your UEFI application at an address different from 0 usually and it relocates the app, so there should be no problem having the binary loaded there.

Do you see any problem with your binaries being loaded at 0x10000?

[chr-chr]

You are alright about relocation, that should just work but

Do you see any problem with your binaries being loaded at 0x10000?

Simply yes. The mapping all gets ImageBase as an offset. I was using stable version, the analysis tools failed finding references, problems with cutter, missing xrefs, reloading project was a pain, ... it all worked just halfway.

Ok, Actually I fail to reproduce with dev version, seems to work better. Got to compile cutter aswell.