### yet another reversing activity imhex op `flag.yarc` is basically a compiled yara rule, which https://bnbdr.github.io/posts/swisscheese/ actually details the format pretty well as a part of a vuln writeup - but too bad this version is very outdated and a lot of the things changed already so into yara's repo we go https://github.com/VirusTotal/yara/blob/666d5a4fd61df57d261d387676f7bd98544337a3/libyara/arena.c now since we dont have this current format laid out by ppl for us to understand we would have to basically map the parser type definitions to something that we can visualize and whats better than writing an hex pattern template turns out imhex is actually insanely flexible LOL i finally have a reason to drop 010 editor now ```c #define uint8_t u8 #define uint16_t u16 #define uint32_t u32 #define uint64_t u64 #define yr_arena_off_t u32 #include struct YR_ARENA_FILE_HEADER { char magic[4]; uint8_t version; uint8_t num_buffers; }; struct YR_ARENA_FILE_BUFFER { uint64_t offset; uint32_t size; char arena[size] @ offset; }; struct YR_ARENA_REF { uint32_t buffer_id; yr_arena_off_t offset; }; YR_ARENA_FILE_HEADER header @ 0x00; YR_ARENA_FILE_BUFFER buffers[header.num_buffers] @ 0x06; u32 size; for(u8 i = 0, i < header.num_buffers, i+=1) { size = size + sizeof(YR_ARENA_REF) + buffers[i].size; }; YR_ARENA_REF reloc[header.num_buffers] @ size; ``` while [@Arctic](https://maplebacon.org/authors/rctcwyvrn/) was busy updating the opcodes from https://github.com/bnbdr/swisscheese/blob/master/assembler.py i was doing what i do the best again: pattern identification none of the arenas seem to have anything special, aside from one that looks suspiciously orderly as if its a flag checker, which with some formatting we can lay it out like this: ```text 00 F0 3C 5F 3C 39 07 64 2F 0F 00 00 00 3C 01 F0 3C 33 3C 5F 07 64 01 2F 0F 00 00 00 3C 02 F0 3C F8 3C 99 07 64 01 2F 0F 00 00 00 3C 03 F0 3C 53 3C 34 07 64 01 2F 0F 00 00 00 3C 04 F0 3C F8 3C 83 07 64 01 2F 0F 00 00 00 3C 05 F0 3C 9A 3C F7 07 64 01 2F 0F 00 00 00 3C 06 F0 3C DD 3C EE 07 64 01 2F 0F 00 00 00 3C 07 F0 3C 5C 3C 6F 07 64 01 2F 0F 00 00 00 3C 08 F0 3C F9 3C 8D 07 64 01 2F 0F 00 00 00 3C 09 F0 3C F9 3C A6 07 64 01 2F 0F 00 00 00 3C 0A F0 3C C8 3C A5 07 64 01 2F 0F 00 00 00 3C 0B F0 3C 80 3C E5 07 64 01 2F 0F 00 00 00 3C 0C F0 3C 86 3C D9 07 64 01 2F 0F 00 00 00 3C 0D F0 3C 0D 3C 3C 07 64 01 2F 0F 00 00 00 3C 0E F0 3C 65 3C 0B 07 64 01 2F 0F 00 00 00 3C 0F F0 3C 77 3C 28 07 64 01 2F 0F 00 00 00 3C 10 F0 3C 8F 3C B8 07 64 01 2F 0F 00 00 00 3C 11 F0 3C 80 3C E8 07 64 01 2F 0F 00 00 00 3C 12 F0 3C AA 3C 99 07 64 01 2F 0F 00 00 00 3C 13 F0 3C 28 3C 77 07 64 01 2F 0F 00 00 00 3C 14 F0 3C 69 3C 08 07 64 01 2F 0F 00 00 00 3C 15 F0 3C 56 3C 24 07 64 01 2F 0F 00 00 00 3C 16 F0 3C A1 3C 92 07 64 01 2F 0F 00 00 00 3C 17 F0 3C 2A 3C 44 07 64 01 2F 0F 00 00 00 3C 18 F0 3C EC 3C D8 07 64 01 2F 0F 00 00 00 3C 19 F0 3C EA 3C 97 07 64 01 1D 00 00 00 00 00 00 00 00 FF ``` and we can see that basically aside from the first byte which is likely a counter, and the 2 bytes in the 2 rows after that byte would change, all other ones are basically static so i started reading the current opcode map to see what operation might be acting on those 2 specific bytes and aha `#define OP_BITWISE_XOR 7` so i tried it out and with ```py print(bytes([0x5F^0x39, 0x33^0x5F, 0xF8^0x99, 0x53^0x34, 0xF8^0x83, 0x9A^0xF7, 0xDD^0xEE, 0x5C^0x6F, 0xF9^0x8D, 0xF9^0xA6, 0xC8^0xA5, 0x80^0xE5, 0x86^0xD9, 0x0D^0x3C, 0x65^0x0B, 0x77^0x28, 0x8F^0xB8, 0x80^0xE8, 0xAA^0x99, 0x28^0x77, 0x69^0x08, 0x56^0x24, 0xA1^0x92, 0x2A^0x44, 0xEC^0xD8, 0xEA^0x97])) ``` i was correct and we get the flag `flag{m33t_me_1n_7h3_ar3n4}` lmaooo i love just recognizing patterns instead of reversing