3 ms·
ARM thumb disassembly: 00: 11 38 subs r0, #0x11 02: C0 7A ldrb r0, [r0, #0xb] 04: 00 BD pop {pc} 06: 00 B5
by Retr0id 5y ago
ARM thumb disassembly:
00: 11 38 subs r0, #0x11
02: C0 7A ldrb r0, [r0, #0xb]
04: 00 BD pop {pc}
06: 00 B5 push {lr}
08: 42 40 eors r2, r0
0a: 00 2A cmp r2, #0
0c: 00 F0 02 F8 bl #0x14
10: F6 D2 bhs #0
12: 8E 46 mov lr, r1
14: 70 46 mov r0, lr
16: 00 47 bx r0
Edit: I agree with the other commenters that this doesn't really look like a valid disassembly, it is perhaps data rather than code.
Edit2: I take that back - it's just very "creatively" written.
- mmastrac 5y agoThis reads a bit like a spurious decompilation. It's sorta valid but doing very weird things. Random bytes will often decompile to valid Thumb that looks sort of right like this all the time. 04 pop {pc} -> this is an odd way to return from a function on ARM, and likely means that these first bytes would be a very odd function. 06 push {lr} -> OK, maybe a valid prologue, but this function ignores the result of the cmp and calls 0x14.
- TuxSH 5y agopop {..., pc} is THE standard way to return from a function that calls other functions itself, on Armv5 and above. Non tail functions usually do this: push {..., lr} ... pop {..., pc}
- mmastrac 5y agoOnly if there's a corresponding push { ..., lr }, but in this case there isn't. I'd expect bx lr here.
- TuxSH 5y agoAs other people are saying, code seems to be jumped at at #6. > I'd expect bx lr here LR is being clobbered by the bl (EDIT: bl, not blx)
- mmastrac 5y ago> As other people are saying, code seems to be jumped at at #6. Well yeah, that's what I said above. > LR is being clobbered by the blx There's no blx in the first section. These first six bytes would only make sense if this small stub ended in bx lr, therefore I don't think it's a valid function.
- TuxSH 5y agoNormally you'd save more than just PC as AAPCS (https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aap...) mandates stack to be aligned to 8 bytes for "public interface" functions. But this is is not a "public" function so it's fine to only save lr here. "bx lr" is only used on it's own when the function doesn't call another function (altering lr), and doesn't need to save any registers. If you see pop {lr}; bx lr then that's code that's being compiled to explicitly support Armv4 (e.g. Arm7TDMI) EDIT: https://gcc.godbolt.org/z/TadnqescT https://gcc.godbolt.org/z/TadnqescT
- nynyny7 5y agoThis makes a bit of sense when the actual entry point is at 06: 00 B5 push {lr} However, even then, the code appears unnecessarily convoluted. Easter egg? Back door ;-)?
- TuxSH 5y ago// r0 = arg1, r1 = arg2, r2 = arg3 if (arg3 ^ arg1 >= 0u) return 42; // edited //*(u8 *)(r0 - 17 + 11); else // dead code (edited) return arg2();