Incorrect decompilation

[ghost]

98acc7530cf84c731ff1f42de12b6c21b1ac3778.zip

Decompiling the uploaded file (password is: 'infected' and as obviously be warned that the file itself is malicious) gives the following decompilation:

//
// This file was generated by the Retargetable Decompiler
// Website: https://retdec.com
// Copyright (c) 2019 Retargetable Decompiler <info@retdec.com>
//

#include <stdint.h>

// ------------------------ Structures ------------------------

struct HINSTANCE__ {
    int32_t e0;
};

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

int32_t _WinMain_40_16(struct HINSTANCE__ * hInstance, struct HINSTANCE__ * hPrevInstance, char * lpCmdLine, int32_t nShowCmd);

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

// Address range: 0x40147c - 0x40148e
int32_t _WinMain_40_16(struct HINSTANCE__ * hInstance, struct HINSTANCE__ * hPrevInstance, char * lpCmdLine, int32_t nShowCmd) {
    // 0x40147c
    return 0;
}

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

// Detected compiler/packer: upx
// Detected functions: 1
// Decompilation date: 2019-02-05 09:00:08

The IDA disassembly shows the following code:

Even if the jump and other not interesting instructions are optimized away by RetDec, my opinion is that important call instruction shouldn't be skipped.

[s3rvac]

@PeterMatula can you please verify?

[ghost]

I've just realized that it might be because as IDA shows the call instruction itself is not in the "scope" of WinMain, but comes right after a jump. Just a theoretical question: Do you think it's okay like this? I mean not showing any disassembled code for the jump taken?

[s3rvac]

The empty body with return 0 that we generate seems definitely fishy. @PeterMatula will look into this and will let you know.