flat assembler
Message board for the users of flat assembler.

Index > Windows > strange code in KERNELBASE

Author
Thread Post new topic Reply to topic
tthsqe



Joined: 20 May 2009
Posts: 730
tthsqe
I was just playing around and I stumbled upon the following code near the end of the function
Code:
KERNELBASE.LoadLibraryExA    


I am talking about the two seemingly useless jumps starting at the highlighted instruction.
Any comments on this? What could this possibly do that a nop could not do?


Description:
Filesize: 27.86 KB
Viewed: 2197 Time(s)

strangekernelbasecode.png


Post 17 May 2013, 13:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
tthsqe wrote:
What could [the two seemingly useless jumps] possibly do that a nop could not do?
Take up two less lines in a disassembly window? Flush the prefetch buffer? Make a debugging session slower because people waste time wondering about such things rather than concentrating on the task at hand? Legacy code from aeons ago? Erm ... or perhaps nothing?

I give in. What is the answer? Wink
Post 17 May 2013, 14:09
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 20:31; edited 1 time in total
Post 17 May 2013, 15:11
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 730
tthsqe
Incorrect disassembled code?
- no, it is disassembled correctly
Compiler generated code?
- I'm sure that is the case, but neither of the jumps is the target of another jump in the function, so they probably didn't come from an empty basic block of instructions
Take up two less lines in a disassembly window?
- 66 66 66 90 only takes up only one line and does the same thing
- plus, if the goal is alignment, this is a fairly poor choice given the proceeding code
Flush the prefetch buffer?
- This is interesting - so unconditional jumps may flush the (instruction) prefetch buffer?
Make a debugging session slower because people waste time wondering about such things rather than concentrating on the task at hand? Legacy code from aeons ago? Erm ... or perhaps nothing?
- This is too pragmatic - what if the goal is understanding?

kernelbase.dll is littered with such examples, here is another
Code:
TerminateThread:
...
je  A
...
jmp A
nop
A:
jmp B
nop
B:
...
jmp (to the epilog of LocalFree)    

This kind of code was written either my a machine or by a human, and it was written for a reason. I was just hoping someone here at this board had a good explanation of why such nonsense exists in my copy of windows...
Post 18 May 2013, 16:38
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 20:30; edited 1 time in total
Post 18 May 2013, 16:52
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 730
tthsqe
Well, compilers do have a difficult task to perform, and sometimes the results of applying some algorithm A look strange to us because another algorithm B gives better results.

Certainly the compiler is not programmed like:
Code:
if get_random_integer() < nonsense_threshold 
{
waste a bunch of time and space
}    


I hope you will not conclude that this thread is the same waste.
Post 18 May 2013, 17:04
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 20:30; edited 1 time in total
Post 18 May 2013, 17:31
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1419
Location: Toronto, Canada
AsmGuru62
Maybe this code will be patched at run-time?
If it will be patched with one (shorter) byte sequence -- code will jump to one location.
When patched with sequence #2 (longer) -- then jump to a different location.
Of course, patching may happen on some condition, so you are not seeing it while stepping in debugger at the moment.

Windows likes to do the "hot" patching.
Post 19 May 2013, 11:08
View user's profile Send private message Send e-mail Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 730
tthsqe
Good answer, these useless instructions do make it much easier to divert control, and that is probably what is happening.
But, the code was in a write/execute section only. So, I assume only the kernel can patch it???
Post 31 May 2013, 00:06
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
tthsqe wrote:
But, the code was in a write/execute section only. So, I assume only the kernel can patch it???

VirtualProtect, WriteProcessMemory... global patching is trickier, though.

_________________
Image - carpe noctem
Post 01 Jun 2013, 15:13
View user's profile Send private message Visit poster's website Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
Going just by the screen shot, my guess is that since "lock xadd" can only be done in asm this has either interrupted the normal optimisation of the nested ifs or is the result of inline linking Question
Post 01 Jun 2013, 20:06
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
cod3b453 wrote:
Going just by the screen shot, my guess is that since "lock xadd" can only be done in asm this has either interrupted the normal optimisation of the nested ifs or is the result of inline linking Question
It can be even LTCG-involved result. There are many kludges (like __declspec(thread)) in Visual C, probably only its programmers know what it's doing. Wink
Post 01 Jun 2013, 22:41
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.