2

I'm using radare2 to deconstruct a binary blob. When defining bit-field value there seems to be no syntax to specify the width of the field that contains the enum. For instance with a C structure as follows :

struct mystruct{
   uint32_t myint,
   uint8_t bitfield1,
   uint8_t bitfield2,
   uint8_t bitfield3,
   uint8_t bitfield4
}

I would declare the following :

"td enum byte_enum {bit_8=0x80, bit_7=0x40,bit_6=0x20,bit_5=0x10, bit_4=0x08,bit_3=0x04,bit_2=0x02,bit_1=0x01}"
pf.binary xBBBB myint (byte_enum)bitfield1 (byte_enum)bitfield2 (byte_enum)bitfield3 (byte_enum)bitfield4

but each byte gets interpreted as a full 32 bits int (although the offsets only get incremented by 1, which is bewildering me)

[0x00000000]> px 16
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  4142 4344 3132 3334 0aff ffff ffff ffff  ABCD1234........
[0x00000000]> pf.binary
     myint : 0x00000000 = 0x44434241
 bitfield1 : 0x00000004 =  bitfield1 (bitfield) = 0x34333231 : bit_1 | bit_5 | bit_6 | 0x200 | 0x1000 | 0x2000 | 0x10000 | 0x20000 | 0x100000 | 0x200000 | 0x4000000 | 0x10000000 | 0x20000000
 bitfield2 : 0x00000005 =  bitfield2 (bitfield) = 0x0a343332 : bit_2 | bit_5 | bit_6 | 0x100 | 0x200 | 0x1000 | 0x2000 | 0x40000 | 0x100000 | 0x200000 | 0x2000000 | 0x8000000
 bitfield3 : 0x00000006 =  bitfield3 (bitfield) = 0xff0a3433 : bit_1 | bit_2 | bit_5 | bit_6 | 0x400 | 0x1000 | 0x2000 | 0x20000 | 0x80000 | 0x1000000 | 0x2000000 | 0x4000000 | 0x8000000 | 0x10000000 | 0x20000000 | 0x40000000 | 0x80000000
 bitfield4 : 0x00000007 =  bitfield4 (bitfield) = 0xffff0a34 : bit_3 | bit_5 | bit_6 | 0x200 | 0x800 | 0x10000 | 0x20000 | 0x40000 | 0x80000 | 0x100000 | 0x200000 | 0x400000 | 0x800000 | 0x1000000 | 0x2000000 | 0x4000000 | 0x8000000 | 0x10000000 | 0x20000000

I tried the [1]B syntax but radare2 does not take the right byte, it just truncates the 4-byte value to LSB, which happens to be 3 bytes down if you use big endian (like I do). This may be a bug.

  • have you tried reporting this to r2 devs? not sure what we can do here... – Igor Skochinsky Oct 6 '17 at 9:13
  • Yes, I think this is a bug in r2. I reported it a such. I suppose this can be closed down. – takumar Oct 7 '17 at 17:56
  • @takumar, any news about the issue you've reported? If the issue isn't solved yet, please share link to the Github issue you've reported. – Megabeets Jan 11 '18 at 13:28
  • This was filed as issue #8589. I don't know the status of it since I had apparently little success in pushing the associated test case to get merged. – takumar Jan 12 '18 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.