Indirect branch to the middle of a function?

Indirect branch to the middle of a function?

Hello everybody.

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.

Kind regards,

Mateus.

9 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

>>...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)?

Manual application of a such technique ( possibly ) could be done in assembler language. However, I can't imaging how it could be done for a method of a C++ template class. What about a stack, exceptions handling, RTTI, etc?

>>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.

Jim Dempsey

www.quickthreadprogramming.com

>>...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)?..

Mateus,

Could you provide additional information on why that subject is so interested for you? Are there any practical applications of this or you're experiencing a problem with Intel C++ compiler?

Thanks in advance.

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:

http://www.newswebreader.com/gnu.gcc.help/jal-to-the-middle-of-another-f...

Thank you again.

Greetings,

Mateus.

>>...Some proposed protections assume that all the branches to other functions occurs on their entry points...

You understand that instead of a set of calls to some functions forced inlining of these functions could be used. Have you seen assembler codes for such cases? What are you going to do in that case?

>>>'m a Master's student and I'm working on protections against a code execution technique named Return-oriented Programming (ROP).>>>

This is not proper forum for ROP question.You can ask this on OpenRCE forum.
Please follow this link:http://innovation.columbia.edu/technologies/cu12079/computer-protection-...

Please read:

>>>>...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...

There is nothing wrong here because the question is really interesting and I regret that I can not provide more help.

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.

Greetings,

Mateus.

Melden Sie sich an, um einen Kommentar zu hinterlassen.