2010-04-14 7 views
6

से एमबीआर बूटिंग एक परियोजना के लिए मैं एमओएस को पहली हार्डडिस्क पर सीधे डॉस से आमंत्रित करना चाहता हूं। मैंने एक छोटा असेंबलर प्रोग्राम लिखा है जो 0: 7c00h पर मेमोरी में एमबीआर लोड करता है, जो इससे कहीं ज्यादा कूदता है। मैंने अपना उपयोग एक (डीओएस) बूट करने योग्य फ्लॉपी पर रखा है। डिस्क (एचडी 0, 0x80) मैं बूट करने की कोशिश कर रहा हूं इसमें एक TrueCrypt बूट लोडर है। जब मैं इस सेटअप में टूल चलाता हूं, तो यह TrueCrypt स्क्रीन दिखाता है, लेकिन पासवर्ड दर्ज करने के बाद यह सिस्टम को क्रैश करता है। जब मैं एक सामान्य WinXP मशीन पर अपनी छोटी उपयोगिता (w00t.com) चलाता हूं तो यह तुरंत क्रैश लगता है।डीओएस

जाहिर है, मैं सामान्य रूप से कुछ महत्वपूर्ण चीजें भूल रहा हूं, मेरा अनुमान है कि यह कुछ मामूली है। क्या बेहतर नंगे धातु डीओएस और बीआईओएस अनुभव वाला कोई व्यक्ति मेरी मदद कर सकता है?

यहाँ मेरा कोड:

.MODEL tiny 
.386 
_TEXT SEGMENT USE16 

INCLUDE BootDefs.i 

ORG 100h 

start: 
    ; http://vxheavens.com/lib/vbw05.html 
    ; Before DOS has booted the BIOS stores the amount of usable lower memory 
    ; in a word located at 0:413h in memory. We going to erase this value because 
    ; we have booted dos before loading the bootsector, and dos is fat (and ugly). 

    ; fake free memory 
    ;push ds 
    ;push 0 
    ;pop  ds 
    ;mov  ax, TC_BOOT_LOADER_SEGMENT/1024 * 16 + TC_BOOT_MEMORY_REQUIRED 
    ;mov word ptr ds:[413h], ax ;ax = memory in K 
    ;pop ds 
    ;lea si, memory_patched_msg 
    ;call print 

    ;mov ax, cs 
    mov ax, 0 
    mov es, ax 

    ; read first sector to es:7c00h (== cs:7c00) 
    mov dl, 80h 
    mov cl, 1 
    mov al, 1 
    mov bx, 7c00h ;load sector to es:bx 
    call read_sectors 

    lea si, mbr_loaded_msg 
    call print 

    lea si, jmp_to_mbr_msg 
    call print 

    ;Set BIOS default values in environment 
    cli 
    mov dl, 80h ;(drive C) 
    xor ax, ax 
    mov ds, ax 
    mov es, ax 
    mov ss, ax 
    mov sp, 0ffffh 
    sti 

    push es 
    push 7c00h 
    retf   ;Jump to MBR code at 0:7c00h 


    ; Print string 
print: 
    xor bx, bx 
    mov ah, 0eh 
    cld 

@@: lodsb 
    test al, al 
    jz print_end 

    int 10h 
    jmp @B 

print_end: 
    ret 

    ; Read sectors of the first cylinder 
read_sectors: 
    mov ch, 0   ; Cylinder 
    mov dh, 0   ; Head 
         ; DL = drive number passed from BIOS 
    mov ah, 2 
    int 13h 
    jnc read_ok 

    lea si, disk_error_msg 
    call print 
read_ok: 
    ret 

memory_patched_msg  db 'Memory patched', 13, 10, 7, 0 
mbr_loaded_msg   db 'MBR loaded', 13, 10, 7, 0 
jmp_to_mbr_msg   db 'Jumping to MBR code', 13, 10, 7, 0 
disk_error_msg   db 'Disk error', 13, 10, 7, 0 

_TEXT ENDS 
END start 

उत्तर

1

संपादित - नया उत्तर:

ठीक है, लगता है कि मैं पहली बार अपने प्रश्न को गलत समझा।

  • चेक कि आप या तो HIMEM.SYS और/या EMM386.EXE (और न ही किसी अन्य स्मृति प्रबंधक) लोड नहीं है: केवल आगे की सलाह मैं दे सकता है यह है। बूटलोडर निष्पादित होने पर CPU वास्तविक मोड में होना चाहिए।

  • राल्फ ब्राउन की इंटरप्ट सूची देखें। अगर मुझे सही तरीके से याद है, बूट प्रक्रिया के बारे में वहां कुछ तकनीकी जानकारी है। यह आपको एक संकेत दे सकता है।

  • अन्य लोडर उपयोगिताओं के स्रोत कोड को देखें, उदा। loadlin। (यह आपकी उपयोगिता के रूप में बिल्कुल वैसा ही काम करते हैं नहीं है, लेकिन आप कुछ अंतर्दृष्टि फिर भी दे सकता है।)


पिछला जवाब:

ORG 100h वास्तव में है बूट लोडर में करने के लिए सही चीज?

मैंने सोचा कि यह सिर्फ डॉस .com निष्पादन योग्य के लिए प्रासंगिक था, क्योंकि डॉस प्रोग्राम सेगमेंट प्रीफिक्स (पीएसपी) के साथ पहले 256 बाइट्स को प्रारंभ करेगा। यदि आप बूट लोडर लिखते हैं, तो कोई डॉस नहीं है, और पीएसपी जैसी कोई चीज़ नहीं है। मुझे लगता है कि यह ORG 0 होना चाहिए।

+0

यह एक COM फ़ाइल वास्तव में है, इसलिए कि whys है यह 100h पर ORGed है। किसी भी अन्य .com फ़ाइल की तरह। यह एमबीआर को मेम करने के लिए लोड करता है और कूदता है। जैसा कि आप अपने प्रारंभिक प्रश्न में पढ़ सकते हैं, यह वास्तव में नौकरी करता है: TrueCrypt बूटलोडर प्रारंभ हो जाता है और सही स्क्रीन दिखाता है। तो लोडिंग और कूद काम करता है। उसके बाद ही, कंप्यूटर फ्रीज हो जाता है। कुछ गलत होना चाहिए, शायद पर्यावरण सही ढंग से सेट नहीं है? – Rogier

+0

यदि आपकी डिस्क पर TrueCrypt बूट लोडर वास्तव में _expects_ नियमित '.com' फ़ाइल है, तो' ORG 100h' कोई समस्या नहीं होनी चाहिए। अन्यथा, मुझे लगता है कि यह एक त्रुटि है। - दूसरा, यह कोई आश्चर्य की बात नहीं है कि Windows XP के तहत निष्पादित होने पर आपका प्रोग्राम क्रैश हो जाता है। जब कंप्यूटर पहले बूट करता है, तो CPU वास्तविक मोड (8086 इम्यूलेशन) में होता है, और बूट लोडर इसकी अपेक्षा करते हैं। एक बार विंडोज एक्सपी शुरू हो जाने के बाद, सीपीयू कभी भी रीयल मोड में वापस नहीं आ जाएगा। डॉस प्रोग्राम्स को वर्चुअल 8086 मोड (यदि मुझे सही नाम याद है) में निष्पादित किया जा सकता है, और बूटलोडर उस CPU मोड में काम नहीं करेंगे। – stakx

+0

नहीं, इस यूटिल के साथ विंडोज (एक्सपी) में 0: 7 सी 00 को संबोधित करने के लिए बूटलोडर लोड करना भी संभव नहीं है। आप सीधे खिड़कियों से डिस्क को acces नहीं कर सकते हैं और आप सिर्फ mem में चारों ओर pokin नहीं जा सकते हैं। लेकिन कृपया मेरे प्रश्न में पढ़ें कि मैं फ्लॉपी (छवि) से उपकरण चला रहा हूं, यानी यह डॉस, 16 बिट असली मोड में चल रहा है। इसके अलावा वास्तव में नौकरी आंशिक रूप से पहले से ही है; टीसी बूटलोडर शुरू हुआ और "टीसी में आपका स्वागत है, कृपया पासवर्ड दर्ज करें" स्क्रीन दिखाएं। उसके बाद ही यह पागल हो जाता है। Ergo, BIOS सामान्य रूप से स्थापित वातावरण में कुछ गलत होना चाहिए। – Rogier

0

मुझे नहीं लगता कि यह बूट लोडर है, यह .com फ़ाइल है जो बूट सेक्टर लोड करती है और इसे निष्पादित करने का प्रयास करती है। तो डॉस शुरू होने के बाद यह चलता है।

1

ठीक है मेरी डॉस ज्ञान बहुत जंग लगी है और मैं समय का परीक्षण/मेरा उत्तर मान्य करने के लिए नहीं था, लेकिन मुझे लगता है कि आपकी समस्या इस प्रकार है:

जब डॉस या किसी अन्य ओएस बूट, वे बदल जाएगा बाधा तालिका। डॉस इंटरप्ट टेबल को बदल देगा - उदाहरण के लिए - इंटरप्ट 20 का उपयोग डॉस "कर्नेल" को कमांड भेजने के लिए किया जा सकता है। वे इसे मूल हस्तक्षेप हैंडलर को सहेजकर करते हैं, इसे अपने हैंडलर द्वारा प्रतिस्थापित करते हैं और बाद में, डिफ़ॉल्ट फॉलबैक के रूप में, मूल इंटरप्ट हैंडलर को चेन करते हुए अगर वे नहीं जानते कि बाधा को कैसे संभालना है।इस तरह वे पहले से मौजूद बायोस funcitionality के लिए नई कार्यक्षमता "जोड़", और डीओएस के तहत चल रहे हर कार्यक्रम सिस्टम रजिस्टरों को बस कुछ रजिस्टरों को सेट करके और फिर बाधा को बुलाकर सिस्टम कॉल का उपयोग कर सकते हैं।

हालांकि, जब आप एक नया ऑपरेटिंग सिस्टम बूट करते हैं, तो यह नया ऑपरेटिंग सिस्टम यह मान लेगा कि ए) सभी इंटरप्ट को बायोस द्वारा नियंत्रित किया जाता है और बी) सभी बायोमा द्वारा उपयोग में रिपोर्ट किए जाने तक सभी मेमोरी मुफ्त/अप्रयुक्त होती है।

तो नया ओएस वर्तमान में आपके पुराने ओएस द्वारा उपयोग की जाने वाली मेमोरी को ओवरराइट करेगा और फिर यह किसी बिंदु पर इंटरप्ट्स में से किसी एक को कॉल करेगा, और अमान्य मेमोरी में कुछ निष्पादित करेगा, और आपका कंप्यूटर क्रैश हो जाएगा।

तो, मूल bios संस्करण के लिए अपने बाधा तालिका रीसेट और आप ठीक होना चाहिए ...

+0

अरे यह सराहनीय लगता है! धन्यवाद। – Rogier

संबंधित मुद्दे