- Binary Ninja Version: 3.2.3906-dev
- OS: Windows 11, x64
Bug Description:
As you can see from disassembly below, actually it calls rdi which stores the address of MiniDumpReadDumpStream. But in decompiler output it calls rax which is already overwritten in HLIL output. MLIL looks like correct, so it could be related to MLIL -> HLIL translation.
HLIL:
193d2f84 FARPROC rax
193d2f84 if (arg1 != 0)
193d2f91 rax = GetProcAddress(arg1, "MiniDumpReadDumpStream")
193d2f9d if (rax != 0)
193d2fb3 int32_t var_60_1 = 0
193d2fc7 rax = CreateFileA(arg2, 0x80000000, FILE_SHARE_READ, nullptr, OPEN_EXISTING, SECURITY_ANONYMOUS, nullptr)
193d2fd4 if (rax != -1)
193d2fe6 var_60_1.q = 0
193d2ff8 int32_t var_68 = 0
193d2ffd int64_t r12
193d2ffd r12.b = 0
193d3000 HANDLE rax_1 = CreateFileMappingA(rax, nullptr, PAGE_READONLY, 0, 0, nullptr)
193d300c if (rax_1 != 0)
193d301d var_68.q = 0
193d3029 void* rax_2 = MapViewOfFile(rax_1, FILE_MAP_READ, 0, 0, nullptr)
193d3035 if (rax_2 != 0)
193d3043 int64_t var_48 = 0
193d3050 var_68.q = &arg_8
193d305a arg_20 = nullptr
193d3066 arg_8 = 0
193d3071 int32_t rax_3 = rax(rax_2, 5, &var_48, &arg_20, var_68)
Disassembly:
193d2f8a lea rdx, [rel data_193efc38] {"MiniDumpReadDumpStream"}
193d2f91 call qword [rel GetProcAddress]
193d2f97 mov rdi, rax
193d2f9a test rax, rax
193d2f9d je 0x193d3156
193d2fa3 xor r13d, r13d {0x0}
193d2fa6 xor r9d, r9d {0x0}
193d2fa9 mov qword [rsp+0x30 {var_58}], r13 {0x0}
193d2fae mov edx, 0x80000000
193d2fb3 mov dword [rsp+0x28 {var_60_1}], r13d {0x0}
193d2fb8 mov rcx, rsi
193d2fbb mov dword [rsp+0x20], 0x3
193d2fc3 lea r8d, [r13+0x1]
193d2fc7 call qword [rel CreateFileA]
193d2fcd mov rbp, rax
193d2fd0 cmp rax, 0xffffffffffffffff
193d2fd4 je 0x193d3156
193d2fda mov qword [rsp+0x98 {__saved_r12}], r12
193d2fe2 lea r8d, [r13+0x2]
193d2fe6 mov qword [rsp+0x28 {var_60_1}], r13 {0x0}
193d2feb xor r9d, r9d {0x0}
193d2fee xor edx, edx {0x0}
193d2ff0 mov qword [rsp+0x58 {__saved_r14}], r14
193d2ff5 mov rcx, rax
193d2ff8 mov dword [rsp+0x20 {var_68}], r13d {0x0}
193d2ffd xor r12b, r12b {0x0}
193d3000 call qword [rel CreateFileMappingA]
193d3006 mov r14, rax
193d3009 test rax, rax
193d300c je 0x193d3131
193d3012 xor r9d, r9d {0x0}
193d3015 mov qword [rsp+0x50 {__saved_r15}], r15
193d301a xor r8d, r8d {0x0}
193d301d mov qword [rsp+0x20 {var_68}], r13 {0x0}
193d3022 lea edx, [r13+0x4]
193d3026 mov rcx, rax
193d3029 call qword [rel MapViewOfFile]
193d302f mov r15, rax
193d3032 test rax, rax
193d3035 je 0x193d3123
193d303b lea rax, [rsp+0x90 {arg_8}]
193d3043 mov qword [rsp+0x40 {var_48}], r13 {0x0}
193d3048 lea r9, [rsp+0xa8 {arg_20}]
193d3050 mov qword [rsp+0x20 {var_68}], rax {arg_8}
193d3055 lea r8, [rsp+0x40 {var_48}]
193d305a mov qword [rsp+0xa8 {arg_20}], r13 {0x0}
193d3062 lea edx, [r13+0x5]
193d3066 mov dword [rsp+0x90 {arg_8}], r13d {0x0}
193d306e mov rcx, r15
193d3071 call rdi
Additional Information:
I can share BNDB via PM in slack.
Bug Description:
As you can see from disassembly below, actually it calls
rdiwhich stores the address ofMiniDumpReadDumpStream. But in decompiler output it callsraxwhich is already overwritten in HLIL output. MLIL looks like correct, so it could be related to MLIL -> HLIL translation.HLIL:
Disassembly:
Additional Information:
I can share BNDB via PM in slack.