rellic decompilation failure

[0x410c]

F20230510 17:32:52.513430 15913 ASTBuilder.cpp:158] Check failed: val.getBitWidth() == ctx.getIntWidth(type) (128 vs. 64) *** Check failure stack trace: *** @ 0x5dd39c google::LogMessageFatal::~LogMessageFatal() @ 0x5c3501 rellic::ASTBuilder::CreateIntLit() @ 0x5c3557 rellic::ASTBuilder::CreateAdjustedIntLit() @ 0x4c60f0 rellic::ASTBuilder::CreateAdjustedIntLit() @ 0x4be532 rellic::ExprGen::CreateLiteralExpr() @ 0x4bec55 rellic::ExprGen::CreateOperandExpr() @ 0x4c225d rellic::ExprGen::visitCmpInst() @ 0x4bedf3 rellic::ExprGen::CreateOperandExpr() @ 0x4c010d rellic::ExprGen::visitCallInst() @ 0x4c35c6 rellic::StmtGen::visitCallInst() @ 0x4c3d1b rellic::IRToASTVisitor::VisitBasicBlock() @ 0x4afe60 rellic::GenerateAST::CreateRegionStmts() @ 0x4b33f6 rellic::GenerateAST::StructureRegion() @ 0x4b3866 rellic::GenerateAST::run() @ 0x4bbf4d llvm::detail::PassModel<>::run() @ 0x2ef5c91 llvm::PassManager<>::run() @ 0x4b4832 rellic::GenerateAST::run() @ 0x436014 rellic::Decompile() @ 0x42b243 main @ 0x7ff7a1c29d90 (unknown) @ 0x7ff7a1c29e40 __libc_start_main @ 0x42a77e _start @ (nil) (unknown) Aborted (core dumped)

[frabert]

I'm going to need more details to help. Can you share the module that's causing issues?

I'm guessing that in this case Rellic tried to create a 128 bit wide integer, but AFAIK C doesn't provide such a type

[0x410c]

i tried a function :

FF0301D1E00F00F9E10B00F9E20700F9E00F40F9E01F00F9E00B40F9E01B00F9E00740F91F1C00F109070054E11F40F9E01B40F9200000AA000840921F0000F141060054E01F40F9E01700F9E01B40F9E01300F910000014E01740F9010040F9E01340F9000040F93F0000EBC1010054E01740F900200091E01700F9E01340F900200091E01300F9E00740F9002000D1E00700F9E00740F91F1C00F1E8FDFF54020000141F2003D5E01740F9E01F00F9E01340F9E01B00F914000014E01F40F901004039E01B40F9000040393F00006B00010054E01F40F900004039E103002AE01B40F9000040392000004B0D000014E01F40F900040091E01F00F9E01B40F900040091E01B00F9E00740F9010400D1E10700F91F0000F121FDFF5400008052FF030191C0035FD6

[frabert]

Is that a hex encoded LLVM module? Could you translate it into textual format and share it?

llvm-dis -o output.ll input.bc

[0x410c]

this aarch64 hex bytes

remill-lift-14 -arch aarch64 --ir_out ./func1.ir --bytes FF0301D1E00F00F9E10B00F9E20700F9E00F40F9E01F00F9E00B40F9E01B00F9E00740F91F1C00F109070054E11F40F9E01B40F9200000AA000840921F0000F141060054E01F40F9E01700F9E01B40F9E01300F910000014E01740F9010040F9E01340F9000040F93F0000EBC1010054E01740F900200091E01700F9E01340F900200091E01300F9E00740F9002000D1E00700F9E00740F91F1C00F1E8FDFF54020000141F2003D5E01740F9E01F00F9E01340F9E01B00F914000014E01F40F901004039E01B40F9000040393F00006B00010054E01F40F900004039E103002AE01B40F9000040392000004B0D000014E01F40F900040091E01F00F9E01B40F900040091E01B00F9E00740F9010400D1E10700F91F0000F121FDFF5400008052FF030191C0035FD6

[0x410c]

user@user-virtual-machine:~/magnifier$ remill-lift-14 -arch aarch64 --ir_out ./func1.ir --bytes FF0301D1E00F00F9E10B00F9E20700F9E00F40F9E01F00F9E00B40F9E01B00F9E00740F91F1C00F109070054E11F40F9E01B40F9200000AA000840921F0000F141060054E01F40F9E01700F9E01B40F9E01300F910000014E01740F9010040F9E01340F9000040F93F0000EBC1010054E01740F900200091E01700F9E01340F900200091E01300F9E00740F9002000D1E00700F9E00740F91F1C00F1E8FDFF54020000141F2003D5E01740F9E01F00F9E01340F9E01B00F914000014E01F40F901004039E01B40F9000040393F00006B00010054E01F40F900004039E103002AE01B40F9000040392000004B0D000014E01F40F900040091E01F00F9E01B40F900040091E01B00F9E00740F9010400D1E10700F91F0000F121FDFF5400008052FF030191C0035FD6
user@user-virtual-machine:~/magnifier$ remill-lift-14 -arch aarch64 --bc_out ./func1.bc --bytes FF0301D1E00F00F9E10B00F9E20700F9E00F40F9E01F00F9E00B40F9E01B00F9E00740F91F1C00F109070054E11F40F9E01B40F9200000AA000840921F0000F141060054E01F40F9E01700F9E01B40F9E01300F910000014E01740F9010040F9E01340F9000040F93F0000EBC1010054E01740F900200091E01700F9E01340F900200091E01300F9E00740F9002000D1E00700F9E00740F91F1C00F1E8FDFF54020000141F2003D5E01740F9E01F00F9E01340F9E01B00F914000014E01F40F901004039E01B40F9000040393F00006B00010054E01F40F900004039E103002AE01B40F9000040392000004B0D000014E01F40F900040091E01F00F9E01B40F900040091E01B00F9E00740F9010400D1E10700F91F0000F121FDFF5400008052FF030191C0035FD6
user@user-virtual-machine:~/magnifier$ rellic-decomp --input func1.bc --output func.c
F20230510 19:42:37.049466 17869 ASTBuilder.cpp:158] Check failed: val.getBitWidth() == ctx.getIntWidth(type) (128 vs. 64) 
*** Check failure stack trace: ***
    @           0x5dd39c  google::LogMessageFatal::~LogMessageFatal()
    @           0x5c3501  rellic::ASTBuilder::CreateIntLit()
    @           0x5c3557  rellic::ASTBuilder::CreateAdjustedIntLit()
    @           0x4c60f0  rellic::ASTBuilder::CreateAdjustedIntLit()
    @           0x4be532  rellic::ExprGen::CreateLiteralExpr()
    @           0x4bec55  rellic::ExprGen::CreateOperandExpr()
    @           0x4c1beb  rellic::ExprGen::visitBinaryOperator()
    @           0x4c378d  rellic::StmtGen::visitInstruction()
    @           0x4c3d1b  rellic::IRToASTVisitor::VisitBasicBlock()
    @           0x4afe60  rellic::GenerateAST::CreateRegionStmts()
    @           0x4b0f07  rellic::GenerateAST::StructureCyclicRegion()
    @           0x4b33d7  rellic::GenerateAST::StructureRegion()
    @           0x4b4cbc  std::_Function_handler<>::_M_invoke()
    @           0x4b4ca8  std::_Function_handler<>::_M_invoke()
    @           0x4b4ca8  std::_Function_handler<>::_M_invoke()
    @           0x4b383a  rellic::GenerateAST::run()
    @           0x4bbf4d  llvm::detail::PassModel<>::run()
    @          0x2ef5c91  llvm::PassManager<>::run()
    @           0x4b4832  rellic::GenerateAST::run()
    @           0x436014  rellic::Decompile()
    @           0x42b243  main
    @     0x7ffbd8429d90  (unknown)
    @     0x7ffbd8429e40  __libc_start_main
    @           0x42a77e  _start
    @              (nil)  (unknown)
Aborted (core dumped)

[frabert]

Could you provide the result of remill-lift-14, i.e. func1.ir? Thanks!

[0x410c]

sure here func1.txt

[frabert]

Pretty much as I suspected. While I can fix Rellic to produce a wide enough type, it's not standard C and Clang doesn't know how to print it, so it'll need a bit more work.

In the meantime, as a workaround, I can suggest finding or writing an LLVM pass that would turn 128bit-wide values and operations into two 64bits ops. Not sure if something like this already exists, but it's pretty likely.

[0x410c]

where i can find one if you can point to somewhere?

[0x410c]

is there a way to do it through remill?

[frabert]

The list of generally available LLVM passes is here https://www.llvm.org/docs/Passes.html

I can't really answer for if Remill can do something about this -- that's best asked in Remill's repository

[pgoodman]

Do you know if it's representable as 64 bits? One possibility could be a 64-bit literal, upcasted to a 128-bit type.

[frabert]

Just tried it, some of the values have more significant bits than available in a long long

[pgoodman]

Next question: are those significant bits all 1 :-P Worst case, you could decompose into two 64-bit literals, then upcast, and merge into the final literal via a shift and bitwise or.

[frabert]

That seems to work, I have a branch with that fix in it: https://github.com/lifting-bits/rellic/pull/323

[frabert]

Upgrading to LLVM16 might fix the printing issue, so I think we should wait until that is done before proceeding with a longterm fix

[frabert]

Fixed by #323