به نام خدا


برنامه نویسی با هگز ادیتور بخش 6


نقطه ی ورودی :


در پست قبلی قرار را بر این گذاشتم که در مورد نقطه ی ورودی که اولین کدی است که توسط برنامه نویس زبان سطح بالا یا زبان اسمبلی می نویسد و قرار است بعنوان اولین کد از سکشن کد اجرا شود ، قدری بنویسم ! 


ببینید متاسفانه شرکت مایکروسافت ، معماری نرم افزارها و درایورها و کتابخانه های ویندوز را بطور کامل با زبانهای سطح بالا خصوصا زبانهای سی و سی پلاس پلاس ، طراحی کرده و ساخته است . 


لذا حتی در اسمبلرهایی همچون masm32  نیز شاهد چیزهایی تحت عنوان WinMain    یا  DllMain هستیم که این دو عبارت توسط زبان برنامه نویسی سی پلاس پلاس ساخته شده و بر برنامه نویسان تحمیل شده اند . 


این دو عبارت را در زبان اسمبلی نیز متاسفانه شاهد هستیم . البته در اسمبلر  RosAsm که یک اسمبلر کاملا خالص و تمیز و اصیل می باشد و هیچگونه وابستگی به زبانهای سطح بالا ندارد و هرگز از زبانهای سطح بالا تقلید نکرده است بجای این دو کلمه از کلمه ی main  یا  MainWindowProc استفاده می کنیم . 


لذا به همین دلیل به رنه تورنویس ، تهمت زدند و گفتند که این اسمبلری که ساخته ای درواقع شکل جدید از زبان سی می باشد !!


این درحالیست که main در RosAsm هرگز  یک تابع زبان سی نیست بلکه فقط یک برچسب یا نقطه ورودی می باشد. به همین سادگی . 


آن فرم کلیشه ای تابع main در زبانهای سی و سی پلاس پلاس را فراموش کنید . 


در زبان اسمبلی شما این اختیار را دارید که به هر سبکی که دلتان بخواهد برنامه نویسی کنید . 


در زبان ماشین یعنی در محیط هگز ادیتور ، اصلا هیچکدام از این مزخرفات دیده نمی شود !


اینجا فقط با کدهای خالص زبان ماشین مواجه هستیم . 


در اینجا ما فقط با یک آدرسدهی ساده ، نرم افزار را می سازیم . به همین راحتی . 


نقطه ی ورودی در زبان ماشین در محیط هگز ادیتور هیچ علامتی ندارد بلکه یک کد زبان ماشین است که با آدرس ، مشخص می شود . 


مثلا ما می توانیم نقطه ی ورودی و البته اولین کدی که باید اجرا شود را در آدرس  زیر  تعیین نماییم و با دست ، اولین کد را در سکشن کد بدین شکل بنویسیم :



Address     code    Assembly


00000200     6a        push


00000201     00        MB_OK  



همانطور که در بالا ملاحظه می فرمایید ، ما می توانیم در محیط هگز ادیتور ، اولین بایت از سکشن کد را که همان نقطه ی ورودی است به شکلی که می بینید تعیین کنیم . 


یعنی در آدرس  00000200  که معادل با  512 بایت از حجم نرم افزار می باشد ، با نوشتن کد 6a اولین کد اجرایی  یعنی نقطه ی ورودی  را دقیقا در اولین بخش از سکشن کد بنویسیم . 


بعد دومین کد اجرایی نقطه ی ورودی را در دومین بخش از سکشن کد می نویسیم و الی آخر ...


من خودم شخصا دوست دارم تا سرحد ممکن ، نرم افزار را کوچک و فشرده کنم البته با دست نه با نرم افزارهای مهندسی معکوس . 


زیرا وقتی که خودم با دست ، اقدام به بهینه سازی معماری می نمایم دقیقا می فهمم که دارم چه کاری انجام می دهم و قلق کار به دستم می آید ولی ابزارهای مهندسی معکوس عملا بصورت کورمال کورمال ، اینکار را برایم انجام می دهند و ای بسا که باعث خراب شدن نرم افزار بشوند! 


من شخصا هرگز از ابزارهای مهندسی معکوس ، برای فشرده سازی نرم افزارها استفاده نمی کنم و ترجیح می دهم فرایند فشرده سازی را شخصا با دستان خودم انجام دهم تا دقیقا بفهمم که در حال انجام چه کاری هستم و با چشم کاملا باز ،  بهینه سازی کنم تا خدای ناکرده نرم افزارم خراب نشود . 


مهمترین چیز در هگز ادیتور ، آدرسدهی می باشد . در مورد پردازنده ی اینتل ، متاسفانه مجبوریم همه چیز را بصورت معکوس ، آدرسدهی کنیم !


ما در هگز ادیتور ، معمولا بجای ادرس معمولی ( آفست )  از آدرس مجازی رابطه ای استفاده می کنیم . به این نوع آدرس ،  آدرس مجازی نسبی ( خویشاوندی ) نیز گفته می شود که بصورت  RVA  نامیده می گردد . 


اسکلت کلی نرم افزارهای ویندوز شامل دو بخش اصلی است :


1- بخش تابع اصلی یا همان main که به آن نقطه ی ورودی نیز گفته می شود 


2- بخش پیامهای ویندوز که در مورد رویدادها و رخدادهایی است که در ویندوز انجام می شود و نوعی برنامه نویسی شیئ گرا را برای ما  تعیین می کند . 



مثلا در زبان اسمبلی  می توانیم چنین کدی را با کمک  ماکرو  بنویسیم :



IF  umsg ==  WM_CLICK  


push 0 


call  Exitprocess 


end if 


این ماکرو را که معمولا در masm32 می بینیم و البته سایر اسمبلرها نیز تا حدودی شبیه به همین را قبول می کنند ، به ما می گوید که اگر کاربر روی فرم اصلی برنامه  ، کلیک کرد برنامه بسته شود و از حافظه ی رم خارج شود و کاربر به محیط زبان برنامه نویسی یا به محیط ویندوز بازگردد . 


این یک نوع برنامه نویسی شیئ گرا در زبان اسمبلی است که بصورت ذاتی از قبل در این زبان نهادینه شده است . 


برخلاف زبان سی  که شیئ گرا نبود ، زبان اسمبلی از همان روز اول شیئ گرا بود و دانشمندان با کمک زبان اسمبلی ، توانستند زبانهای برنامه نویسی شیئ گرا از قبیل اسمالتاک یا بیسیک یا پاسکال را بسازند . 


اما زبان سی یک انحراف بزرگ در دنیای برنامه نویسی محسوب می شود زیرا اصلا از این قاعده ی استاندارد پیروی نکرد لذا شیئ گرا نبود و بعد با شیئ گرا کردن اش و کلاس بندی کردنش انرا به سی پلاس پلاس تبدیل کردند که من تا این لحظه چیزی به نام شیئ گرایی را در زبان سی پلاس پلاس ندیده ام ! 



بدبختانه دنیس ریچی یک انحراف بسیار بزرگ فکری را در دنیای برنامه نویسی و سیستم عامل ایجاد کرد طوریکه زبانهای قدرتمندی همچون اسمبلی و پاسکال نادیده گرفته شدند و زبان سی بعنوان مادر زبانهای برنامه نویسی تا به امروز بکار رفته است . 


چیزهایی همچون کتابخانه های زمان اجرا  یا همان  Run Time  که یک مفهوم پیچیده و گنگ است عملا برنامه نویسی را پیچیده کرده است . 


برهمین اساس ، من معتقدم که تنها راه نجات از شر زبانهای سطح بالا خصوصا سی و سی پلاس پلاس و جاوا و  پایتون و ....  و مفاهیم مزخرفی که در این زبانها نهادینه شده است باید به هگز ادیتور پناه ببریم . 


در اسمبلر RosAsm  ، برای  ایجاد سکشن کد ، از برچسب main استفاده می شود ولی برای شیئ گرایی و پردازش پیامها و رویدادهای ویندوز از برچسب MainWindowProc استفاده می شود . 


البته من خودم شخصا این دومی را اصلا بکار نمی گیرم و تمام کد برنامه ام را زیر همان main   می نویسم و خودم را خلاص و راحت می کنم ! 


در مورد فایلهای dll که همان کتابخانه های ویندوز هستند ، مقدار فیلد مربوط به نقطه ی ورودی باید برابر با صفر باشد . زیرا این نوع فایلها نمی توانند خودشان شخصا اجرا شوند و به فایلهای exe نیاز  دارند . 


اما در مورد فایلهای exe یعنی نرم افزارها ، باید به این فیلد ، مقدار بدهیم . یعنی باید یک عدد صحیح و درست که مطابق با ادرس باشد را بنویسیم . 


مشکلات اصلی دقیقا از همینجا شروع می شود . یعنی ما باید برای تعیین آدرس محل قرار گیری توابع ویندوز ،  از معکوس آدرس مجازی رابطه ای استفاده کنیم !!!


یعنی نه فقط  آدرس مطلق یا آفست ، کارایی  کامل و همه جانبه  ندارد بلکه حتی آدرس مجازی رابطه ای نیز کافی نیست و باید این آدرس را طبق خواسته ی پردازنده ی اینتل ، معکوس نیز بکنیم !!!


این فرایند معکوس سازی را باید تا آخرین سکشن و با دست انجام دهیم  و گرنه پردازنده ی اینتل که عاشق معکوس سازی است کد  برنامه  را اجرا نمی کند !!



با این وضعیت ، شما حتی یک برنامه ی کادر پیام ساده را در مدتی کمتر از دو هفته نمی توانید بسازید !!


من در این مورد تجربه دارم ! 


اما من نمی خواهم خودم و شما را مایوس و ناامید کنم . 


بهرحال معماری ویندوز برخلاف معماری بسیاری از سیستم عاملها ، به شدت انعطاف پذیر است و راههای فراوانی برای ساده سازی این فرایند در پیش پای ما هستند . 


کافیست کمی فکر کنیم و صبور و خونسرد باشیم . 


همانطور که در پستهای قبلی گفتم ، تدریس برنامه نویسی با هگز ادیتور دستکم هشت سال طول می کشد . 


یعنی من قصد دارم در مدت هشت تا ده سال و به تدریج در این وبلاگ ، روش برنامه نویسی با هگز ادیتور را بصورت عملی  ، به شما یاد بدهم !!



به همین دلیل بود که گفتم اگر بتوانید این مدت طولانی را تحمل کنید به یک مرتاض واقعی تبدیل می شوید . 



شاید بگویید : خب چرا از زبان اسمبلی استفاده نمی کنی که اینهمه وقت و انرژی و پول هدر نرود ؟؟؟



در جواب باید بگویم :  زیرا هیچکدام از کامپایلرهای اسمبلی ، کامل  و بی نقص نیستند و به  درد مهندسی معکوس نمی خورند . مهندسی معکوس را با دست باید انجام داد نه با ابزارهای کرک . 


مشکل در اینجاست که همه ی دنیا خیال می کنند برای  مهندسی معکوس لابد باید از ابزارهای کرک استفاده کرد . در حالیکه مهندسی معکوس یک فرایند کاملا دستی می باشد . 


برنامه نویسی با هگز ادیتور بصورت همزمان با مهندسی معکوس دستی ، امکان پذیر می شود . 


بدون مهندسی معکوس دستی ، هرگز نمی توانید در هگز ادیتور برنامه نویسی کنید . اگر هم بتوانید اینکار را انجام دهید خروجی مناسبی در پی نخواهد داشت و رشته ی کار از دستتان در می رود. 


به همین دلیل است که از زبان اسمبلی استفاده نمی کنم و ترجیح می دهم از هگز ادیتور استفاده نمایم . 

زیرا زبان اسمبلی به ندرت از مهندسی معکوس پشتیبانی می کند . 



من مجبورم چرخ را از اول اختراع کنم . یعنی باید معماری نرم افزارهای ویندوز را با دست و با آزمون و خطا  ، از اول  بازنویسی کنم . 


اینکار واقعا خسته کننده و وقتگیر است و شاید چند سال طول بکشد . لذا هیچ قولی نمی توانم به شما بدهم . انتظار وقوع هیچ معجزه ای را نداشته باشید . 


بارها و بارها به همین دلیل ،  به محض فکر کردن به هگز ادیتور ، از میانه ی راه برگشتم زیرا خسته و بی حوصله شده بودم . 


اما اینبار برای خودم  به مدت هشت تا ده سال  وقت خریده ام ! 


یعنی هیچ عجله ای ندارم .  با صبر و متانت و حوصله و با مطالعه ی بیشتر و عمیقتر و آزمون و خطا ، راه ساده تری پیدا می کنم و کار را به سرانجام می رسانم . 


من برای تدریس برنامه نویسی با هگز ادیتور  ، تعداد چهار هزار پست و هشت سال وقت ، در نظر گرفته ام . 


یعنی یک برنامه ریزی بلند مدت را برای خودم تعیین کرده ام . 


باید صبور باشیم . 


اگر خسته و بی حوصله هستید و نمی توانید بیش از این صبر کنید پس باید بدانید که وبلاگ وحیدمی دیگه به درد شما نمی خورد و  می توانید این وبلاگ را ترک کنید و خودتان را نجات دهید. 


بله ، وبلاگ وحیدمی دیگه کارایی خودش را از دست داده است و شاید به زودی متوقف شود یا شاید بتواند هشت سال دوام بیاورد . هیچ چیز معلوم نیست . من هیچ قولی به شما نمی دهم . 


اگر دیدم باز هم به بن بست خورده ام یا آپدیتهای ویندوز 10  سر راهم سنگ اندازی می کنند و مایکروسافت در کارم دخالت می کند و قادر به اتمام این پروژه نیستم  بی سرو صدا  خداحافظی می کنم . 


اگر مایکروسافت  دخالت و مخالفت نکند می توانم در مدت هشت سال ، این پروژه را به اتمام برسانم وگرنه باید قید وبلاگ نویسی را بزنم . 


برنامه نویسی با هگز ادیتور ، کماکان در این وبلاگ تدریس می شود اما به مرور زمان و با صبر و حوصله . 


من قبلا توانسته ام با تمام دشواریهای اینکار کنار بیایم و نرم افزار بسازم . شاید اینبار نیز بتوانم . اما همه چیز به نقشه های شیطانی مایکروسافت مربوط می شود . 


اگر شکست خوردم بدانید که من بی تقصیرم و این مایکروسافت بود که مانع تراشی کرد . 



+


بهرحال من در برنامه نویسی با هگز ادیتور در محیط ویندوز ایکس پی ، تجربه دارم . اما بهرحال ویندوزهای نسل جدید  با ویندوزهای قدیمی از زمین تا آسمان فرق دارند . 


پس شاید اینبار علاوه بر تجربه به یکسری فاکتورهای دیگه هم نیاز داشته باشم . 


پس باید بیشتر مطالعه و تحقیق کنم تا موانع را شناسایی و حذف کنم . 


شاید لازم باشد ابتدا ویندوز 10 را از لوث وجود جاسوس افزارها و فناوری منحوس دات نت فریمورک   پاکسازی کنم . 


بله شاید لازم باشد ویندوز را پاکسازی کنم و بعد برگردم به اینجا و کارم را ادامه دهم . 


+


در مورد سکشن کد و نقطه ی اجرایی ، اگر مطلبی مفید پیدا کردم حتما  در پستهای بعدی می نویسم وگرنه  کار را ادامه می دهم تا به سایر سکشنها برسم . 


فعلا باید مستندات مربوط به معماری نرم افزارهای ویندوز را مجددا و با دقت بیشتری مطالعه و ترجمه نمایم تا بتوانم شاخ غول مایکروسافت را بشکنم و این شرکت را سر جایش بنشانم . انشاا...