NASM - The Netwide Assembler

NASM Forum => Example Code => Topic started by: S Mahen on August 09, 2013, 11:41:58 PM

Title: Reading GDTR, IDTR and LDTR in real mode
Post by: S Mahen on August 09, 2013, 11:41:58 PM
I'm using Fedora 17 + nasm 2.10.07 for ALPing.

I tried reading GDTR, LDTR and IDTR.
And was successful ???, but in protected mode :-X. (Code Attached)

In the code I checked the mode of processor and found "Protected Mode"

smsw eax
.
.
 ror eax,1                        ;checking PE=1 (Protected) or =0 (Real)
 jc prmode
 disp rmodemsg,rmsg_len
 jmp nxt1

prmode:   disp pmodemsg,pmsg_len


I also tried to switch over back to real mode by ANDing EAX with 0FFFFFFFEh to make PE=0 and then loading back to CR0 using lmsw but not working.

I want to read GDTR, IDTR and LDTR in real mode.

Please help.
Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: Frank Kotler on August 10, 2013, 02:14:22 AM
I can't imagine that any protected mode OS is going to let you do that. Wouldn't be very "protected" if it did!

Best,
Frank

Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: S Mahen on August 13, 2013, 05:26:15 PM
That's true Frank.

But I want to access the registers and that in real mode.

What is the option?
Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: Frank Kotler on August 14, 2013, 02:04:15 PM
Well, boot into real mode. Either dos or a bootsector of your own design. I have no idea if DosBox would work or not. I'm not sure the results would be "interesting" in real mode, but you ought to be able to do it. You'd have to modify your program to use dos or bios interrupts (or write "direct to screen") instead of int 80h, of course. Shouldn't be too difficult.

Best,
Frank

Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: pradnya on August 22, 2013, 05:55:52 AM
hello
    will u please give the code for reading GDTR,LDTR and IDTR in real mode. this will be grate help to me.

Thank....
Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: Bryant Keller on September 03, 2013, 05:27:09 AM
I can't imagine that any protected mode OS is going to let you do that. Wouldn't be very "protected" if it did!

Best,
Frank



As it turns out, protected mode isn't very protected... This is a link I've had in my bookmarks for quite some time. lol

http://www.sudleyplace.com/pmtorm.html
Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: encryptor256 on September 03, 2013, 09:23:21 AM
Hi!

You said switching back to real mode was not possible, but
look at this, looks very promising:

With the release of the 386, protected mode could be exited by loading the segment registers with real mode values, disabling the A20 line and clearing the PE bit in the CR0 register, without the need to perform the initial setup steps required with the 286.

http://en.wikipedia.org/wiki/Protected_mode (http://en.wikipedia.org/wiki/Protected_mode)



From:
http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for (http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for)

Exiting Protected Mode
Code: [Select]
cli
mov eax,cr0
and eax,0ffffffeh
mov cr0,eax
mov ax,data16
mov ds,ax
mov ax,stack16
mov ss,ax
mov sp,1000h ; assuming that stack16 is 1000h bytes in length
mov bx,RealMemoryInterruptTableSavedWithSidt
litd [bx]
sti


.edit0:

Well, sorry, i haven't tested, can't tell you if it works. :)

It should work in Ring-0 access level,
because cli and sti are privileged instructions.


.edit1:

Nice link, Bryant Keller!  8)

Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: Frank Kotler on September 03, 2013, 12:14:17 PM
Great! How's it work on your OS?

Best,
Frank

Title: Re: Reading GDTR, IDTR and LDTR in real mode
Post by: Bryant Keller on September 03, 2013, 11:33:52 PM
encryptor256,

As the link I posted showed, it most definitely is possible. That is from a kernel module or other ring-0 program. You aren't, however, going to write an application to do that. Even if you write a driver to do this, you'll basically have to completely reload the kernel once you want to return back so the default action here would be to just let the system reboot when your driver completes what it's doing in real mode... but if you're going to do that, why not just do what Frank said and boot off of a disk. it's easier and your program will begin execution in a known stable state.