\n\nThis page has been machine-translated from the original page.
\n
The other day, I wrote an article on creating and analyzing ClamAV bytecode signatures using the SECCON 2022 challenge Devil Hunter as the theme.
\nReference: Learning ClamAV Signature Creation and Analysis Through a CTF
\nI did not cover it in that article, but there is also a brilliant analysis technique for bytecode signatures: patching libclamav so you can trace the bytecode being executed.
\nReference: hxp | SECCON CTF 2022 Quals
\nIn this article, I summarize a method for analyzing how bytecode signatures work by patching libclamav, based on the write-up above.
\nNote that when patching libclamav, you need to build ClamAV yourself from source.
\nI summarized how to build ClamAV in the following article.
\nReference: Notes on Building ClamAV from Source and Setting Up OnAccessScan
\n\nTo use this technique, modify the line DEFINE_ICMPOP(OP_BC_ICMP_EQ, res = (op0 == op1)); in bytecode_vm.c in libclamav as follows.
// DEFINE_ICMPOP(OP_BC_ICMP_EQ, res = (op0 == op1));\nDEFINE_ICMPOP(OP_BC_ICMP_EQ, printf(\"%d: %x == %x\\n\", bb_inst, op0, op1);res = (op0 == op1));This change lets you dump the two values being compared when OP_BC_ICMP_EQ is called.
Let’s actually run a scan with clamscan in an environment where this change has been applied.
The following is the result when scanning a fake Flag.
\nThe following is the result when scanning the correct Flag.
\nHowever, as you can see from the following code, the trace output available through cli_byteinst_describe expresses operands as variables, just like the output disassembled with the clambc command, so you cannot see the actual values.
void cli_byteinst_describe(const struct cli_bc_inst *inst, unsigned *bbnum)\n{\n size_t j;\n char inst_str[256];\n const struct cli_apicall *api;\n\n if (inst->opcode > OP_BC_INVALID) {\n printf(\"opcode %u[%u] of type %u is not implemented yet!\",\n inst->opcode, inst->interp_op / 5, inst->interp_op % 5);\n return;\n }\n\n snprintf(inst_str, sizeof(inst_str), \"%-20s[%-3d/%3d/%3d]\", bc_opstr[inst->opcode],\n inst->opcode, inst->interp_op, inst->interp_op % inst->opcode);\n printf(\"%-35s\", inst_str);\n switch (inst->opcode) {\n // binary operations\n case OP_BC_ADD:\n printf(\"%d = %d + %d\", inst->dest, inst->u.binop[0], inst->u.binop[1]);\n break;\n case OP_BC_SUB:\n printf(\"%d = %d - %d\", inst->dest, inst->u.binop[0], inst->u.binop[1]);\n break;\n case OP_BC_MUL:\n printf(\"%d = %d * %d\", inst->dest, inst->u.binop[0], inst->u.binop[1]);\n break; \n***Reference: clamav/libclamav/bytecode.c at main · Cisco-Talos/clamav
\nSo, in addition to TRACE_INST, I modified the libclamav code so that the debug output from TRACE_PTR, TRACE_R, TRACE_W, TRACE_EXEC, and TRACE_API is written to standard output.
// #define TRACE_PTR(ptr, s) cli_dbgmsg(\"bytecode trace: ptr %llx, +%x\\n\", ptr, s);\n// #define TRACE_R(x) cli_dbgmsg(\"bytecode trace: %u, read %llx\\n\", pc, (long long)x);\n// #define TRACE_W(x, w, p) cli_dbgmsg(\"bytecode trace: %u, write%d @%u %llx\\n\", pc, p, w, (long long)(x));\n// #define TRACE_EXEC(id, dest, ty, stack) cli_dbgmsg(\"bytecode trace: executing %d, -> %u (%u); %u\\n\", id, dest, ty, stack)\n\n#define TRACE_PTR(ptr, s) printf(\"ptr %llx, +%x\\n\", ptr, s);\n#define TRACE_R(x) printf(\"%u, read %llx\\n\", pc, (long long)x);\n#define TRACE_W(x, w, p) printf(\"%u, write%d @%u %llx\\n\", pc, p, w, (long long)(x));\n#define TRACE_EXEC(id, dest, ty, stack) printf(\"bytecode trace: executing %d, -> %u (%u); %u\\n\", id, dest, ty, stack)\n\n#define TRACE_INST(inst) \\\n do { \\\n unsigned bbnum = 0; \\\n printf(\"\"); \\\n cli_byteinst_describe(inst, &bbnum); \\\n printf(\"\\n\"); \\\n } while (0)\n\n// #define TRACE_API(s, dest, ty, stack) cli_dbgmsg(\"bytecode trace: executing %s, -> %u (%u); %u\\n\", s, dest, ty, stack)\n#define TRACE_API(s, dest, ty, stack) printf(\"bytecode trace: executing %s, -> %u (%u); %u\\n\", s, dest, ty, stack)Reference: clamav/libclamav/bytecode_vm.c at patch-libclamav · kash1064/clamav
\nWith this change enabled, you can trace memory reads and writes as shown below.
\nAs you can see from the output above, information about memory reads and writes is printed immediately after the traced instruction.
\nFor example, in the following part, v640 and v1240 each read 0x6cbfdd9f, compare them with OP_BC_ICMP_EQ, and store the result (1) at @644.
OP_BC_ICMP_EQ [21 /108/ 3] 644 = (640 == 1240)\n1444, read 6cbfdd9f\n1444, read 6cbfdd9f\n1444, write8 @644 1Also, in the following part, you can confirm that the 4-character integer value 0x33547962 (3Tyb) is read from the p.248 pointer, written to v256, and then passed in a function call as the argument to Func2.
OP_BC_LOAD [39 /198/ 3] load 256 <- p.248\n530, read fffffffe00000019\nptr fffffffe00000019, +4\n530, read 617f7db2ab69\n530, write32 @256 33547962\n\nOP_BC_CALL_DIRECT [32 /163/ 3] 260 = call F.2 (256)\nbytecode trace: executing 2, -> 260 (32); 2In this way, by enabling debug tracing, you can easily determine—without having to struggle through disassembled code like in the previous article—that the Flag text is split into 4-character chunks and passed to Func2 as 32-bit integer values.
The debug tracing was extremely useful.
\nIf another bytecode signature challenge comes up in the future, I feel like I’ll be able to solve it without too much trouble.
","fields":{"slug":"/clamav-debug-signature-libclamav-en","tagSlugs":["/tag/clam-av/","/tag/malware/","/tag/english/"]},"frontmatter":{"date":"2024-08-19","description":"This article summarizes how to enable debug tracing for bytecode signatures in libclamav.","tags":["ClamAV","Malware","English"],"title":"How to Enable Debug Tracing for Bytecode Signatures in libclamav","socialImage":{"publicURL":"/static/677321ee47cda9d6640b819d3190fe11/clamav-debug-signature-libclamav.png"}}}},"pageContext":{"slug":"/clamav-debug-signature-libclamav-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}