WorksButNotTested

As far as I’m aware I don’t think there’s anything outstanding for me to sort. But @stefan-esser-sg will be the one to judge I guess?

Awesome. Thanks. I’ve not been spending a lot of time on 32 bit arm because it’s not what I’m targeting right now and it’s not as popular. So a few...

I don't have a 32-bit arm target, but on my RPI running ubuntu 20.04, this builds ok for me. `LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib/ ARCH=armhf CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++ make`

Looks like it got fixed here... https://github.com/AFLplusplus/AFLplusplus/commit/a705b1548f903a8cc3f85ec960b5d09a7d7a3ee7

I'd say close it assuming @hexcoder- is happy.

Looks like the last two issues by @hexcoder- have been addressed.

ARM has two big-endian modes which I am aware of: * In ARMBE8 mode, instructions are in little-endian whilst data is in big-endian. * In ARMBE32 mode, instruction and data...

The offending line of code appears to be [here](https://github.com/frida/frida-gum/blob/b9cd693812322e3219c2358f7feec491989a2b18/bindings/gumjs/gumdukinstruction.c#L209). ```c GUMJS_DEFINE_FUNCTION (gumjs_instruction_parse) { GumDukInstruction * module; gpointer target; uint64_t address; const gsize max_instruction_size = 16; cs_insn * insn; module =...

In BE8 mode, recall that the endianness of the code and data is different. The value of *GUM_DEFAULT_CS_ENDIAN* is defined [here](https://github.com/frida/frida-gum/blob/b9cd693812322e3219c2358f7feec491989a2b18/gum/gumdefs.h#L67): ```c #if G_BYTE_ORDER == G_LITTLE_ENDIAN # define GUM_DEFAULT_CS_ENDIAN CS_MODE_LITTLE_ENDIAN...

Rebased version of the missing https://github.com/frida/frida-gum/pull/537