locked
Accessing Privileges RRS feed

  • Question

  •    I am about to learn the assembly language but have been stuck with privileges to the CPU and/or other parts of the hardware (such as RAM). I can't even call an interrupt routine such as DOS's int 21 .

       I wonder if there is any way to cut the hands of OS off of privileges and gives them all to the user. I'm not afraid of viruses, I can handle them (suppose it's a test system ;) ). There may be some environmental variable or registry key to solve the problem.

    for instance, I receive the following run-time error (this error works as a stop working pop up message if I run the .exe, I found it through debugging by VS 2010 Ult B2. It's accurate, I debugged it with VS 2008 too):

    0xC0000005 : Access violation for reading the 0xffffffff of the memory!!! just because I used an int instruction.

       You see, I just wrote the following opcodes and recieved the error:


    .486
    
    .model flat,stdcall
    .stack 100
    
    .data
        x DB 'Student$'
        p db 8
          db ?
          db 8 dup (?)
    
    .code
    
    assume ds:_DATA,cs:_TEXT
    
    main:
        push ds
        push 0
        mov eax,offset _DATA
        mov ds,eax
        mov ah,10
        lea edx,p
        int 21h
        ret
    
    end main
    
    



       Some of my fellow colleagues kill the kernel, most probable in Linux, but I just want to bend it, not shutting it down. There must be a trigger for accessing the 0 privilege on my processor implemented in the OS Win7, a backdoor or something. I would be thankful if you or anybody else could pass the secret to me. Anyway, the OS Win8's kernel itself must be built somehow ;).

        Oh! by the way you may need these:
              assembler: MASM32 @ http://www.masm32.com
              OS: Win7 Ult
              CPU: AMD64 Architecture - family 10h
              RAM: PC3-10666 DDR3 2*2 Dual module

       This question's been asked through Microsoft answers too, at the:
             http://social.answers.microsoft.com/Forums/en-US/w7security/thread/d34e9bc9-d88e-4d2d-b105-05e734883bb0?prof=required



    Thanks everybody!
    Tuesday, December 22, 2009 11:37 PM

All replies

  • After checking the issue, it seems this is a general Visual Studio related issue. As this forum focuses on Windows 7 specific issues, this inquiry would best be posted to MSDN forum:

    http://social.msdn.microsoft.com/Forums/en-US/category/visualstudio

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us.  Thank you for your understanding.


    Sean Zhu - MSFT
    Tuesday, December 29, 2009 8:46 AM
  • Thanks Sean!

      But there is still a problem! I didn't use the Visual Studio to assemble that pure assembly code and I didn't even used VS as an IDE, (as I said it was the Steve Hutchesson's MASM32 ver. 10 on RadASM IDE, which means it got nothing to do with the Visual Studio's assemblers) I just used the debugger to find out why it stops working in Windows! and I found the Access Violation! Now I want to set aside the Windows restrictions to see the result of the sample code I just wrote! so I still think It is the Windows matter. These restrictions are applied for security matters and opening them up may cause security risks! And it's also beyond the usual use of the OS, I mean it is a technical matter! So as I said, I think It is just fit for the Windows 7 Security Forum on TechNet!

    By the way, thanks!
    Tuesday, December 29, 2009 12:51 PM

  • I have finally found the problem! I was using the MASM 5.1 and earlier style with MASM 6.11 and later assembler. that was a problem, but when I used the right assembler for my code (MASM 5.10), I got a new error with NTVDM.exe! funny! I solved one, and found another! :D

    I think the question for NTVDM.exe (which might mean NT Virtual D??? Machine  :D) is not proper for this section of forum. But I insist that there must be a way to fool the kernel from meddling in interrupt execution!
    Wednesday, January 27, 2010 10:04 PM