Log in

View Full Version : Real LDE.

Indy
October 15th, 2011, 13:27
(Length Disassembler Engine).

Determining the length of instructions the processor means. For example the opcode 0xFF0F(0F FF) - has ModR/M byte:
0F FF 05 DISP32 - 7 byte's.

2505

http://indy-vx.narod.ru/Bin/LDE.zip ("http://indy-vx.narod.ru/Bin/LDE.zip")
http://rootkits.su/topic,60.15.html ("http://rootkits.su/topic,60.15.html")
evlncrn8
October 15th, 2011, 18:35
Whats the "real" part in the name for?
I saw some years ago, z0mbies in particular..i think theres a decent one with beaengine too. also for x64... they are quite useful things, wrote my own years ago and discovered how crazy intels encoding is, with exceptions to the 'rules' etc... Fun times
bluebyrd
October 15th, 2011, 19:13
Quote:
[Originally Posted by evlncrn8;91224]Fun times

Pros start having fun when normal people start getting pissed off. It's the attitude that makes a great reverser.
Indy
October 16th, 2011, 00:21
It determines the actual length, even for non-existent instructions. No tables, run the instruction on a page boundary. Even the privileged.

Other engines use a opcode tables. This makes it impossible to determine the lengths of instructions that are in the tables are not described. For the kernel this engine is unnecessary, there should just handle faults, without adjustment Ss/Esp

To write to a different platform(eg. x64), no need composes new tables.

As example, determine(bea, z0mbie etc) the size 0F FF 05 =)
evlncrn8
October 16th, 2011, 05:08
Hmm interesting, will have to check it out when i have a bit of time (probably monday).. totally agree about the tables etc... Damn wish i had time now, your post really got me curious now indy :-)
Indy
October 16th, 2011, 10:19
epic fail не ?
evlncrn8
October 16th, 2011, 19:58
Hmm am i wrong or is it using tracing and seh to obtain the length..ie : executing the line (with some intelligence in its checking).. ? kinda dangerous if the opcode is unknown but can be dangerous...no?

Not sure what you meant by fail though...
Indy
October 17th, 2011, 13:00
The code is not dangerous, opcode does not matter. Code is reduced to the correction because of bugs in the kernel.

The problem with seh is only one - NX. Solved as follows: http://www.woodmann.com/forum/showthread.php?14007-PoC-Hiding-the-caller.&daysprune=365 ("http://www.woodmann.com/forum/showthread.php?14007-PoC-Hiding-the-caller.&daysprune=365")
evlncrn8
October 18th, 2011, 14:08
my meaning for dangerous was simply that executing 'unknown' code can be dangerous (eg: sigt instruction that can run in ring 3 with a little help from a ring 0 driver) etc...

its two approaches. passive (tables) or non passive (tracing) etc....
im just a pacifist heh
Indy
October 18th, 2011, 23:14
evlncrn8
sidt fword ptr ss:[esp + eax + 0x100]
0F 01 8C 04 00 01 00 00, returns 8
sgdt fword ptr ds:[edi + esi - 1]
0F 01 44 37 FF, returns 5.

Tracing is used to control the successful execution of instructions.

Quote:
executing 'unknown' code can be dangerous

Really ?
Code:
	mov Seed,2

Next:

	lea edi,Buffer

	lea ebx,[esi + MAX_INSTRUCTION_LENGTH]

	.repeat

		invoke RtlRandom, addr Seed

		mov eax,Seed

		stosd

	.until Edi >= Ebx

	inc Iters

	invoke LDE, RegionBase, Esi


Give an example of dangerous code.
Indy
October 24th, 2011, 00:55
0F 50 E0 movmskps esp,xmm0 - dangerous instruction.