I asked this question a month ago on various forums (including here) and as I got no response I'm asking it again. Any minimum help will be very welcome.
Is there some kind of code optimization or specific case where the compiler generates indirect branch instructions (except for the RET instructions) that point to the MIDDLE of ANOTHER function code (instead of the entry point)?
Thank you very much for your time and attention.
>>that point to the MIDDLE of ANOTHER function code (instead of the entry point)?
"instead of the entry point" somewhat implies you are talking about a function call (or inlined piece of code for function).
Barring dispatch table corruption, code segment modification for bad user code, and small posibility for bad code generation; depending on compile time options, the compiler may generate multiple code paths (e.g. FPU, SSE or AVX paths). When a code path is determined and taken and the call is made to a multi-code path function from within a known code path of a caller, then the compiler could (in some cases) bypass the code path test and enter at an alternative entry point. Source level debugging should not see this occuring (assembly level would).
If, on the other hand, you perform a Step Into, and you end up in the middle of the desired function or unrelated function, then this is indicative of: address vector table corruption, vtable corruption, code corruption, a functor. If this situation is repeatable, then this would be a good time to use the Dissassembly window. Break at call, determine how the call is performed, determine the address of the component generating the address to call (this would be the location within an address vector table, a location within a vtable, the location of the imm portion of the instruction, or the address of and contents of the functor). Inspection will likely identify the address of a corrupted value (i.e. when the call is performed, a corrupted value is used to calculate the address of the call). Now the task is to repeat the debug session with a break point earlier in the code, hopefully to a spot prior to the corruption (but after any initialization such as the case for vtable or functor). Note, you may not necessarily know the value is correct but will observe it is different. Knowing what address gets corrupted, you would then enter that address in the data break debug break point. Then let the program run to the break point you have set at the errant call. Something may show up.
Hello Sergey Kostrov and Jim Dempsey.
Thank you for your answers. Sorry for taking too long to write, but this forum had a bug and because of it I was not able to post any comments. As you see, now the problem was solved!
I'm a Master's student and I'm working on protections against a code execution technique named Return-oriented Programming (ROP). Some proposed protections assume that all the branches to other functions occurs on their entry points. I wonder if there are especial cases where it is not always true. If you know other cases or can indicate some reference that explains any pointed case I would apreciate.
I found a similar question made by a colleague who found an occurrence when he was reverse engineering the playstation 1 (MIPS). See:
Thank you again.
Iliyapolak, despite the motivation of my question is my project with protections against ROP attacks, I believe the question is directly related to the topic of compilers and therefore is relevant to this forum. Thanks for the link indication. Actually, I already knew this proposed protection against ROP attacks.
Sergey Kostrov, I thank you for your interest and willingness to help me. Your contribution has been important. I have not found any examples of this type of code in assembly but I imagine they must exist and that's why I asked the question here in this forum. Until now, the only reference to this type of situation I've found was that presented in the link I've posted (playstation 1 and the MIPS architecture). Regarding the usefulness of this information for my job, it can be used to refute other protections against ROP proposed in the literature and thus justify the need for preparation of the solution in which I am working.
Thanks again for all the comments.