This 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.
pop {..., 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}
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.
Normally you'd save more than just PC as AAPCS (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)
Comments
ARM thumb disassembly:
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.
This 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.
pop {..., 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}
Only if there's a corresponding push { ..., lr }, but in this case there isn't. I'd expect bx lr here.
As other people are saying, code seems to be jumped at at #6.
LR is being clobbered by the bl (EDIT: bl, not blx)
Well yeah, that's what I said above.
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.
Normally you'd save more than just PC as AAPCS (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
[deleted]
https://www.keil.com/support/man/docs/armasm/armasm_dom13612...
Doesn't seem like much of an assumption to me :P
This makes a bit of sense when the actual entry point is at
However, even then, the code appears unnecessarily convoluted. Easter egg? Back door ;-)?