Author Topic: try to test the protected mode in windows  (Read 13261 times)

Offline codeferever

  • Jr. Member
  • *
  • Posts: 21
try to test the protected mode in windows
« on: December 04, 2010, 06:13:26 AM »
Code: [Select]
; 1G = 0x40000000 = 0x00000001<<30
; 1M = 0x00010000 = 0x00000001<<20
; 1K = 0x00000400 = 0x00000001<<10

; nasm -o invalid.exe -f bin invalid.asm
[bits 32]
[cpu 386]
[section .text]
;The windows system memory maped to top 2GB in protected mode.

;write a word outside the os space
mov edi,0x7fffffe0
mov eax,0x7c00
mov [edi],eax

;read a word from the os space
mov esi,0x80000000
mov eax,[esi]

;write a word to the os space
mov edi,0x80000000
mov eax,0x7c00
mov [edi],eax

; The result
; 16-bit MS-DOS subsystem
;c:\progra~1\nasm\invalid.exe
;NTVDM CPU invalid instruction.
;CS:0587 IP:010a OP:ff 7f b8 00 7c

; I don't know much about debug, can the debug inside ms-dos debug
; 32-bit code ?
; Why this ms-dos warning me it is wrong ?
; The CS and IP values mean what ? in 16-mode or 32-mode ?
« Last Edit: December 04, 2010, 08:14:01 AM by codeferever »

Offline cm

  • Jr. Member
  • *
  • Posts: 65
Re: try to test the protected mode in windows
« Reply #1 on: December 04, 2010, 12:29:02 PM »
With this command line, you instruct NASM to create a flat-format executable. (No one cares about the file name.) Therefore, Windows handles your executable as if it is a 16-bit MS-DOS flat-form executable (usually known to end in the ".COM" file name extension). Therefore, your program does not just crash because it tries to circumvent the memory protection (as is its purpose) but because it is "encoded" (so to speak) to run in a 32-bit mode but it will be run in a 16-bit mode. (This results in wrong and possibly random or invalid instructions executing.)

To create a Windows executable, use NASM's output format "win32" to create an object file (you can use the ".obj" or ".o" file name extension for these: it doesn't really matter, but remember that the file NASM outputs is not the finished executable in this case). Then, use a linker to link this object file into a 32-bit Windows executable. Finding an appropriate linker and how to create the program with it is left as an exercise to the reader. (Because I don't know much about Windows programming.) (Search for tutorials.)
C. Masloch

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: try to test the protected mode in windows
« Reply #2 on: December 04, 2010, 03:43:49 PM »
Finding an appropriate linker and how to create the program with it is left as an exercise to the reader. (Because I don't know much about Windows programming.) (Search for tutorials.)

FYI: The NASMX win32 package currently available on sourceforge http://sourceforge.net/projects/nasmx/ contains everything a Windows assembly programmer needs to create Windows programs.  It contains the assembler ( currently Nasm v2.10rc2 ), a linker, and a resource editor and compiler.  It also includes various Windows include files and macros which target the Windows platform along with demos of their usage.  It does not however contain a file editor or debugger.

Offline codeferever

  • Jr. Member
  • *
  • Posts: 21
Re: try to test the protected mode in windows
« Reply #3 on: December 07, 2010, 07:44:06 AM »
 ???
I really don't know how to generate a win32 file with nasm and alink.exe,
can you give me a example ?

Offline Bryant Keller

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 360
  • Country: us
    • About Bryant Keller
Re: try to test the protected mode in windows
« Reply #4 on: December 07, 2010, 08:25:49 AM »
???
I really don't know how to generate a win32 file with nasm and alink.exe,
can you give me a example ?

Code: (nwin32.asm) [Select]
; Build with:
;    nasm -f obj nwin32.asm
;    alink -c -oPE -subsys gui nwin32

[BITS  32]
[CPU 486]

EXTERN ExitProcess
EXTERN MessageBoxA
IMPORT ExitProcess kernel32.dll
IMPORT MessageBoxA user32.dll

[SECTION .data]

strCaption:    db "Hi!", 0
strMessage:   db "Win32 NASM Application", 0

[SECTION .text]
..start:
    push dword 0                    ; uType
    push dword strCaption           ; lpCaption
    push dword strMessage           ; lpText
    push dword 0                    ; hWnd
    call [MessageBoxA]

    push dword 0                    ; uExitCode
    call [ExitProcess]
« Last Edit: December 07, 2010, 08:29:05 AM by Bryant Keller »

About Bryant Keller
bkeller@about.me

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: try to test the protected mode in windows
« Reply #5 on: December 07, 2010, 12:16:45 PM »
Thanks, Bryant! I'm not able (okay, I'm not willing) to test this, but I'm getting warnings from Alink (with the help of a poster on this forum, I've got Alink running in Linux).

I believe that the problem is that "-f obj" is, by default, a 16-bit format. The "[BITS 32]" may help to override this, but I'm not sure it's enough. I believe that the section declarations also(?) need to be specified as "use32". Further, it seems to help if the code section is marked "class=CODE" (Agner's "objconv" thinks it's "noexecute" without it and doesn't disassemble it, and as I recall Ollydbg likes it better with it). It may help to specify an "align=" as well - default alignment seems to be "align=1" (Although it comes out on an even alignment anyway)

Code: [Select]
; Build with:
;    nasm -f obj nwin32.asm
;    alink -c -oPE -subsys gui nwin32

[BITS  32]
[CPU 486]

EXTERN ExitProcess
EXTERN MessageBoxA
IMPORT ExitProcess kernel32.dll
IMPORT MessageBoxA user32.dll

[SECTION .data use32] ; aint got no class? :)

strCaption:    db "Hi!", 0
strMessage:   db "Win32 NASM Application", 0

[SECTION .text use32 class=CODE]
..start:
    push dword 0                    ; uType
    push dword strCaption           ; lpCaption
    push dword strMessage           ; lpText
    push dword 0                    ; hWnd
    call [MessageBoxA]

    push dword 0                    ; uExitCode
    call [ExitProcess]

That's based on my shakey memory, and on examination of the code. It would be really nice if someone who is actually running the bloody virus, Windows, would test the thing - both ways - and report back...

Best,
Frank