flat assembler
Message board for the users of flat assembler.

Index > DOS > problem with unREAL mode fasm

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 08 Feb 2008, 16:14
I thought the topic is about unREAL mode, how is it related to XP?
Post 08 Feb 2008, 16:14
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4347
Location: Now
edfed 08 Feb 2008, 16:23
cause of IOPL
xp is IOPL.
unreal is not XP
protected is the XP mode.
unreal is the DOS mode for 4G support. but about unreal, it's for dos mode running with 4G memory space.
about fasm, can it be executed on pure real mode?

sorry, i"m the king of offtopic creation.
Post 08 Feb 2008, 16:23
View user's profile Send private message Visit poster's website Reply with quote
DJ Mauretto



Joined: 14 Mar 2007
Posts: 464
Location: Rome,Italy
DJ Mauretto 08 Feb 2008, 16:38
Marijuana you smoke seems good, I want also Rolling Eyes
Post 08 Feb 2008, 16:38
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4047
Location: vpcmpistri
bitRAKE 08 Feb 2008, 16:40
It is fastinating to me that System Management Mode is like unreal mode. Makes me wonder if that is the native state of the CPU and protected mode is the abstraction (ie slower)?
Post 08 Feb 2008, 16:40
View user's profile Send private message Visit poster's website Reply with quote
System86



Joined: 15 Aug 2007
Posts: 77
System86 09 Feb 2008, 02:30
Unreal has the advantage over protected mode that you can directly call DOS/BIOS interrupts from it (without switching back to RM or VM86 mode for every call).
Post 09 Feb 2008, 02:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 09 Feb 2008, 03:36
System86 wrote:
Unreal has the advantage over protected mode that you can directly call DOS/BIOS interrupts from it (without switching back to RM or VM86 mode for every call).
I don't think so. BIOS needs 16bit mode FRM is 32it mode.
Post 09 Feb 2008, 03:36
View user's profile Send private message Visit poster's website Reply with quote
System86



Joined: 15 Aug 2007
Posts: 77
System86 09 Feb 2008, 18:54
Quote:


I don't think so. BIOS needs 16bit mode FRM is 32it mode.


Ok, maybe not the 32-bit unreal mode that fasm uses, but plain FRM (16-bit code, with 4 GB segment limits) is compatible with DOS/BIOS, I made a FRM program and it did not need to thunk back to true real mode for every DOS call.
Post 09 Feb 2008, 18:54
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4047
Location: vpcmpistri
bitRAKE 09 Feb 2008, 22:45
http://en.wikipedia.org/wiki/System_Management_Mode

http://www.rcollins.org/ddj/Jan97/Jan97.html
Quote:
After the microprocessor state has been stored to memory, the special SMM handler begins to execute. The processor is in real mode, all segments have 4-GB limits, and all segments are read/writable.
There is no GDT and the segments can be whatever - just some extra 16-bit registers, lol. Cool
Post 09 Feb 2008, 22:45
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4347
Location: Now
edfed 10 Feb 2008, 00:57
yes, at boot time, the hidden descriptors are set to limit = 64k
when switching to prtected mode, we can change the limits
and return to real mode, limits are then the ones sets by pm.
Post 10 Feb 2008, 00:57
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon 10 Feb 2008, 11:26
That is exactly what I want to do. I've generated the "flatmode" sub from many examples here and around the Internet, but I'm missing something, as it's not setting the address space to 4gig. Can anyone see what's wrong with the code?

Code:
use16
 pushfd  ; Push Flags Register onto the Stack (use 32)
       push    eax
 push    ebx
 push    edx
 call    flatmode                ; first, set up FS to access all 4G 
        
    mov eax,080000048h              ; (G)MCH Base Address Register
      mov dx,0CF8h                    ; set port address
  out dx,eax                      ; send address through the port
     mov dx,0CFCh                    ; set port data
     in eax,dx                       ; fetch data
        mov ebx,eax                     ; save the old value
        or eax,1                        ; increase data by new setting
      out dx,eax                      ; send data through port data

   and ebx,0FFFFC000h              ; mask off bits 31:14 inclusive
 add ebx,250h                    ; point to the relevant part
        mov ax,[fs:ebx]             ; fetch data at 250h address
        and ax,07FFh                    ; set Tras data bit to zero
 or ax,9000h                     ; copy data for Tras 18T
    mov [fs:ebx],ax             ; send data with 18T change

     pop     edx
 pop     ebx
 pop     eax
 popfd                           ; Pop Stack into  Eflags Register
   retf                            ; Return Far from Procedure

;----------------------------------------------------------------------
flatmode:
 ; first, calculate the linear address of GDT
        xor     edx,edx                 ; clear edx
 xor     eax,eax                 ; clear edx
 mov     dx,ds                   ; get the data segment
      shl     edx,4                   ; shift it over a bit
       cli                             ; turn off interrupts
       add     [cs:dword GDT+2],edx        ; store as GDT linear base addr
                                     ; now load the GDT into the GDTR
       lgdt    fword ptr cs:GDT         ; load GDT base (286-style 24-bit load)
     mov     bx,8                    ;1 * size DESC386 ; point to first descriptor
       mov     eax,cr0                 ; prepare to enter protected mode
   or      al,1                    ; flip the PE bit
   mov     cr0,eax                 ; we're now in protected mode
      mov     fs,bx                   ; load the FS segment register
      mov     ds,bx                   ;
   mov     es,bx                   ;
   mov     gs,bx                   ;
   mov     ss,bx                   ; load the SS segment register
      and     al,0FEh                 ; clear the PE bit again
    mov     cr0,eax                 ; back to real mode
 sti                             ; resume handling interrupts
        ret                             ;
;----------------------------------------------------------------------
GDT:
    dw  000fh                       ; limit low
 dw  GDT                         ; base lo
   db  0                           ; base mid
  db  0                           ; dpltype
   db  0                           ; lim hi
    db  0                           ; base hi

       ; this is the setup for the 4G segment
      dw  0ffffh                      ; limit low
 dw  0                           ; base lo
   db  0                           ; base mid
  db  092h                        ; dpltype
   db  0cfh                        ; lim hi
    db  0                           ; base hi
GDT_END:
    
Post 10 Feb 2008, 11:26
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 10 Feb 2008, 11:30
After this:
Code:
        mov     cr0,eax                 ; we're now in protected mode    
you need a jmp to activate PM. And the same when leaving PM.
TFM wrote:
Immediately following the MOV CR0 instruction, execute a far JMP or far CALL
instruction. (This operation is typically a far jump or call to the next instruction in the
instruction stream.)
The JMP or CALL instruction immediately after the MOV CR0 instruction changes the
flow of execution and serializes the processor.
If paging is enabled, the code for the MOV CR0 instruction and the JMP or CALL
instruction must come from a page that is identity mapped (that is, the linear address before
the jump is the same as the physical address after paging and protected mode is enabled).
The target instruction for the JMP or CALL instruction does not need to be identity
mapped.
Post 10 Feb 2008, 11:30
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon 10 Feb 2008, 12:12
Thanks! I'm a little new to assembly, could you give me a little example please. Can it be a jump to just a return in the same code?
Post 10 Feb 2008, 12:12
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 10 Feb 2008, 12:34
The answer is written above: (This operation is typically a far jump or call to the next instruction in the instruction stream.)
Post 10 Feb 2008, 12:34
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon 10 Feb 2008, 12:48
Thanks, but being new to assembly, I don't know how to do a far jump to the next instruction. This won't compile:
Code:
       mov     cr0,eax                 ; back to real mode
 jmp far next
next:
   sti                             ; resume handling interrupts
        ret     
    
Post 10 Feb 2008, 12:48
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 10 Feb 2008, 12:53
jmp seg:offset

eg. jmp 8:next
Post 10 Feb 2008, 12:53
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon 10 Feb 2008, 12:56
This does compile. Thanks!:

Code:
       mov     cr0,eax                 ; back to real mode
        jmp dword next
next:
        sti                             ; resume handling interrupts
        ret   
    
Post 10 Feb 2008, 12:56
View user's profile Send private message Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon 10 Feb 2008, 12:59
As does this. Thanks again:
Code:
        jmp 8:next
next:
        sti                             ; resume handling interrupts
        ret       
Post 10 Feb 2008, 12:59
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 10 Feb 2008, 13:00
jmp dword next won't work, it is a near jump.
Post 10 Feb 2008, 13:00
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon 10 Feb 2008, 13:08
Yes, I see that now. I compiled both and then disassembled both, and I see the problem. Thanks, my friend Very Happy
Post 10 Feb 2008, 13:08
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4047
Location: vpcmpistri
bitRAKE 10 Feb 2008, 16:38
Code:
2E 0F 01 16 0A 35   lgdt fword [cs:350Ah]
0F 20 C0            mov eax, cr0
0C 01               or  al, 1
0F 22 C0            mov cr0, eax
EB 00               jmp short $+2
B8 10 00            mov ax, 10h
8E D0               mov ss, ax
0F 20 C0            mov eax, cr0
24 FE               and al, 0FEh
0F 22 C0            mov cr0, eax
EA 1F 10 86 E8      jmp far [0E886h:101Fh]    
As this code from my BIOS shows, the far jmp/call is only needed to load CS with a valid descriptor from the table. If going back to real mode then loading CS is not required. Following this code SS references are allowed 32-bit offsets with limits based on the cached descriptor (until SS is changed).

Of course, this limits code execution to previously cached CS descriptor limits, usually the first meg of memory. I'm just showing it as a further example (and to say "Hi" to Polygon Smile ).
Post 10 Feb 2008, 16:38
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< 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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.