სისტემის პროცესებისა და OS ბირთვების გამართვა. Hardcore გამართვა Linice-თან: ისწავლეთ მუშაობა კონსოლის ბირთვის გამართვაში. სამიზნე სისტემების ტიპები

03.03.2020

ავტორები:
ბარინოვი ს.ს., შევჩენკო ო.გ.
წელი:
წყარო:
ინფორმატიკა და კომპიუტერული ტექნოლოგიები / სტუდენტების, მაგისტრანტებისა და ახალგაზრდა მეცნიერების VI საერთაშორისო სამეცნიერო და ტექნიკური კონფერენციის მასალები - 2010 წლის 23-25 ნოემბერი, დონეცკი, დონსტუ. - 2010. - 448გვ.

ანოტაცია

მოცემულია მომხმარებლის გამართვის რეჟიმისა და ბირთვის რეჟიმის შედარებითი ანალიზი Microsoft Windows ოპერაციულ სისტემასთან მიმართებაში, ხაზგასმულია ამ უკანასკნელის გამართვის ორგანიზების განსხვავებები და პრობლემები. მიღებული შედეგების საფუძველზე ჩამოყალიბებულია ძირითადი მოთხოვნები ბირთვის რეჟიმის გამართვისთვის საგანგებო და ინტერაქტიული გამართვის შემთხვევაში. განხორციელდა მოთხოვნებთან შესაბამისობის არსებული გადაწყვეტილებების ანალიზი. კერძოდ, განსაკუთრებული ყურადღება ეთმობა Microsoft Windows Debugger-ს.

Მთავარი ნაწილი

გამართვა არის პროგრამული უზრუნველყოფის შეცდომების მიზეზების იდენტიფიცირებისა და აღმოფხვრის პროცესი. ზოგიერთ პროექტში, გამართვას სჭირდება განვითარების მთლიანი დროის 50%. გამართვა შეიძლება მნიშვნელოვნად გამარტივდეს სპეციალიზებული ხელსაწყოების გამოყენებით, რომლებიც მუდმივად იხვეწებიან. მთავარი ასეთი ინსტრუმენტი არის გამართვა, რომელიც საშუალებას გაძლევთ აკონტროლოთ პროგრამული უზრუნველყოფის შესრულება, აკონტროლოთ მისი პროგრესი და ჩაერიოთ მასში. ბირთვის გამართვის ინსტრუმენტები ძირითადად გამოიყენება დრაივერის დეველოპერების მიერ.

აპლიკაციის პროგრამული უზრუნველყოფის შემუშავების ინსტრუმენტები პროგრამისტს ფართო შესაძლებლობებს სთავაზობს. ნებისმიერი ინტეგრირებული განვითარების გარემო მოიცავს გამართვის შესაძლებლობას მესამე მხარის კომუნალური საშუალებების გამოყენების გარეშე. თუ კონკრეტულად ვსაუბრობთ სისტემის პროგრამულ უზრუნველყოფასა და დრაივერების შემუშავებაზე, მაშინ მისი სპეციფიკიდან გამომდინარე, განვითარების პროცესი უკიდურესად რთული და ნაკლებად ავტომატიზირებულია. განვითარების ყველა ეტაპი, გამართვის ჩათვლით, ცალკეა. თითოეული მათგანის განსახორციელებლად საჭიროა სპეციალური პირობები: პროგრამის კოდის ჩაწერა ხორციელდება სრულფასოვან კომპიუტერულ სისტემაზე, გამართვა ხდება გამართვის სისტემაზე, ტესტირება ხდება გარემოებების მიხედვით და ა.შ. თავად ბირთვის რეჟიმის გამართვა უფრო რთული შესასწავლია და, შესაბამისად, ნაკლებად მეგობრული.

ზოგადად, შეიძლება ვისაუბროთ ბირთვის გამართვის ხელსაწყოების ნაკლებობაზე. მიუხედავად იმისა, რომ ასეთი საშუალებები არსებობს, ხშირად არ არის საუბარი ალტერნატივებზე. მაგალითად, Microsoft Windows Debugger-ს აქვს ძალიან მაღალი შესვლის ბარიერი. ბევრი პროგრამისტი საუბრობს პირველ ნეგატიურ გამოცდილებაზე მასთან შეხვედრისას და მისი შესაძლებლობების უმეტესობა გამოუცხადებელი რჩება.

ვირტუალური მისამართების სივრცის სტრუქტურიდან გამომდინარე, თუ აპლიკაცია დაუშვებს შეცდომას, რომელიც აიძულებს აპლიკაციას დაწეროს მონაცემები მეხსიერების თვითნებურ ადგილას, აპლიკაცია მხოლოდ საკუთარ მეხსიერებას დააზიანებს და არ იმოქმედებს სხვა აპლიკაციებისა და ოპერაციული სისტემის მუშაობაზე. . მიუხედავად იმისა, რომ ბირთვის რეჟიმის პროგრამის კოდს შეუძლია დააზიანოს ოპერაციული სისტემის მნიშვნელოვანი მონაცემთა სტრუქტურები, რაც აუცილებლად გამოიწვევს ზოგად მარცხს. არაეფექტურად დაწერილმა დრაივერმა ასევე შეიძლება გამოიწვიოს მთელი ოპერაციული სისტემის სერიოზული დეგრადაცია.

გამართვა წყარო კოდის დონეზე;
შესრულების მართვა;
მეხსიერების დათვალიერება და შეცვლა;
პროცესორის რეგისტრების შიგთავსის ნახვა და შეცვლა;
ზარის სტეკის ნახვა.

დაშლილ კოდთან მუშაობის გასაადვილებლად ე.წ. სიმბოლოების გამართვა. სანამ ლინკერი მუშაობს, გარდა შესრულებადი ფაილის გამოსახულების გარდა, ასევე შეიძლება შეიქმნას მონაცემთა ფაილი, რომელიც შეიცავს ინფორმაციას, რომელიც არ არის საჭირო პროგრამის შესრულებისას, მაგრამ ძალიან სასარგებლოა მისი გამართვისას: ფუნქციების სახელები, გლობალური ცვლადები, აღწერილობები. სტრუქტურების. გამართვის სიმბოლოები ხელმისაწვდომია Windows ოპერაციული სისტემის ყველა შესრულებადისთვის.

შესრულების კონტროლი გულისხმობს პროგრამის კოდის შესრულების შეწყვეტის და განახლების შესაძლებლობას პროგრამის კოდში მითითებული ბრძანების მიღწევის შემდეგ. თუ პროგრამის კოდი შესრულებულია ნაბიჯ-ნაბიჯ რეჟიმში, შეფერხება ხდება თითოეული პროგრამირების ენის ნიშნისთვის ან ქვეპროგრამიდან გასვლისას. თავისუფალ შესრულებაში, შესრულების შეფერხებები ხდება კოდის წინასწარ განსაზღვრულ განყოფილებებში - ადგილები, სადაც დაყენებულია წყვეტის წერტილები.

ბირთვის რეჟიმის კოდის შეწყვეტისას ჩნდება შემდეგი დილემა. დებუგერი იყენებს მომხმარებლის ინტერფეისს პროგრამისტთან ურთიერთობისთვის. იმათ. გამართვის ხილული ნაწილი მაინც მუშაობს მომხმარებლის რეჟიმში და ბუნებრივია იყენებს აპლიკაციის პროგრამირების ინტერფეისს (Windows API), რომელიც თავის მხრივ მის ასაგებად ეყრდნობა ბირთვის რეჟიმის მოდულებს. ამრიგად, ბირთვის რეჟიმის კოდის შეჩერებამ შეიძლება გამოიწვიოს ჩიხი: სისტემა შეწყვეტს პასუხს მომხმარებლის მოთხოვნებზე.

ბირთვის მეხსიერებაში წვდომისთვის, გამართვის ნაწილები ასევე უნდა მუშაობდეს ბირთვის რეჟიმში. ეს იწვევს ერთდროულად ორ პრობლემას, რაც მეხსიერების პროცესორის დაცულ რეჟიმში ორგანიზების აშკარა შედეგია.

პირველი პრობლემა ეხება ვირტუალური მეხსიერების მისამართების თარგმნას. დრაივერები მუდმივად ურთიერთობენ მომხმარებლის რეჟიმის აპლიკაციებთან მათ მეხსიერებაში წვდომით. Windows ოპერაციული სისტემა თარგმნის ვირტუალურ მისამართებს ფიზიკურად, თემის კონტექსტის კონცეფციის საფუძველზე. თემის კონტექსტი არის სტრუქტურა, რომელიც ასახავს ძაფის მდგომარეობას და მოიცავს, კერძოდ, რეგისტრების ერთობლიობას და სხვა ინფორმაციას. როდესაც კონტროლი გადადის სხვა ძაფზე, ხდება კონტექსტის შეცვლა, რომელიც ინახავს ინფორმაციას ერთი თემის შესახებ და აღადგენს ინფორმაციას მეორის შესახებ. როდესაც თემის კონტექსტი გადართულია სხვა პროცესის ძაფზე, გვერდების დირექტორია, რომელიც გამოიყენება ვირტუალური მისამართების ფიზიკურად გადასათარგმნად, ასევე გადართავს.

თავისებურება ის არის, რომ სისტემური ზარების გაგზავნისას Windows ოპერაციული სისტემა არ ცვლის კონტექსტს. ეს საშუალებას აძლევს ბირთვის რეჟიმის კოდს გამოიყენოს მომხმარებლის რეჟიმის ვირტუალური მისამართები.

სიტუაცია განსხვავებულია შეფერხებების გაგზავნისას ან სისტემის ძაფების შესრულებისას. შეფერხება შეიძლება მოხდეს ნებისმიერ დროს, ასე რომ, არ არსებობს იმის პროგნოზირება, თუ რომელი თემის კონტექსტი იქნება გამოყენებული. სისტემის ძაფები არ განეკუთვნება არცერთ პროცესს და არ შეუძლია მომხმარებლის რეჟიმის ვირტუალური მისამართების თარგმნა. აქედან გამომდინარეობს, რომ ამ სიტუაციებში მომხმარებლის რეჟიმის მეხსიერებაზე წვდომა შეუძლებელია.

მეორე პრობლემა არის გადასატან მეხსიერებაზე წვდომა. მეხსიერების ინფორმაციის უმეტესი ნაწილი გადაადგილებადია და ნებისმიერ დროს შესაძლებელია ფიზიკური მეხსიერებიდან მყარ დისკზე გადატანა გვერდის ფაილში. თუ ისეთ გვერდზე წვდომა, რომელიც არ არის ფიზიკურ მეხსიერებაში, პროცესორი ჩვეულებრივ წარმოქმნის Page Fault შეფერხებას, რომელსაც ამუშავებს მეხსიერების მენეჯერი, რის შედეგადაც გვერდი იკითხება გვერდის ფაილიდან და იტვირთება ფიზიკურ მეხსიერებაში.

ეს ქცევა იშლება, თუ გამართვის კოდი იძულებულია გამოიყენოს შეფერხების მოთხოვნის მაღალი დონე (IRQL). თუ IRQL ემთხვევა ან აღემატება მეხსიერების მენეჯერის IRQL-ს, ეს უკანასკნელი ვერ შეძლებს დაკარგული გვერდის ჩატვირთვას, რადგან ოპერაციული სისტემა დაბლოკავს Page Fault-ის შეფერხებას. ეს გამოიწვევს ოპერაციული სისტემის ავარიას.

გამართვა ჩვეულებრივ იყოფა ინტერაქტიულ და საგანგებოდ. ინტერაქტიული ლოკალური გამართვისას, გამართვა მუშაობს იმავე სისტემაზე, როგორც გამართვა. ინტერაქტიული დისტანციური გამართვისას, გამართვა და გამართვის ობიექტი მუშაობს სხვადასხვა სისტემაზე. ბირთვის კოდის გამართვისას, სისტემა უნდა კონტროლდებოდეს მისი ჩატვირთვის პირველი ეტაპებიდან, როდესაც ქსელი ჯერ არ ფუნქციონირებს, ამიტომ სისტემებს შორის კომუნიკაციისთვის გამოიყენება მარტივი სერიული ინტერფეისები, როგორიცაა COM, FireWire, USB. ბოლო დროს, აბსტრაქციის სხვადასხვა დონეზე პროგრამული უზრუნველყოფის ვირტუალიზაციის განვითარების ტენდენციების წყალობით, ვირტუალური მანქანები სულ უფრო ხშირად გამოიყენება. სტუმარი OS მოქმედებს როგორც გამართვის OS, მასპინძელი OS მოიცავს debugger მომხმარებლის ინტერფეისს.

ამიტომ, გადაუდებელი გამართვისთვის არ არის საჭირო გამართვის ხელსაწყოს დაინსტალირება სატესტო კომპიუტერზე. Windows ოპერაციული სისტემის განაწილება მოიცავს მექანიზმებს გადაუდებელი გამართვის განსახორციელებლად. გადატვირთვამდე, ოპერაციულ სისტემას შეუძლია შეინახოს ინფორმაცია მისი მდგომარეობის შესახებ, რომელიც დეველოპერს შეუძლია გააანალიზოს და გაარკვიოს მიზეზი. ფაილში შენახულ ასეთ ინფორმაციას მეხსიერების ნაგავსაყრელი ეწოდება.

ძირითადი ბირთვის რეჟიმის გამართვის ინსტრუმენტები მოწოდებულია თავად Windows ოპერაციული სისტემის მწარმოებლის მიერ, როგორც თავისუფლად განაწილებული გამართვის ხელსაწყოები Windows-ისთვის. ინსტრუმენტებში შედის გრაფიკული და კონსოლის გამართვა WinDbg და KD, შესაბამისად (შემდგომში Windows Debugger). ამ გამართვების მუშაობა ეფუძნება მექანიზმებს, რომლებიც უზრუნველყოფილია ოპერაციული სისტემის დეველოპერების მიერ და ჩართულია მის ბირთვში.

Windows Debugger-ის მთავარი რეჟიმი არის ბრძანების თარჯიმნის რეჟიმი. მოდულური სტრუქტურის წყალობით, Windows Debugger-ი მხარს უჭერს მესამე მხარის მოდულებს, რომლებსაც გაფართოებები ეწოდება, დეველოპერის მიერ მიწოდებული ბრძანებების გარდა. სინამდვილეში, ჩაშენებული ბრძანებების უმეტესობა ასევე შეფუთულია გაფართოების სახით.

Windows Debugger ორიენტირებულია დისტანციურ ინტერაქტიულ და გადაუდებელ გამართვაზე, რომელიც გამოყენებისას ავლენს მის ყველა შესაძლებლობას. ამავდროულად, სრული ლოკალური ინტერაქტიული გამართვა არ არის მხარდაჭერილი: გამართვა მხოლოდ ბირთვის ზოგიერთი სტრუქტურის ნახვის საშუალებას გაძლევთ.

არსებობს Windows Debugger-ის გაფართოების მოდული სახელწოდებით LiveKD, შექმნილი მარკ რუსინოვიჩის მიერ, რომელიც გარკვეულწილად ახორციელებს ადგილობრივ ინტერაქტიულ გამართვას. LiveKD ქმნის სამუშაო სისტემის მეხსიერების ნაგავსაყრელს და იყენებს მას გამართვისთვის.

Windows-ისთვის გამართვის ინსტრუმენტების პაკეტი რეგულარულად განახლდება და მხარს უჭერს ყველა თანამედროვე Windows ოპერაციულ სისტემას.

SoftICE ბირთვის გამართვა, რომელიც დამზადებულია Compuware-ის მიერ DriverStudio პროგრამულ პაკეტში, ტრადიციულად იყო Windows-ის გამართვის ინსტრუმენტების ალტერნატივა. SoftICE-ის გამორჩეული თვისება იყო ადგილობრივი ინტერაქტიული გამართვის განხორციელება მხარდაჭერილ აპარატურაზე. Debugger-ს შეეძლო თითქმის მთლიანად აკონტროლებდეს ოპერაციული სისტემის მუშაობას.

2006 წლის 3 აპრილიდან DriverStudio პროდუქციის ოჯახის გაყიდვები შეწყდა „სხვადასხვა ტექნიკური და საქმიანი საკითხების, ასევე ზოგადი ბაზრის პირობების გამო“. მხარდაჭერილი ოპერაციული სისტემის უახლესი ვერსია არის Windows XP Service Pack 2. როგორც წესი, სერვის პაკეტები არ ცვლის ოპერაციული სისტემის აპლიკაციის ინტერფეისს, მაგრამ შეიძლება შეიცვალოს სისტემის ზარის ნომრები და სხვა არადოკუმენტური ინფორმაცია. SoftICE debugger ეყრდნობოდა მონაცემთა შიდა სტრუქტურების მყარი კოდირებულ მისამართებს. შედეგად, თავსებადობა დაირღვა Service Pack 3-ის გამოშვებით. ცხადია, Windows ოპერაციული სისტემის შემდგომი ვერსიებიც არ არის მხარდაჭერილი.

Syser Kernel Debugger შეიქმნა მცირე ჩინური კომპანიის Sysersoft-ის მიერ, როგორც SoftICE გამართვის შემცვლელი. პირველი საბოლოო ვერსია გამოვიდა 2007 წელს. SoftICE-ის მსგავსად, Syser Kernel Debugger-საც შეუძლია გაშვებულ სისტემაზე ინტერაქტიული გამართვა. Windows-ის თანამედროვე ვერსიების მხოლოდ 32-ბიტიანი გამოცემებია მხარდაჭერილი.

ამჟამად, Windows Debugger არის მთავარი ინსტრუმენტი ბირთვის მოდულის დეველოპერებს შორის. მას ასევე იყენებს Windows ოპერაციული სისტემის ბირთვის გუნდი.

Debugger არის მეორე რამ მას შემდეგ, რაც კომპილატორს სჭირდება პროგრამების შესაქმნელად. თუმცა, ბევრმა მათგანმა, ვინც წერს კომპიუტერულ პროგრამებს და იყენებს გამართავს, არ იცის მისი მუშაობის პრინციპები და მექანიზმები.

ძნელია იყო დებუგერი...

იმის გათვალისწინებით, რომ პროგრამისტები იყენებენ გამართვას დღედაღამ, განსაკუთრებით მაშინ, როდესაც ისინი შედიან ღრმა გამართვის რეჟიმში, ღირს იმის თქმა, რომ გამართვა რომ არა პროგრამა, არამედ აპარატურის ნაწილი იყოს, ის ალბათ გადახურდება და გაფუჭდება. იმის გამო, რომ შემდგენელსაც კი არ აქვს იმდენი სამუშაო, რამდენსაც დებუგერი იღებს.

რა თქმა უნდა, რადგან ახლა ბევრი სხვადასხვა პროგრამირების ენაა, თითოეული მათგანისთვის არის სხვადასხვა გამართული. და, ბუნებრივია, ამ ენების სხვადასხვა კატეგორიისთვის, არსებობს განსხვავებები გამართულ მუშაობაში: მაგალითად, პროგრამების გამართვა ინტერპრეტირებული Ruby-ში განსხვავებულად იმუშავებს, ვიდრე ბაიტკოდში შედგენილი Java ენისთვის, ხოლო Java-ს გამართვა, მხრივ, ექნება განსხვავებები Debugger-ისგან Visual C++.

მე ვისაუბრებ Windows პლატფორმის გამართვაზე. მას შემდეგ რაც გაიგეთ გამართვის მოქმედების პრინციპები, შესაძლებელი იქნება გაგება როგორც POSIX სისტემებისთვის, ასევე გამართვისთვის, რომლებიც მუშაობენ არა ოპერაციული სისტემის დონეზე, არამედ ვირტუალური მანქანის ან რომელიმე თარჯიმნის დონეზე.

Debugger-ები Windows-ისთვის: ორი ტიპი

Windows-ისთვის არსებობს ორი ფუნდამენტურად განსხვავებული ტიპის გამართვა. მე ვფიქრობ, რომ ყველას წააწყდა პირველი დელფოში პროგრამირებისას (არ დაპროგრამებულა? ძნელი დასაჯერებელია. რაში დაპროგრამებდით სკოლაში და უმცროს კოლეჯში?). ეს არის პერსონალური აპლიკაციის გამართვა. ბევრი მათგანია და ისინი არსებობენ როგორც ინდივიდუალურად, ისე (განსაკუთრებით, სხვათა შორის, ხშირად), როგორც ინტეგრირებული აპლიკაციის განვითარების გარემოს ნაწილი. ცალკეულ პროგრამულ პროდუქტად გავრცელებულ გამართულებს შორის, OllyDbg ტრადიციულად ხაზგასმულია და ამის შესახებ ერთხელ დავწერე კომპიუტერული ამბები.

გამართვის მეორე ტიპი არის ოპერაციული სისტემის ბირთვის გამართვა. ისინი გვხვდება და გამოიყენება ნაკლებად ხშირად და მათი დიზაინი მნიშვნელოვნად განსხვავდება პერსონალური აპლიკაციების გამართვისგან. ყველაზე ცნობილი და ამავდროულად საუკეთესო ბირთვის გამართვა არის SoftIce. ალბათ თქვენ არა მხოლოდ გსმენიათ ამის შესახებ, არამედ გამოიყენეთ კიდეც.

ვინაიდან ამ ორი ტიპის გამმართველის მუშაობას თავისი სპეციფიკა აქვს, თითოეულ მათგანზე უფრო დეტალურად ვისაუბრებ.

მორგებული აპლიკაციის გამართვა

მომხმარებლის აპლიკაციების გამართვა უფრო მარტივია, რადგან ოპერაციული სისტემა იღებს ყველაზე ცუდ და ბინძურ სამუშაოს. Windows-ს აქვს სპეციალური პროგრამული ინტერფეისები, რომლებიც შექმნილია მომხმარებლის დონის აპლიკაციების გამართვისთვის - მათ უწოდებენ Windows Debugging API. ეს არის გამართვის API-ები, რომლებსაც იყენებს ყველა გამართვა, რომლებიც ჩაშენებულია Windows-ის პოპულარულ ინტეგრირებულ განვითარების გარემოში.

იმისთვის, რომ გამართვა დაიწყოს, გამართვამ უნდა დაიწყოს გამართვის პროცესი სპეციალური გზით - რათა სისტემამ იცოდეს, რომ ეს პროცესი იქნება გამართვის პროცესში. ამის შემდეგ იწყება გამართვის ციკლი: პროგრამა სრულდება მანამ, სანამ არ მოხდება გარკვეული მოვლენა, რომელსაც ეწოდება გამართვის მოვლენა. ეს აწარმოებს გამართვის ციკლს ცალკე ძაფში, რათა თავიდან აიცილოს გამართვის დაკიდება.

მაგრამ ეს მხოლოდ დასაწყისია. იმის გამო, რომ გამართვის გართობა იწყება, როდესაც ხდება გამართვის მოვლენა. ბოლოს და ბოლოს, რა არის გამართვის სამუშაო? დაეხმარონ პროგრამისტს შეცდომის ლოკალიზაციაში სიზუსტით კონკრეტულ ფუნქციაზე, კონკრეტულ ოპერაციაზე, კონკრეტულ ცვლადზე. ოპერაციულ სისტემას ასევე შეუძლია დაეხმაროს დებუგერს ამ რთულ ამოცანაში.

ასე რომ, მოხდა გამართვის მოვლენა და შემდეგ ჩვენ უნდა გავარკვიოთ, როგორ არის ეს დაკავშირებული პროგრამის ტექსტთან. ეს შესაძლებელია მხოლოდ იმ შემთხვევაში, თუ პროგრამა თავად შეიცავს სპეციალურ გამართვის ინფორმაციას - გამართვის სიმბოლოების ცხრილს. ის შეიცავს ინფორმაციას მისამართებისა და ფუნქციების სახელების, მონაცემთა ტიპებისა და კოდის ხაზების ნომრების შესაბამისობის შესახებ. სწორედ მათი წყალობითაა შესაძლებელი გამართვა, რომელსაც ყველა Windows პროგრამისტი იცნობს. სიმბოლოების ცხრილებს აქვთ სხვადასხვა ფორმატი და, შესაბამისად, ყოველთვის არ არის შესაძლებელი პროგრამის გამართვა, რომელიც შედგენილია ერთი დეველოპერის შემდგენელის მიერ სხვა მწარმოებლის გამართვის გამოყენებით. თუმცა, ყველაზე გავრცელებული ფორმატი მაინც შეიძლება დაზუსტდეს - ეს არის PDB (პროგრამის მონაცემთა ბაზა) და ის, ბუნებრივია, შეიქმნა Microsoft Corporation-ის მიერ.

ასე რომ, თუ გამართვის სიმბოლოების ცხრილი არის PDB ფორმატში, მაშინ შეგიძლიათ გამოიყენოთ Microsoft-ის სპეციალური ინსტრუმენტი - სიმბოლური გამართვის პროცესორი. ოდესღაც ის იყო სისტემის ბირთვის ნაწილი და ერქვა Imagehlp.dll, მაგრამ დიდი ხნის წინ ის ცალკე ბიბლიოთეკაში იყო გამოყოფილი. სიმბოლოების პროცესორი საშუალებას გაძლევთ იპოვოთ უახლოესი ღია ფუნქცია ან გლობალური ცვლადი მოცემულ მისამართზე, ისევე როგორც ხაზის ნომერი და წყარო ფაილის სახელი, რომელშიც მდებარეობს ეს ხაზი. ასევე მხარდაჭერილია ინვერსიული ოპერაციები, მაგალითად, ფუნქციის მისამართის ძებნა მისი სახელით.

ეს, რა თქმა უნდა, არ არის მთელი სამუშაო, რასაც აკეთებს პერსონალური აპლიკაციის გამართვა. მაგალითად, მრავალნაკადიანი აპლიკაციების გამართვისას, ჩნდება მრავალი ძალიან დახვეწილი საკითხი, რომელიც დაკავშირებულია ძაფების ურთიერთქმედებით. ისეთი შედარებით მარტივი საკითხების გამართვისასც კი, როგორიცაა სერვისები, არის გარკვეული ნიუანსი.

მაგრამ ჩვენ ახლა არ ვისაუბრებთ ნიუანსებზე - სტატიის ბოლოს გეტყვით, სად წაიკითხოთ მათ შესახებ. ახლა მოდით შევხედოთ ბირთვის გამართვას.

ბირთვის გამართვა

ბირთვის გამართვა ბევრად უფრო რთული პროგრამებია, ვიდრე მომხმარებლის აპლიკაციების გამართვა და ვფიქრობ, რომ საკმაოდ გასაგებია რატომ: მათ არ აქვთ ოპერაციული სისტემის ასისტენტი. ამ შემთხვევაში, ის მათი კლიენტია, რადგან სწორედ მან უნდა გამართოს შეცდომები.

ბირთვის გამართვის უმეტესობას სჭირდება ორი კომპიუტერი, რომლებიც დაკავშირებულია ნულ მოდემის კაბელთან მუშაობისთვის. ნულოვანი მოდემი არის გზა ორი კომპიუტერის პირდაპირ კაბელთან დასაკავშირებლად მათი COM ან LTP პორტების საშუალებით. საჭიროა მეორე კომპიუტერი, რადგან გამართვის ნაწილს, რომელიც ზის პირველზე (მასზე, სადაც დაინსტალირებულია სისტემა) აქვს შეზღუდული წვდომა აპარატურაზე და, შესაბამისად, ყველა მონაცემი გადადის null მოდემის მეშვეობით მეორე კომპიუტერზე.

თანამედროვე Intel x86 არქიტექტურის პროცესორებს აქვთ სპეციალური გამართვის რეგისტრები (როგორც ძველ 368 და ახალ პროცესორის მოდელებს აქვთ მხოლოდ რვა მათგანი, მათ უწოდებენ DR0-DR7). ეს რეგისტრები საშუალებას აძლევს გამმართველს დააყენოს წყვეტის წერტილები მეხსიერების წაკითხვისა და ჩაწერის, ასევე I/O პორტებზე. ზოგადად, ყველაფერი ზუსტად ასე გამოიყურება და ვფიქრობ, არ ღირს ახლა დეტალურად აღვწერო, რაზეა პასუხისმგებელი თითოეული გამართვის რეგისტრი, რა წყვეტს დანერგვის წყვეტის წერტილებს და სხვა მსგავსი ინფორმაციის მიწოდებას. ჯობია გითხრათ Windows-ისთვის ბირთვის კონკრეტული არსებული გამართვის შესახებ.

კარგად, პირველ რიგში, ეს არის თავად ოპერაციული სისტემის ბირთვში ჩაშენებული გამართვა. ის წარმოდგენილია ყველა NT ხაზის ოპერაციულ სისტემაში, დაწყებული Windows 2000-დან. ის არის NTOSKRNL.EXE ფაილის ნაწილი და მისი ჩართვა შესაძლებელია ოპერაციული სისტემისთვის "/Debug" ოფციის დაყენებით BOOT.INI-ში. ეს გამართვა საჭიროებს ნულ მოდემის კავშირს და მეორე კომპიუტერს იგივე OS-ით.

არის კიდევ ერთი ბირთვის გამართვა Microsoft-ისგან - WinDBG. მკაცრად რომ ვთქვათ, ეს არ არის ბირთვის გამართვა, არამედ ჰიბრიდული გამართვა, რომელიც ასევე შეიძლება გამოყენებულ იქნას მომხმარებლის დონის აპლიკაციების გამართვისთვის. მას, ბირთვში ჩაშენებული გამართვისგან განსხვავებით, აქვს გრაფიკული გარსი და, შესაბამისად, უფრო ადვილი გამოსაყენებელია. ეს გამართვა ასევე მხარს უჭერს სპეციალურ გაფართოებებს, რომლებიც შეიძლება სასარგებლო იყოს ზოგიერთი გამართვის ამოცანისთვის. მაგრამ მას ასევე სჭირდება ორი კომპიუტერი ბირთვის გამართვისთვის.

თუმცა, არსებობს ბირთვის გამართვა, რომელსაც შეუძლია გამართოს ერთი კომპიუტერი. ეს არის SoftIce. ამავდროულად, SoftIce-ს ასევე შეუძლია აპლიკაციის პროგრამების გამართვა. ამ გამართვის გამოყენება მომხმარებლის პროგრამებისთვის გამართლებულია, მაგალითად, სისტემის ტაიმერზე მიბმული რეალურ დროში სისტემის გამართვის შემთხვევაში. თუ თქვენ გამართავთ გამართვას ჩვეულებრივი გამართვის საშუალებით, შედეგი შეიძლება იყოს არასწორი, მაშინაც კი, თუ პროგრამა სწორად მუშაობს და SoftIce შეაჩერებს პროგრამასაც და ტაიმერსაც. ეს სასარგებლოა მრავალნაკადიანი აპლიკაციების გამართვისას. გარდა ამისა, SoftIce-ს აქვს ძალიან, ძალიან კარგად განვითარებული საშუალებები სისტემის ყველა ძაფების შესახებ ინფორმაციის საჩვენებლად, ძაფების სინქრონიზაციის შესახებ მრავალნაკადიანი აპლიკაციებისთვის, ინფორმაცია სახელურების შესახებ... ამ გამართვის ერთადერთი მინუსი არის მისი სირთულე აპლიკაციის პროგრამისტისთვის. მაგრამ ბირთვის გამართვისგან ეს ყველაზე მარტივი და ეფექტურია.

ყველაზე ცნობისმოყვარეებისთვის

ახლა, რა თქმა უნდა, Windows-ის აპლიკაციების გამართავებზე საუბარი არც ისე აქტუალურია, როგორც ეს იყო ათი წლის წინ. ინტერნეტით მთელი მსოფლიო დაინტერესდა და SoftIce-ის მთავარი მომხმარებლები იყვნენ კრეკერები, დაუღალავი მუშები მეკობრეობის სფეროში. თუმცა, არც ისე ცუდია. SoftIce-თან კომუნიკაცია უდავოდ ავითარებს ადამიანს კომპიუტერული ცოდნის კუთხით, თუმცა, რა თქმა უნდა, თუ თქვენ დაუკავშირდებით მხოლოდ გამართულებს და არ დაუკავშირდებით რეალურ ადამიანებთან, შესაძლებელია გარკვეული გვერდითი მოვლენები.

Debugger არის ზოგიერთი ყველაზე გამორჩეული ტიპის პროგრამული უზრუნველყოფა, მაგრამ განვითარების თვალსაზრისით, მომხმარებლის დონის პროგრამის გამართვებიც კი საკმაოდ რთულია. მაგრამ, მიუხედავად ამისა, თუ გექნებათ სურვილი და დრო, შეიმუშაოთ საკუთარი დებაგერი, საგრძნობლად გაიზრდება თქვენი ცოდნა ოპერაციული სისტემებისა და პროგრამირების სფეროში, რაც ნიშნავს, რომ გაიზრდება თქვენი კარგი ანაზღაურებადი სამუშაოს მიღების შანსი.

ასე რომ, თუ გსურთ შექმნათ თქვენი საკუთარი გამართვა, ჯერ უნდა წაიკითხოთ მასალები ამ თემაზე. ჩემი აზრით, საუკეთესო წიგნი დასაწყებად არის ჯონ რობინსის წიგნი, Windows Applications-ის გამართვა. ის უკვე ძველია, გამოქვეყნებულია 2001 წელს, მაგრამ მასში მოთავსებული ინფორმაცია დღესაც აქტუალურია, ვინაიდან მას ზოგადი, თუნდაც გარკვეულწილად ფუნდამენტური ხასიათი აქვს. ეს წიგნი შეიცავს Windows-ისთვის გამართვის წერის მაგალითებს და ასევე სასარგებლო იქნება, თუ დაპროგრამებთ C++-ში და გსურთ უკეთ გაიგოთ გამონაკლისების მართვა. ფაქტობრივად, სწორედ ამ წიგნიდან გავიგე ინფორმაცია სტატიაში წარმოდგენილი გამართვის შესახებ. თუ ამ წიგნს ვერ იპოვით (ბოლოს და ბოლოს, ის უკვე საკმაოდ ძველია), არის რამდენიმე მისამართი, რომელიც შეიძლება გამოგადგეთ. პირველი ასეთია: www.xakep.ru/post/19158/default.asp. ეს სტატია ჟურნალ Hacker-დან ცოტა უფრო დეტალურად არის განხილული ბირთვის გამართვის შესახებ, ვიდრე მე, და ასევე შეიცავს კოდს მარტივი გამართვისთვის. და kalashnikoff.ru/Assembler/issues/016.htm შეგიძლიათ ისწავლოთ როგორ დაწეროთ DOS გამართვა. მაგრამ, რა თქმა უნდა, უმჯობესია წაიკითხოთ MSDN და ამავე დროს იპოვოთ რაიმე ღია კოდის გამართვა მის გასაგებად. და, რა თქმა უნდა, თუ თქვენ დაიწყეთ გამართვის წერა, მაშინ წარმატება გელით ამ რთულ ამოცანაში!

ტერმინი "ბირთის გამართვა" ნიშნავს ბირთვის შიდა მონაცემთა სტრუქტურის შემოწმებას და/ან ბირთვში ფუნქციების ნაბიჯ-ნაბიჯ მიკვლევას. ეს გამართვა არის ძალიან სასარგებლო გზა Windows-ის შიდა მუშაობის შესამოწმებლად, რადგან ის საშუალებას გაძლევთ ნახოთ შიდა სისტემის ინფორმაცია, რომელიც არ არის ხელმისაწვდომი სხვა საშუალებების გამოყენებით და იძლევა ნათელ სურათს ბირთვში კოდის პროგრესის შესახებ.

სანამ განვიხილავთ ბირთვის გამართვის სხვადასხვა გზებს, განვიხილოთ ფაილების ნაკრები, რომელიც დაგჭირდებათ ნებისმიერი სახის ბირთვის გამართვისთვის.

სიმბოლოები ბირთვის გამართვისთვის

სიმბოლო ფაილები შეიცავს ფუნქციების და ცვლადების სახელებს, ასევე მონაცემთა სტრუქტურების დიზაინს და ფორმატს. ისინი გენერირდება ლინკერის პროგრამის მიერ და გამოიყენება გამართვის მიერ ამ სახელების მითითებისთვის და მათი საჩვენებლად გამართვის სესიის დროს. ეს ინფორმაცია ჩვეულებრივ არ ინახება ორობით კოდში, რადგან ის არ არის საჭირო კოდის შესრულებისას. ეს ნიშნავს, რომ მის გარეშე, ორობითი კოდი უფრო მცირეა და უფრო სწრაფად მუშაობს. მაგრამ ეს ასევე ნიშნავს, რომ გამართვისას, თქვენ უნდა დარწმუნდეთ, რომ გამართვას აქვს წვდომა სიმბოლოების ფაილებზე, რომლებიც დაკავშირებულია ორობით სურათებთან, რომლებიც მითითებულია გამართვის სესიის დროს.

ნებისმიერი ბირთვის რეჟიმის გამართვის ხელსაწყოს გამოსაყენებლად Windows ბირთვის მონაცემთა სტრუქტურის შიდა ნაწილების შესამოწმებლად (პროცესების სია, ძაფების ბლოკების სია, ჩატვირთული დრაივერების სია, მეხსიერების გამოყენების ინფორმაცია და ა.შ.), გჭირდებათ სწორი სიმბოლო ფაილები და, მინიმუმ, სიმბოლო ფაილი ბირთვის ორობითი გამოსახულების - Ntoskrnl.exe. სიმბოლოების ცხრილის ფაილები უნდა შეესაბამებოდეს ბინარული გამოსახულების ვერსიას, საიდანაც ისინი იქნა ამოღებული. მაგალითად, თუ თქვენ დააინსტალირეთ Windows Service Pack ან რაიმე სახის პატჩი, რომელიც განაახლებს ბირთვს, თქვენ უნდა განაახლოთ სიმბოლო ფაილები შესაბამისად.

Windows-ის სხვადასხვა ვერსიისთვის სიმბოლოების ჩამოტვირთვა და ინსტალაცია მარტივია, მაგრამ პატჩებისთვის სიმბოლოების განახლება ყოველთვის არ არის შესაძლებელი. გამართვისთვის სიმბოლოების საჭირო ვერსიის მოპოვების უმარტივესი გზაა დაუკავშირდით Microsoft-ის სიმბოლო სერვერს, რომელიც სპეციალურად არის შექმნილი ამ მიზნით, სპეციალური სინტაქსის გამოყენებით, რომელიც მითითებულია გამართვისთვის მითითებული სიმბოლოს ბილიკისთვის. მაგალითად, სიმბოლოების შემდეგი გზა იწვევს გამართვის ხელსაწყოებს, გადმოწერონ სიმბოლოები ონლაინ სიმბოლოების სერვერიდან და შეინახონ ადგილობრივი ასლი c:\symbols:srv*c:\symbols*http://msdl.microsoft.com/download/ სიმბოლოები

სიმბოლოების სერვერის გამოყენების დეტალური ინსტრუქციები შეგიძლიათ იხილოთ გამართვის ხელსაწყოების დახმარების ფაილში ან ონლაინ მისამართზე http://msdn.microsoft.com/en-us/windows/hardware/gg462988.aspx.

Windows-ისთვის ბირთვის დონის რამდენიმე წესიერი დებაგერია, მაგრამ ლინუქსში მათი დათვლა შესაძლებელია ერთი ხელის თითებზე და ესენიც კი ძირითადად უხეში, დაუმთავრებელი ან მიტოვებული და ხავსით სავსე... დღეს ვისაუბრებთ ყველაზე პოპულარულებზე. და მათგან ყველაზე საინტერესო -
ლინისი.

შესავალი

როგორც სახელიდან უკვე მიხვდით, ლინისილეგენდარულის არაოფიციალური "პორტია".
SoftICE Linux-ისთვის, რომელმაც შეინარჩუნა ინტერფეისი, ბრძანების სისტემა და ამ უკანასკნელის უმეტესი შესაძლებლობები: ამომხტარი ღილაკის გამოყენებით (in ლინისიეს ); ყველა ფუნქციასა და სისტემურ ზარზე ტექნიკის წყვეტის წერტილების დაყენება; GDT/LDT/IDT, ფიზიკური მეხსიერების გვერდების ნახვა; GDB-დან ნასესხები ფუნქციები (თვითნებური ფუნქციის გამოძახება CALL ბრძანებით, რეგისტრის კონტექსტის შენახვა/აღდგენა, შიდა ცვლადები და ა.შ.).

სხვა გამართვისგან განსხვავებით, რომლებიც მუშაობენ ptrace მექანიზმით, რომელიც არ არის ხელახალი და ადვილად აღმოჩენილი დაცვით (რომლის Windows-ის ანალოგი არის DEBUG_PROCESS, რომელსაც იყენებენ აპლიკაციების გამართვები), ლინისიიყენებს მშობლიურ ტრასირებას, ისევე როგორც SoftICE-ში, რომელიც საშუალებას აძლევს ორივე დებუგერს გამართონ მაღალ დაცული პროგრამები, რომლებსაც სხვები ვერ უმკლავდებიან.

სინამდვილეში, ეს საერთოდ არ არის პორტი (აქედან გამომდინარე ციტატები), არამედ დამოუკიდებელი პროექტი, დაწერილი ნულიდან და განაწილებულია წყაროს კოდით უფასოდ (SoftICE-დან არის მხოლოდ შთაგონება). 2.4 ბირთვისთვის განკუთვნილი კოდის ძირითადი ნაწილი გერმანელმა ჰაკერმა გორან დევიჩმა დაწერა, მაგრამ 2.6 ბირთვის შენარჩუნებაში სრულიად განსხვავებული ადამიანები იყვნენ ჩართულები: დანიელ რეზნიკი, პიტერ კ. და კარლოს მანუელ დუკლოს ვერგარა. და ჩვენმა თანამემამულემ - ოლეგ ხუდაკოვმა - გადაწერა ასამბლერის ფაილები ნასმიდან
gcc.

საწყისი ტექსტები მოცემულია პროექტის ოფიციალურ ვებსაიტზე -
ხაზი%0A.com">www.Linice.com, ასევე არის დოკუმენტაცია, მოკლე FAQ და ფორუმის ბმული
ხაზი%0A">groups.google.com/group/Linice. არ არსებობს მზა ორობითი ასამბლეები.
პროექტის შემქმნელებმა გახსნეს საკუთარი ანგარიში SourceForge-ზე, მაგრამ ძალიან ეზარებოდათ მასში რაიმე ფაილის ატვირთვა, წარმოადგინეს მხოლოდ 3 ძალიან დაბალი ხარისხის ეკრანის სურათი:
.

Სისტემის მოთხოვნები

უახლესი ვერსია ლინისიდანომრილია 2.6 და თარიღდება 2005 წლის 28 ივლისით, სრულად უჭერს მხარს 2.4.x ბირთვს და VGA კონსოლის რეჟიმს. სერიოზული პრობლემებია ახალ ბირთვებთან დაკავშირებით და 2.6.x ბირთვს მხოლოდ შეზღუდული მხარდაჭერა აქვს.
Debugger შეიქმნა და ტესტირება Debian 2.6-ში. მისი თავსებადობა სხვა დისტრიბუციებთან გარანტირებული არ არის, რაც გვაიძულებს მივმართოთ ტამბურს, მაგრამ ზოგიერთ შემთხვევაში ტამბურიც კი არ შველის. სინამდვილეში, შეინახეთ Debian თქვენს აპარატზე მხოლოდ იმისთვის, რომ იმუშაოთ ლინისი, - ეს საკმაოდ ნორმალურია. დიდი ხნის წინ, როდესაც ჯერ არ იყო SoftICE იმპლემენტაცია NT-სთვის, ბევრმა ჰაკერმა დააინსტალირა Win 9x მხოლოდ პროგრამების გასატეხად, თუმცა ისინი თავად ისხდნენ.
ნ.ტ. იმის გამო, რომ დაფაროს ინსტალაციის ყველა სირთულე ლინისიერთი სტატიის ფარგლებში ეს პრაქტიკულად შეუძლებელია, შემოვიფარგლები შედგენისა და გაშვების პროცესის აღწერით ლინისიერთი კონკრეტული განაწილების ქვეშ - Knoppix 3.7 ბირთვით 2.4.1 კონსოლის VGA რეჟიმში.
ლინისიმხარს უჭერს ACPI-ს და მულტიპროცესორულ მანქანებს, მაგრამ კარგად არ მუშაობს X-თან, განსაკუთრებით nVidia-ს გარდა, ის საერთოდ არ აღიქვამს 24-ბიტიან ფერთა სიღრმეს, „ითვისებს“ მხოლოდ 8, 16 და 32 ბიტს, ამიტომ უფრო მოსახერხებელია. X აპლიკაციების გამართვა COM პორტით დაკავშირებული დისტანციური ტერმინალის მეშვეობით VT100 პროტოკოლის გამოყენებით, ამ შემთხვევაში, ადგილობრივი კლავიატურა ასევე იმუშავებს.
ლინისი!

Linice-ის შედგენა და კონფიგურაცია

ჩამოტვირთეთ წყარო ტექსტების gzip არქივი www. ლინისი.devic.us/ ლინისი-2.6.tar.gz, რომელიც იკავებს მეგაბაიტზე ცოტა ნაკლებს, ამოალაგეთ იგი დისკზე, გადადით ./docs დირექტორიაში და readme ფაილიდან აღმოვაჩენთ, რომ გამართავი 2.4 ბირთვისთვის არის აგებული შემდეგნაირად:

# დისკის აშენება
# ./make_bin-2.4
# cd ../bin
# გაასუფთავე; მაქე

თუმცა, სანამ დაიწყებთ make-ს, უნდა გახსნათ ფაილი ./bin-2.4/Makefile და დაარედაქტიროთ "TARGET" ხაზი სამიზნე პლატფორმის კონფიგურაციისა და არქიტექტურის მიხედვით. კერძოდ, ACPI მანქანებზე მრავალბირთვიანი ან HyperThreading პროცესორებით ასე გამოიყურება:

TARGET = -DSMP -DIO_APIC

კომპილაციის დასრულების შემდეგ, ./bin დირექტორიაში იქნება ბევრი ფაილი და დირექტორია, მაგრამ ერთადერთი მნიშვნელოვანი არის:

linsym – გამართვის ჩატვირთვის მოდული;
linice.dat – კონფიგურაციის ფაილი;
xice – X"-ების მხარდაჭერა, ტექსტურ რეჟიმში მუშაობისას შესაძლებელია მისი წაშლა;
./Linice_2.4.27/Linice.o – იტვირთებადი ბირთვის მოდული, რომელიც შეიცავს თავად გამართვას.

აშენების პროცესი ლინისი

მინიმალურად მომუშავე ნაკრების აწყობის შემდეგ, კარგი იქნება, რომ მიიღოთ ყველაფერი დანარჩენი - დემო გამართვის მაგალითები განთავსებულია ./test დირექტორიაში და შედგენილი კომპილირებული სკრიპტით, ასევე გაფართოების მოდული (ჩვენი აზრით, მოდული), რომელიც მდებარეობს ./ext დირექტორია, რომელიც შედგენილია make ბრძანებით და იტვირთება insmod ბრძანებით. ამისგან არანაირი სარგებელი არ არის, მაგრამ წყაროს კოდის შესწავლის შემდეგ ჩვენ შეგვიძლია დავწეროთ საკუთარი მოდულები, რომლებიც აფართოებენ ფუნქციებს
ლინისი.

Knoppix-ის ჩატვირთვისას ჩნდება მოთხოვნა "boot:" ეკრანის ბოლოში, სადაც უნდა შეიყვანოთ "knoppix 2 vga=normal". შეიძლება გამოტოვოთ), "2" ბლოკავს X"-ების ჩატვირთვას და "vga=normal" აყენებს სტანდარტულ vga რეჟიმს 80x25 გარჩევადობით.

ჩამოტვირთვის დასრულებას ველოდებით, ჩვენ ვამბობთ „su“, შემდეგ „passwd“ და შევიყვანთ ახალ პაროლს root „a“-სთვის, რომლის მიხედვითაც დაუყოვნებლივ შევდივართ სისტემაში შესვლის ბრძანების გამოყენებით. თუ ეს არ გაკეთებულა, მცდელობა დაწყება ლინისიდასრულდება გამანადგურებელი მარცხით „სეგმენტაციის ხარვეზის“ ძახილით.

როდესაც ჩატვირთავთ Knoppix-ს თქვენი მყარი დისკიდან (რომელზეც შეგიძლიათ დააინსტალიროთ ტერმინალის ფანჯარაში აკრეფილი ბრძანებით "sudo knoppix-installer" LiveCD სესიის ქვეშ), გამოჩნდება დაწყების მენიუ ხელმისაწვდომი ბირთვების სიით (2.4)-1 და დააწკაპუნეთ ჩატვირთვის პარამეტრების დასაყენებლად - „2 vga=normal“. არ არის საჭირო სიტყვის "knoppix" დაწერა, რადგან ბირთვი უკვე შერჩეულია. ჩამოტვირთვის დასრულების შემდეგ, მიეცით შესვლის ბრძანება და შედით როგორც root (დავარაუდეთ, რომ ანგარიში ადრე შეიქმნა).

დებუგერი გაშვებულია ბრძანებით ./linsym –i, რის შემდეგაც ის მაშინვე გამოჩნდება ეკრანზე. თუ ეს არ მოხდა, შეეცადეთ მიუთითოთ "--verbose 3" გადამრთველი დიაგნოსტიკური შეტყობინებების საჩვენებლად.
ჩატვირთვის წარუმატებლობის ერთ-ერთი მიზეზი შეიძლება იყოს /boot/System.map ფაილის არარსებობა, რომელიც შეიცავს ბირთვის ფუნქციების მისამართებს. ჩამოტვირთვა ასევე ვერ მოხერხდება, თუ System.map-ის შიგთავსი არ ემთხვევა მიმდინარე ბირთვს, რაც შეიძლება მოხდეს, მაგალითად, მისი ხელახალი კომპილაციის დროს. ზოგიერთი სადისტრიბუციო შემდგენელი ან საერთოდ არ შეიცავს System.map-ს (მიაჩნია, რომ ეს გააძლიერებს სისტემის უსაფრთხოებას, რადგან Rootkits-ისთვის უფრო რთული იქნება syscals-ის ჩარევა), ან ისინი ათავსებენ რაღაც სრულიად არასწორად აქ და საერთოდ გაუგებარია სად. ის მოვიდა. ასეთ შემთხვევებში საკმარისია უბრალოდ ბირთვის ხელახლა შედგენა, გამართვის სიგნალის მითითებით System.map ფაილის გზაზე "-m" გადამრთველის გამოყენებით, თუ ის მდებარეობს სხვა ადგილას, გარდა /boot. ამგვარად, უსაფრთხოება არ იქნება კომპრომეტირებული და ლინისიშეუძლია მუშაობა!
გამართავი სისტემაში ბრუნდება ან ბრძანების გამოყენებით "x " კომბინაცია იძახებს გამართვას ნებისმიერი პროგრამიდან. თუმცა, სულაც არ არის ფაქტი, რომ ჩვენ აღმოვჩნდებით მის კონტექსტში, რადგან Linux არის მრავალფუნქციური სისტემა, რომელიც ცვლის პროცესებს ერთმანეთის მიყოლებით, ხოლო ADDR (კონტექსტის გადართვა) ბრძანებები არის "ლექსიკონში". ლინისიჯერ კიდევ არ არსებობს და როდის გამოჩნდება უცნობია. მაშასადამე, თქვენ უნდა იყოთ მზაკვრული, როდესაც დააყენეთ წყვეტის წერტილები სისტემურ ზარებზე, რომლებიც გამოიყენება კონკრეტული პროგრამის მიერ, ან პროცესის გარღვევით INT 03h მეთოდით, რაზეც ახლა ვისაუბრებთ.

“-x” გადამრთველი, რომელიც გადაცემულია იმავე linsym-ზე, პასუხისმგებელია დებუგერის გადმოტვირთვაზე (თუ ნამდვილად გსურთ მისი განტვირთვა).

მუშაობის საფუძვლები ლინისი

მათთვის, ვინც უკვე იმუშავა SoftICE-თან, მასტერინგი ლინისიარანაირ პრობლემას არ შეუქმნის. აქ გამოიყენება იგივე ბრძანებები: D – მეხსიერების ამოღება, E – მეხსიერების რედაქტირება, T – ნაბიჯ-ნაბიჯ მიკვლევა, P – კვალიფიკაცია ფუნქციების შეყვანის გარეშე, R – რეგისტრების ნახვა/მოდიფიცირება, BPM/BPX – მეხსიერების წვდომისთვის წყვეტის წერტილის დაყენება. /აღსრულება და ა.შ. ბრძანებების სრული სია შეიცავს როგორც ჩაშენებულ დახმარებას, რომელსაც ეწოდება HELP (სხვათა შორის, "HELP command_name" დამატებით ინფორმაციას გვაწვდის ბრძანებაზე), ასევე სტანდარტულ დოკუმენტაციაში.

მოდით დავაწკაპუნოთ და გადახედეთ პროცესების სიას, რომლებიც ნაჩვენებია PROC ბრძანებით, მიმდინარე პროცესით მონიშნული ლურჯად:

:პროც

1 0000 C1C3E000 SLEEPING 0 0 ინტ
2 0000 F7EE8000 SLEEPING 0 0 keventd
3 0000 F7EE2000 SLEEPING 0 0 ksoftirqd_CPU0
4 0000 F7EE0000 SLEEPING 0 0 ksoftirqd_CPU1
5 0000 F7ED0000 SLEEPING 0 0 kswapd
6 0000 F7EAA000 SLEEPING 0 0 bdflush
7 0000 F7EA8000 SLEEPING 0 0 განახლებულია
56 0000 F6A36000 SLEEPING 0 0 kjournald
1006 0000 F7A34000 RUNNING 0 0 automount
1013 0000 F68E6000 SLEEPING 0 0 ჭიქა
...
1105 0000 F6DDE000 SLEEPING 0 0 მკ
1106 0000 F6DD4000 SLEEPING 0 0 cons.saver

პროცესები, რა თქმა უნდა, კარგია, მაგრამ როგორ გავასწოროთ პროგრამები? უმარტივესი რამ არის ჩასვათ CCh მანქანის ინსტრუქცია, რომელიც შეესაბამება INT 03h ინსტრუქციას შესვლის წერტილში, მას შემდეგ რაც პირველად ჩაიწერეთ ორიგინალური ბაიტის შინაარსი. ეს შეიძლება გაკეთდეს ნებისმიერი თექვსმეტობითი რედაქტორით, მაგალითად, მე რამდენჯერმე ვახსენე
HTE.

ფაილის რედაქტორში ჩატვირთვის შემდეგ დააჭირეთ (რეჟიმი), აირჩიეთ elf/image, გადაიტანეთ კურსორი „entrypoint:“-ზე, დააჭირეთ (რედაქტირება) და შეცვალეთ პირველი ბაიტი CCh-ზე, შეინახეთ ცვლილებები (შენახვა) და დატოვეთ. დაპატჩირებული პროგრამის გაშვებისას ლინისიმაშინვე ჩნდება, შეწუხებულია CCh-ის მიერ წარმოქმნილი გამონაკლისით, რის შემდეგაც EIP მიუთითებს დასასრულს
CCh.

პროგრამის მდგომარეობა შესწორებული შესვლის წერტილით იმ მომენტში, როდესაც ჩნდება გამართვა

0023:080482C0 CC int 3
0023:080482C1 ED eax-ში, dx
0023:080482C2 5E pop esi
0023:080482C3 89E1 mov ecx, ესპ

კურსორი მიუთითებს in eax,dx (EDh) ინსტრუქციაზე, რომელიც არის დაყენებული xor ebp,ebp (31h EDh) ინსტრუქციის ფრაგმენტი. ახლა (თეორიულად) უნდა აღვადგინოთ ორიგინალური ბაიტი CCh-ზე 31 სთ-ზე შეცვლით, EIP რეგისტრი ერთით შევამციროთ და ჩვეულებისამებრ გავაგრძელოთ მიკვლევა.

მაგრამ ეს ასე არ იყო! ლინისი- ეს, რა თქმა უნდა, პორტია, მაგრამ მხოლოდ ძალიან უხეში, და მას არ შეუძლია შეცვალოს გვერდის სურათის მეხსიერება, თუნდაც პირველად გახსნათ კოდის სეგმენტი ჩასაწერად. არც E (რედაქტირება), არც F (შევსება) და არც M (მეხსიერების ასლი) არ მუშაობს! მაგრამ დასტაზე წერა მუშაობს და ეს სრულიად საკმარისია ჩვენთვის ჰაკერებისთვის.

ჩვენ გვახსოვს EIP რეგისტრის მიმდინარე მნიშვნელობა; დააკოპირეთ დაყენებული მანქანის ბრძანება სტეკის ზედა ნაწილში; აღადგინეთ CCh ბაიტი იქ; ჩვენ მას გადავცემთ კონტროლს, ვცვლით EIP მნიშვნელობას; ჩვენ ვახორციელებთ მას კვალიფიკაციის ერთი აქტის შესრულებით; და დააბრუნეთ EIP თავის ადგილზე, ანუ შემდეგ მანქანაში ბრძანებაზე:

ორიგინალური ბაიტის აღდგენა შეიცვალა INT 03h ინსტრუქციით

; მოდით შევხედოთ რა არის დასტაზე (სუფთა ცნობისმოყვარეობის გამო).
:დ ესპ-10
0018:BFFFEFC0 C0 82 04 08 00 00 00 00 5D 0C 00 40 DC EF FF BF

; ჩვენ ვაკოპირებთ დაყენებული მანქანის ბრძანებას სტეკის ზედა ნაწილში.
; რიცხვი 10h არის მანქანის ინსტრუქციის მაქსიმალური შესაძლო ზომა x86-ზე.
:m eip-1 L 10 esp-10

; ვნახოთ, როგორ შეიცვალა დასტა.
:დ ესპ-10
0018:BFFFEFC0 CC ED 5E 89 E1 83 E4 F0 50 54 52 68 F0 85 04 08

; ჰო! სტეკი ნამდვილად შეიცვალა, დროა CCh-ს გამოსწორება 31 სთ-ზე.
:e esp-10 31
დაუყოვნებელი მონაცემების რედაქტირება ჯერ არ განხორციელებულა.

; უი! პირდაპირი მონაცემების მინიჭება არ არის განხორციელებული Linice-ში,
; მაგრამ ჩვენ შეგვიძლია შეცვალოთ ნაგავსაყრელი ინტერაქტიულად (ასევე
; როგორც SoftICE-ში) ან მიეცით ბრძანება F esp-10 L 1 31, უბრალოდ გახსოვდეთ, რომ
; რომ, SoftICE-სგან განსხვავებით, Linice-ის გამართვა არ განაახლებს ნაგავსაყრელ ფანჯარას,
; ამიტომ F ბრძანების შესრულების შემდეგ შეიძლება გამოჩნდეს რომ
; უშედეგო; სინამდვილეში, ეს ასე არ არის, თქვენ უბრალოდ უნდა განაახლოთ
; გადაყარეთ D esp-10 ბრძანებით და ყველაფერი თავის ადგილზე დადგება.

; ჩვენ გადავცემთ კონტროლს სტეკში კოპირებულ ბრძანებას,
; გახსოვდეთ EIP რეგისტრის მნიშვნელობა.
:r eip (esp-10)
reg:eip=BFFFEFC0

; ჩვენ ვასრულებთ მოკვლევის ერთ მოქმედებას.
:ტ
0023:BFFFEFC2 5E pop esi

; როგორც ვხედავთ, EIP რეგისტრი გაიზარდა 2-ით (BFFFEFC2h - BFFFEFC0h) = 02h,
; შესაბამისად, შემდეგი ბრძანების მისამართია: 080482C1h - 01h + 02h = 080482C2h,
; სადაც 080482C1h არის EIP-ის საწყისი მნიშვნელობა პროგრამაში შესვლისას და 01h არის INT 03h-ის ზომა.

; ჩვენ დავაყენეთ EIP ბრძანებაზე დაყენებული ინსტრუქციის შემდეგ.
:r eip 80482C2
reg:eip=80482C2

ეს არის ცეკვები ტამბურით, რომელიც უნდა გააკეთო. და რა უნდა გააკეთოს? ასე რომ, ჩვენ დავახარისხეთ პროგრამების ჩატვირთვა გამართულში, ახლა ჩვენ დავყოფთ წყვეტის წერტილებს სისტემის ზარებად და ბირთვის ფუნქციებად.

exp ბრძანება ბეჭდავს ბირთვის მიერ ექსპორტირებულ სახელებს, რომელთაგან ნებისმიერი შეიძლება გამოჩნდეს გამონათქვამებში, მაგალითად "bpx do_bkr" უდრის "bpx C012C9E8".

ბირთვის მიერ ექსპორტირებული სახელების ჩამონათვალი

: ექსპ
ბირთვი
C0320364 mmu_cr4_ფუნქციები
C02AC3A4 acpi_disabled
C02AC8A0 i8253_lock
...
C012BDA8 do_mmap_pgoff
C012C764 do_munmap
C012C9E8 do_brk
C011E990 გასასვლელი_მმ
C011E69C exit_files

სისტემური ზარები უფრო რთულია. პირდაპირი მხარდაჭერა ლინისიის აქ არ არის (მაგრამ ეს უნდა იყოს, Linux-ის სპეციფიკის გათვალისწინებით), ასე რომ ეს საქმე ხელით უნდა გაკეთდეს.

syscall ცხრილი, როგორც მოგეხსენებათ, არის ორმაგი სიტყვების მასივი, რომელიც იწყება მისამართიდან sys_call_table (ეს ცვლადი ექსპორტირებულია ბირთვის მიერ).

სისტემის ზარის ცხრილი

; ჩვენ გადავრთავთ გამართვას ორმაგი სიტყვის ჩვენების რეჟიმში.
:დდ

; ჩვენ ვაჩვენებთ ცხრილს ეკრანზე.
:d sys_call_table
0018:C02AB6A8 C0126ACC F8932650 F89326A0 C013DC10
0018:C02AB6B8 C013DD18 C013D5C8 C013D724 C011F3BC
0018:C02AB6C8 C013D664 C014A8E0 C014A3B4 F893020C

ცხრილის თითოეული ელემენტი შეესაბამება საკუთარ სისტემურ ზარს და თითოეულ ზარს აქვს საკუთარი ნომერი, რომელიც შეგიძლიათ იხილოთ ფაილში /usr/include/sys/sycall.h, მაგრამ უმჯობესია ამის გაკეთება არა Linux-ის ქვეშ. , სადაც პირდაპირი ნომრები არ არის, მაგრამ ერთი და იგივე ფაილის სესხება BSD-დან - ერთი და იგივე, მთავარი სისტემის ზარების ნომრები ყველა სისტემაზე იგივეა. კერძოდ, ღია სისტემური ზარი არის ნომერი 5.

გახსნაზე წყვეტის წერტილის დასაყენებლად, თქვენ უნდა გაარკვიოთ მისი მისამართი, რომელიც მდებარეობს სისტემის ზარის ცხრილის მეხუთე ორმაგ სიტყვაში, ნულიდან დათვლა და ტოლი (ამ შემთხვევაში) C013D5C8h.

წყვეტის წერტილის დაყენება ღია სისტემურ ზარზე

; დააყენეთ წყვეტის წერტილი ღია სისტემურ ზარზე,
:bpx C013D5C8
; გადით გამართვისგან,
:x
...
# გახსენით ფაილი,
...
; გამართავი მაშინვე ჩნდება და გვეუბნება ამის შესახებ,
:შესვენების წერტილი BPX 01-ის გამო

; ჩვენ ვაძლევთ proc ბრძანებას, რათა დავრწმუნდეთ, რომ ჩვენ ვართ ჩართული ჩვენს პროცესში.
:პრო
PID TSS ამოცანის მდგომარეობის uid gid სახელი
1049 0000 F6364000 ძილი 0 0 გეტი
1145 0000 F61CC000 SLEEPING 0 0 მკ
1146 0000 F614A000 SLEEPING 0 0 cons.saver

ამგვარად, ადვილია უკვე გაშვებული პროცესების გატეხვა, მათ მიერ გამოყენებული სისტემურ ზარებზე წყვეტის წერტილების დაყენება და ასევე ბევრი სხვა რამ, რაც სასიცოცხლოდ მნიშვნელოვანია ჰაკერებისთვის.

დასკვნა

აშკარა ტენიანობის მიუხედავად, ლინისისაკმაოდ შესაფერისია დაცული აპლიკაციების გამართვისთვის, თუმცა საკმაოდ ხშირად თქვენ უნდა მიმართოთ გამოსავალს, რომელიც ავტომატურად სრულდება ნორმალურ გამართავებში. Ამიტომაც ლინისისაერთოდ არ ცვლის gdb-ს, არამედ მხოლოდ ავსებს მას.

სტატიების ეს სერია ორი მიზეზის გამო გამოჩნდა. პირველ რიგში, მომწონს პროექტთან მუშაობა HackSysExtremeVulnerableDriver. მეორეც, მივიღე ბევრი სურვილიამ თემის გასაშუქებლად.

ამ სერიის დასაწერად გამოყენებული ყველა კოდი ჩემს საცავშია.

ამ სტატიების სერიაში ჩვენ შევხედავთ Windows-ში ბირთვის დონის ექსპლოიტების ჩაწერას. მნიშვნელოვანია აღინიშნოს, რომ საქმე გვექნება ცნობილ მოწყვლადობასთან და არ არის საჭირო საპირისპირო ინჟინერია (ყოველ შემთხვევაში მძღოლისთვის).

მოსალოდნელია, რომ ყველა სტატიის წაკითხვის შემდეგ თქვენ გეცოდინებათ დაუცველობის ყველა ყველაზე გავრცელებული კლასი და ექსპლუატაციის მეთოდები, ასევე შეძლებთ ექსპლოიტების გადატანას x86 არქიტექტურიდან x64 არქიტექტურაზე (თუ ეს შესაძლებელია) და გაეცნობით დაცვის ახალ მეთოდებს. Windows 10-ში.

ბირთვის გამართვის წრე

მომხმარებლის დონის გამართვისგან განსხვავებით, რომელიც აჩერებს ერთი პროცესის შესრულებას, ბირთვის დონის გამართვა მოიცავს მთელ სისტემას და ჩვენ ვერ შევძლებთ ამ მეთოდის გამოყენებას. შესაბამისად, ჩვენ გვჭირდება ცალკე გამართვის მანქანა, რომელსაც შეუძლია დაუკავშირდეს სისტემას, სადაც ხდება ბირთვის გამართვა, მეხსიერების და ბირთვის სტრუქტურების ნახვა და ასევე სისტემის ავარიების დაფიქსირება.

დამატებითი მასალა შესასწავლად:

ბირთვის დაუცველობების გამოყენება

ეს პროცესი ბევრად უფრო სახალისოა, ვიდრე მომხმარებლის J დონეზე მუშაობა.

მთავარი მიზანია ბირთვის კონტექსტში პრივილეგირებული შესრულების მიღწევა. შემდეგ კი ყველაფერი ჩვენს ფანტაზიაზეა დამოკიდებული, ხელნაკეთი ლუდით წვეულებიდან დაწყებული სახელმწიფოს მიერ დაფინანსებული მავნე პროგრამების დანერგვამდე.
ზოგადად, ჩვენი ამოცანაა მივიღოთ ჭურვი სისტემის პრივილეგიებით.

ამ სერიის სტატიების თემები

ნაწილი 1: თქვენი სამუშაო გარემოს შექმნა

სამი ვირტუალური მანქანის და სისტემის კონფიგურაცია, რომელიც იმოქმედებს როგორც გამართვა.
WinDBG გამართვის კონფიგურაცია.

ნაწილი 2: დატვირთვები

გამოიკვლიეთ ყველაზე გავრცელებული დატვირთვები. მომდევნო ნაწილები განიხილავს კონკრეტულ დაუცველობას და, საჭიროების შემთხვევაში, უზრუნველყოფს ამ სტატიის ბმულებს.

დარჩენილი ნაწილები.

მოწყვლადობის გათვალისწინება.

ბირთვის ექსპლოიტის განვითარების სასიცოცხლო ციკლი

მოწყვლადობის პოვნა. ეს თემა ამ სერიაში არ იქნება განხილული, რადგან ჩვენ უკვე ვიცით ზუსტად სად არის ხარვეზები.
აღსრულების ძაფის ჩაჭრა. ზოგიერთი დაუცველობა მოიცავს კოდის შესრულებას და ზოგიერთს აქვს დამატებითი მოთხოვნები.
პრივილეგიების ესკალაცია. მთავარი მიზანი არის სისტემის პრივილეგიებით გარსის მიღება.
აღსრულების ძაფის აღდგენა. ბირთვის დონეზე გადაუმოწმებელი გამონაკლისები იწვევს სისტემის ავარიას. თუ არ აპირებთ DoS შეტევის ექსპლოიტის დაწერას, ეს ფაქტი უნდა გაითვალისწინოთ.

სამიზნე სისტემების ტიპები

ჩვენ ვიმუშავებთ დაუცველობებთან შემდეგ სისტემებში (კონკრეტული ვერსია არ არის მნიშვნელოვანი):

Win7 x86 VM
Win7 x64 VM
Win10 x64 VM

დავიწყოთ x86 არქიტექტურით, შემდეგ კი ექსპლოიტს გადავიტანთ Win7 x64 სისტემაში. ზოგიერთი ექსპლოიტი არ იმუშავებს Win10 მანქანებზე ახალი დაცვის არსებობის გამო. ამ შემთხვევაში ჩვენ ან შევცვლით ექსპლოიტის ლოგიკას, ან გამოვიყენებთ სრულიად განსხვავებულ მიდგომას.

გამოყენებული პროგრამული უზრუნველყოფა:

ჰიპერვიზორი (ბევრი ვარიანტი).
Windows 7 x86 VM
Windows 7 x64 VM
Windows 10 x64 VM

გამართვის სისტემების დაყენება

გამართვის სისტემები, რომლებთანაც ვიქნებით ურთიერთქმედება, შექმნილია დაუცველი დრაივერის ჩატვირთვაზე. ეს მანქანები ხშირად იშლება, რადგან ბირთვში არსებული გამონაკლისების უმეტესობა ხელს უწყობს ამ ტიპის ფენომენს. თქვენ უნდა გამოყოთ საკმარისი ოპერატიული მეხსიერება ამ სისტემებისთვის.

თითოეულ მოწყობილობაზე, რომელიც იქნება გამართული, თქვენ უნდა გააკეთოთ შემდეგი:

VirtualKD დირექტორიაში გაუშვით ფაილი target\vminstall.exe. დაემატება ჩატვირთვის ახალი ჩანაწერი და ხელმისაწვდომი იქნება გამართვის ფუნქციები და ავტომატური კავშირი სისტემაზე დაინსტალირებული VirtualKD სერვერთან, რომელიც მოქმედებს როგორც გამართვის ფუნქცია.

Windows 10 VM-ის შემთხვევაში, თქვენ უნდა ჩართოთ ტესტის ხელმოწერის რეჟიმი, რომელიც საშუალებას გაძლევთ ჩატვირთოთ ხელმოუწერელი დრაივერები ბირთვში.

bcdedit /set testsinging ბრძანების გაშვების და გადატვირთვის შემდეგ, სამუშაო მაგიდაზე გამოჩნდება „ტესტი რეჟიმი“.

HEVD მოდულის მოკლე აღწერა

DriverEntry პროცედურა არის საწყისი პროცედურა თითოეული მძღოლისთვის:

NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) (
UINT32 i = 0;
PDEVICE_OBJECT DeviceObject = NULL;
NTSTATUS სტატუსი = STATUS_USUCCESSFUL;
UNICODE_STRING DeviceName, DosDeviceName = (0);

UNREFERENCED_PARAMETER (RegistryPath);
PAGED_CODE();

RtlInitUnicodeString(&DeviceName, L"\\Device\\HackSysExtremeVulnerableDriver");
RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\HackSysExtremeVulnerableDriver");

//მოწყობილობის შექმნა
სტატუსი = IoCreateDevice(DriverObject,
0,
&მოწყობილობის სახელი,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
მცდარი,
&DeviceObject);

ეს პროცედურა შეიცავს ზარს IoCreateDevice ფუნქციაზე, რომელიც შეიცავს დრაივერის სახელს, რომელსაც გამოვიყენებთ კომუნიკაციის დროს.
საჭირო სტრუქტურები და ფუნქციის მაჩვენებლები დაემატება DriverObject ობიექტს.
ჩვენთვის მნიშვნელოვანია DriverObject->MajorFunction პროცედურასთან დაკავშირებული ფუნქციის მაჩვენებელი, რომელიც პასუხისმგებელია IOCTL (I/O Control) დამუშავებაზე;
HEVD-ში ამ ფუნქციას ეწოდება IrpDeviceIoCtlHandler, რომელიც არის დიდი პირობითი გამოხატულება მრავალი განშტოებით თითოეული IOCTL-ისთვის. თითოეულ დაუცველობას აქვს უნიკალური IOCTL.

მაგალითი: HACKSYS_EVD_IOCTL_STACK_OVERFLOW არის IOCTL, რომელიც გამოიყენება სტეკის გადინების ექსპლოიტის გასააქტიურებლად.

ამით მთავრდება პირველი ნაწილი. მომდევნო სტატიაში ვისაუბრებთ დატვირთვის შესახებ. ამ დროისთვის, ერთადერთი ხელმისაწვდომი დატვირთვაა, რომელიც შექმნილია ტოკენების მოსაპარად, რომელიც გამოყენებული იქნება მესამე ნაწილში.

P.S. მესმის, რომ ბევრი სირთულე და პრობლემა შეიძლება შეგხვდეს. ვინაიდან ეს სერია ფოკუსირებულია ექსპლოიტების განვითარებაზე, თქვენ თავად მოგიწევთ ყველა დაკავშირებული პრობლემის გადაჭრა. თუმცა, თქვენ შეგიძლიათ დასვათ ნებისმიერი შეკითხვა კომენტარებში.

ანოტაცია

Მთავარი ნაწილი

სიმბოლოები ბირთვის გამართვისთვის

შეატყობინეთ შეცდომას

ტექსტი, რომელიც გაეგზავნება ჩვენს რედაქტორებს:

თქვენი კომენტარი (სურვილისამებრ):