WorksButNotTested
WorksButNotTested
This is our next problem block: 0xf7d291f0: ldr r3, [r6, #52] ; 0x34 0xf7d291f2: cmp r3, r5 0xf7d291f4: ittte ne 0xf7d291f6: movne r3, #1 0xf7d291f8: strne.w r3, [r0, #256] ;...
Stalker fails to carry out the post-increment. 0x5d, 0xf8, 0x04, 0xfb, /* ldr pc, [sp], #4 */
The [documentation](https://developer.arm.com/documentation/dui0204/j/arm-and-thumb-instructions/memory-access-instructions/ldm-and-stm) states that: """ In ARM code or pre-Thumb-2 Thumb code, if Rn is in reglist, and writeback is specified with the ! suffix: if the instruction is STM...
The input bytes are: ``` 0xe28fc604 ``` The output it generates is: ``` ldr ip, [pc, #-0] add ip, ip, #4 ``` This results in the LSR not being carried...
The output it generates is: ``` ldr sb, [pc, -#0] add sb, r4, #0 ``` This results in sb being loaded with the value of `r4`, and the value of...
`gum_linux_cpu_type_from_file` uses the constant `G_DATA_STREAM_BYTE_ORDER_LITTLE_ENDIAN` [here](https://github.com/frida/frida-gum/blob/3ac6f1531d5ac350753442cb5840403b301bbb90/gum/backend-linux/gumprocess-linux.c#L1714). Rather than reading the header of the ELF to determine endianness.
It seems that the instruction is interpreted big endian even though the instruction stream is little endian.
This line assumes that the auxv contents are little endian. https://github.com/frida/frida-gum/blob/b22ba0713086e990e20d729db4077bcc64c76f2a/gum/backend-linux/gumprocess-linux.c#L1812 [Documentation](https://man7.org/linux/man-pages/man5/proc.5.html) states that: """ The format is one unsigned long ID plus one unsigned long value for each entry....
When using the following test program started in the background: ``` #include int main (void) { puts ("HELLO"); getchar(); } ``` Frida fails to attach with the following message: ```...