retdec icon indicating copy to clipboard operation
retdec copied to clipboard

variable not initialized bug when value casting

Open KnoooW opened this issue 2 years ago • 3 comments

Example Code:

`#include <stdint.h>

int64_t sub(int *x) { if(*x) { return 0 ; } int32_t a1 = 1 ; int64_t a2 = 2 ; a2 = a1 ; return a2 ; }

int main() { sub(0); return 0; }`

Lets generate out X86-64 binary: Generally bug exits on X86-64 AND ARM64 decomiling. I test on X86-64 arch -arch=x86_64 clang aaa.c -O0 -o aaa && cp aaa aaa.out

ASM:

public _sub __text:0000000100003F40 _sub proc near ; CODE XREF: _main+13↓p __text:0000000100003F40 __text:0000000100003F40 var_20 = qword ptr -20h __text:0000000100003F40 var_14 = dword ptr -14h __text:0000000100003F40 var_10 = qword ptr -10h __text:0000000100003F40 var_8 = qword ptr -8 __text:0000000100003F40 __text:0000000100003F40 push rbp __text:0000000100003F41 mov rbp, rsp __text:0000000100003F44 mov [rbp+var_10], rdi __text:0000000100003F48 mov rax, [rbp+var_10] __text:0000000100003F4C cmp dword ptr [rax], 0 __text:0000000100003F4F jz loc_100003F62 __text:0000000100003F55 mov [rbp+var_8], 0 __text:0000000100003F5D jmp loc_100003F81 __text:0000000100003F62 ; --------------------------------------------------------------------------- __text:0000000100003F62 __text:0000000100003F62 loc_100003F62: ; CODE XREF: _sub+F↑j __text:0000000100003F62 mov [rbp+var_14], 1 __text:0000000100003F69 mov [rbp+var_20], 2 __text:0000000100003F71 movsxd rax, [rbp+var_14] __text:0000000100003F75 mov [rbp+var_20], rax __text:0000000100003F79 mov rax, [rbp+var_20] __text:0000000100003F7D mov [rbp+var_8], rax __text:0000000100003F81 __text:0000000100003F81 loc_100003F81: ; CODE XREF: _sub+1D↑j __text:0000000100003F81 mov rax, [rbp+var_8] __text:0000000100003F85 pop rbp __text:0000000100003F86 retn

Try RetDec TeamCity Build:

RetDec version : v4.0-421-gf9ac9ec7 Commit hash : f9ac9ec7e8af77bc14944ce2650c9bbcc84f6368 Build date : 2022-04-28T07:20:02Z

Result: LL:

`source_filename = "test" target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"

define i64 @_sub() local_unnamed_addr { dec_label_pc_100003f38: %0 = alloca i64 %1 = load i64, i64* %0 %2 = trunc i64 %1 to i32 %3 = icmp eq i32 %2, 0, !insn.addr !0 %. = zext i1 %3 to i64 ret i64 %., !insn.addr !1 }

define i64 @main(i64 %argc, i8** %argv) local_unnamed_addr { dec_label_pc_100003f80: %0 = call i64 @_sub(), !insn.addr !2 ret i64 0, !insn.addr !3 }

!0 = !{i64 4294983496} !1 = !{i64 4294983548} !2 = !{i64 4294983580} !3 = !{i64 4294983596}`

decompiled-out c:

`#include <stdint.h>

// ------------------- Function Prototypes --------------------

int64_t _sub(void);

// ------------------------ Functions -------------------------

// Address range: 0x100003f38 - 0x100003f80 int64_t _sub(void) { // 0x100003f38 int64_t v1; // 0x100003f38 return (int32_t)v1 == 0; }

// Address range: 0x100003f80 - 0x100003fb0 int main(int argc, char ** argv) { // 0x100003f80 _sub(); return 0; }

// --------------------- Meta-Information ---------------------

// Detected functions: 2 `

The Problem is v1 is not proper initialized。it should be a1。

KnoooW avatar May 07 '22 03:05 KnoooW

any response?

KnoooW avatar May 10 '22 02:05 KnoooW

Thanks for the thoroughly detailed issue. Would you please also upload the binary itself? Although you gave us all the information, my compiler could generate something slightly different, and it would be slightly less hassle for me.

I will try to have a look at it in a few days.

PeterMatula avatar May 11 '22 07:05 PeterMatula

Thanks for the thoroughly detailed issue. Would you please also upload the binary itself? Although you gave us all the information, my compiler could generate something slightly different, and it would be slightly less hassle for me.

I will try to have a look at it in a few days.

abc_406016.zip

ok above is the test binary, a MACH-O X86-64 bin.

KnoooW avatar May 13 '22 03:05 KnoooW