FARHOOD
12-19-2012, 19:24
چک سام (Checksum) در رسیورهای استارست چیست ؟
این اصطلاح از ترکیب دو واژه "Check" به معنی مقایسه و تطبیق و "Sum" به معنی مقدار ایجاد شده است .
چک سام عموما قسمتی از یک فایل است که وظیفه آن حفاظت از کل فایل در برابر تغییرات میباشد . این قسمت از فایل شامل بایت یا بایتهایی (تیبلی) است که وظیفه آن نگهداری مقدار چک سام کل فایل منهای خود همین بایتها و ( Ignore Bytes ) میباشد . به زبان ساده تر میتوان گفت که اگر چک سام کل یا یک قسمت از فایلی را بر اساس الگوریتمی خاص محاسبه کرده و خروجی آن را در محلی از یک فایل و در لابلای بایتها یا پکتها قرار دهیم ، چک سامی برای فایل تعریف کرده ایم که در این فایل ،اگر تنها مقدار چک سام قسمتی از فایل را محاسبه کرده باشیم ، به قسمت محاسبه نشده این فایل اصطلاحا ( Ignore Bytes ) گقته میشود . یعنی این قسمت در محاسبه چک سام منظور نشده است و از آن چشم پوشی کرده ایم . پس در محاسبه بعدی چک سام هم بایستی از آن چشم پوشی کنیم .
مثال کاملا واضح :
در امیولیتور سامسونگ 9500 محل قرار گیری چک سام در بایتهای ابتدایی 10 و 11 فایل قرار دارند . اگر هر آفست را بر مبنای هگزادسیمال (16) در نظر بگیریم ، این چک سام در آفست اول و در بایتهای 10 و 11 اميوليتور قرار گرفته است . پس از تغییرات در پیکر فایل ، نوبت به محاسبه چک سام میرسد . ما در امولیتورسامسونگ با چک سام از نوع الگوریتم Chechsum16 بیتی روبرو استیم .
نکته : هر 1 بایت (Byte) برابر با 8 بیت (Bit) دیتا میشود .
پس چک سام 16 بیتی ما برابر با دوبایت میشود ! که گفتیم مکان قرار گیری آن در آفست نخست و در بایتهای 10 و 11 قرار دارد .
ولی در امیولیتور سامسونگ 9500 ما با بایتهای خنثی ( Ignore Bytes ) هم روبرو هستیم و میدانید که در الگوریتم محاسبه چک سام ، از بایتهای نامبرده باید چشم پوشی کرد . محل این بایتهای ایگنور در امیولیتور سامسونگ همان آفست نخست میباشد . یعنی آفست نخست این امیولیتور که 16 بایت فرض میشود شامل دو بایت چک سام و 14 بایت خنثی (Ignore Bytes) است . پس برای محاسبه چک سام این فایل بایستی آفست نخست را اصلا محاسبه نکنیم . به گویش ساده تر ما از آفست دوم یا بایت 17 تا آفست آخر فایل را بر اساس الگوریتم Chechsum16 بیتی محاسبه و مقدار بدست آمده را در بایت 10 و 11 آفست نخست (محل قرار گیری مقدار چک سام) مینویسیم ... همین !
برخی از الگوریتمهای چک سام :
برخی از الگوریتمهای سادهء چک سام ، الگوریتم 8 - 16 - 32 - 64 بیتی و CRC32 - CRC16 بیتی و ... میباشند .
دقت کنید که بین الگوریتم چک سام و الگوریتم CRC تفاوتهایی هم هست که بعدها براتان توضیح خواهم داد .
چک سام بر اساس هر الگوریتمی که باشد تعداد بیتهای (Bit) آن تقسیم بر 8 برابر با تعداد بایت (Byte) میشود .
مثلا اگر چک سام بر اساس الگوریتم Checksum8 بیتی باشد مقدار چک سام ما 1 بایت است .
اگر چک سام بر اساس الگوریتم Checksum16 باشد مقدار چک سام ما 2 بایت است .
و اگر چک سام بر اساس الگوریتم Checksum32 باشد مقدار چک سام ما 4 بایت است ... الی آخر ...
توضیحات بیشتر :
بطور کلی هر بیت از فایل دارای چک سام خود است که بر اساس الگوریتمی استاندارد و مطلق محاسبه میشود .از سوي دگر اگر در یک فایل چک سام ما بر اساس الگوریتم CRC16 بیتی باشد ، از آنجاییکه هر 8 بیت برابر با یک بایت میشود پس چک سام ما دو بایت از فایل را شامل میشود . حال جای قرار گیری آن در فایلکجاست ؟ این یکی از پرسشهای سخت است که لازمه درک آن ، محاسبات پیچیده ریاضیات و مهندسی معکوس میباشد و یا دسترسی به سورس (Source) آن برنامه میباشد .
الگوریتم ها برای محاسبه چک سام بر اساس محاسبات ریاضی و بصورت استاندارد و در دسترس میباشند .
دانستنیهای لازم برای محاسبه چک سام :
برای محاسبه چک سام یک فایل ، نخست باید بدانیم که چک سام ما بر اساس چه الگوریتمی محاسبه شده است .
سپس بایستی مکان قرار گیری چک سام را شناسایی کنیم .
... و در آخر هم باید بدانیم که آیا با " Ignore Bytes " هم طرف هستیم یا نه و اگر بله مکان آن کجاست ؟؟؟
اکنون در زمان تغییرات معقول یک فایل میتوانیم به سادگی چک سام تازه آنرا هم محاسبه و جایگزین کنیم .
گاهی وقتها هم در ویرایش یک فایل برای تعدیل مقدار چک سام ، بایتهایی به انتهای فایل اضافه میکنند که البته در این راه هم به دانستن الگوریتم چک سام در آن فایل و هم به اطلاعات پیش زمینه دیگری نیاز داریم . اين موضوع فعلا مورد بحث ما نيست ...
------------------------------------
مثالی بسیار مهم و قابل توجه برای دوستان گرامی
برای مثال در امیولیتور استارست 200 ، بایتهایی که مقدار (Value) چک سام در آن نگهداری میشود بایت 7 و 8 از آفست نخست امیولیتور میباشد . در این امیولیتور ما با الگوریتم Checksum16 روبرو هستیم .
پچها در استارست 200 معمولا حدود 800 تا 850 کیلو بایت حجم دارند ، اگر ما این امیولیتور را به رسیور منتقل و سپس دوباره آنرا به کامپیوتر آپلود (Dump) کنیم ، حجم آن حدودا برابر با 1,569,856 بایت خواهد شد ! يعني چيزي حدود دوبرابر .
( دلیل آن این است که در زمان بازگرداندن پچ ، اطلاعات دیگر درون فلش هم به کامپیوتر منتقل میشوند كه اين هم فعلا مورد بحث ما نيست)
اکنون آنرا در برنامه ادیتوری فرامیخوانیم . میبینیم که 64 بایت نخستین امیولیتور ( به جز بایتهای 7 و 8 که محل قرار گیری مقدار چک سام این امیولیتور است )شامل Ignore Bytes میشوند .
از طرفی اگر سری به انتهای این فایل بزنیم ، میبینیم که دقیقا 1 کیلوبایت ( دقیقا 1024 بایت ) آخر این امیولیتور هم جزء همان بایتهای ایگنور محسوب میشوند ! به گویش بهتر میتوان گفت که 64 بایت ابتدایی و 1024 بایت انتهایی فایل نامبرده در بالا ، در الگوریتم چک سام محاسبه نمیشوند . اکنون پس از دستکاری در این امیولیتور ، تنها کافیست که بر اساس الگوریتم Checksum16 چک سام کل فایل را منهای 64 بایت نخستین و 1024 بایت آخرین این فایل محاسبه و مقدار بدست آمده را ( که دو بایت است ) در بایتهای 7 و 8 از آفست نخست جایگزین کنیم و فایل را ذخیره کنیم ...
( از این ساده تر دیگه فکر نکنم جایی توضیح داده باشند )
نکته 1 : آدرس قرار گیری چک سام ولیو در این سری امیولیتورها( 6h , 7h ) که بایت7 و 8 هستند میباشد .
نکته 2 : مهم این نیست که شما چند بایت از امیولیتور را ویرایش کرده اید ، مهم این است که چون شما باید بر اساس الگوریتم Checksum16 ، مقدار چک سام را محاسبه کنید ، پس خروجی شما هم دو بایت میشود یعنی 16 بیت تقسیم بر 8 برابر با 2 بایت ! و این Value را در دو بایت 7 و 8 جایگزین میکنید ...
نکته 3 : همونطوریکه میدونید ، اگر اطلاعات فلش رو با جیتگ اینترفیس از روی آیسی فلش بک آپ بگیرید و سپس دیتای آنرا بطور معقول ویرایش و آنرا دوباره بارگزاری کنید ، نیازی به فیکس نمودن چک سام ولیو نخواهد بود . ولی این راه اصلا مورد بحث ما نیست . زیرا در فایل فلش رسیورهايی مانند هايويون 9090X ، نحوه قرار گیری اطلاعات بصورت باینری و در ضمن
" بایت به بایت معکوس " میباشد ... اطلاعات مورد نگر ما در این زمینه هم در نیمه دوم آفست های فلش قرار دارد ...
نکات مهم در محاسبه چک سام امیولیتورهای سری EMTECH :
1 - مقادیری که در ادیتورها بر مبنای هگزادسیمال برابر با " 00 " نمایش داده میشوند ، در مقدار چک سام تاثیری ندارند . ( یعنی میتوان آنها را نادیده گرفت ) . اگر بصورت صحیح در نگر بگیریم ، کلا 64 بایت نخستین این امیولیتورها برابر با بایتهای ایگنور اولیه محاسبه میشوند . ( یعنی 4 آفست نخستین )
2 - الگوریتم چک سام مورد نگر ما در این سری امیولیتورها از نوع Checksum-16 میباشد و بهتر است بدانید که مکان قرارگیری آن در آفست نخست و بایتهای 7 و 8 میباشد . پس به دنبال محاسبه الگوریتمهای دیگر گمراه نشوید .
3 - مکان قرارگیری بایتهای ایگنور در انواع امیولیتورها کمی تفاوت دارد اما با توجه به پروسه آزمون خطا ، محل قرار گیری قسمت نخست آن در این سری امیولیتورها شناسایی شده است که همانا 64 بایت نخستین و 128 بايت آخر میباشد . (البته اين نكته در آينده بيشتر توضيح داده ميشود )
4 - در امیولیتورهای 150-200 که از رسیور به کامپیوتر برگردانده شده اند ، اگر به انتهای فایل بروید احتمالا چندین خط کد " 00 " خواهید دید که اگر با توجه به نکته شماره 1 ، از آنها چشم پوشی کنیم خواهیم دید که کافیست 128 بایت انتهایی را برابر با مقدار ایگنور در نگر بگیریم . شایان ذکر است که جمع این 128 بایت انتهایی + مقادیر " 00 " که پس از آن قرار دارند ، برابر با همان 1024 بایت خواهند شد .
5 - برای درک بهتر از الگوریتم چک سام مورد نگر ما در این سری امیولیتورها ، از همین راه به نتیجه درست خواهید رسید . اما برای دوستانی که آشنایی کمی با این موضوع دارند یک راه ساه تر هم موجود است . از لیست کانالها یک بک آپ بگیرید ، این فایل بک آپ را در ادیتور فرابخوانید . اکنون چهار آفست نخستین را برابر با ایگنور بایتز در نگر گرفته و از خط پنجم به بعد را در الگوریتم چک سام Checksum-16 محاسبه کنید . مقدار بدست آمده را با مقادیر موجود در دو بایت 7 و 8 که در همان خط نخست قرار دارد مقایسه کنید ... .
6 - روش نبشتن آدرس بایتهای ایگنور در برنامه ادیتور 010 :
بین آدرس بایت نخست تا بایت انتهایی آفست مورد نگر ( .. ) قرار میگیرد .
بین آدرس آفست تا آفست ( , ) قرار میگیرد .
مثال :
در امیولیتور استارست 150 که از رسیور برگردانده شده است :
حجم آن میشود حدود 1438784 بایت از آفست "0000h " تا " 15f440h "
از بایت 1 در آفست "0000h" تا بایت 49 که در آفست "0030h" قرار دارد : ===>>> 0h..30h
از بایت 1437760 تا انتها که میشود بایت 1438783 ===>>> 15f040h..15f43fh
و همین آدرس بایت ایگنور این امیولیتور بطور کامل : ===>>> 0h..30h,15f040h..15f43fh
برای محاسبه چک سام پچ بالا گزینه Range باید روی Entire File باشد .
آدرسهای بالا شامل همان 49 بایت نخستین و 1024 بایت واپسین در امیولیتور میشوند ! (اگر مقادير 00 را نيز به حساب آوريم همان 64 بايت نخست رو شامل ميشود .)
از کجا این آدرسها را میشود بدست آورد ؟
اگر روی هر بایت دابل کلیک کنید ، آدرس آن بصورت هگزادسیمال در برنامه ادیتور و در Tab پایین برنامه (پایینترین قسمت برنامه ادیتور 010) نمایش داده میشود .
آموزش تغيير آيدي پچ براي تبديل پچهاي ******دور و هايويژن به پچهاي استارست :
نخست آيدي متناظر در رسيورهاي استارست ، ******دور و هايويژن :
آيدي استارست 120-130-150 معمولي بدون كارت و خشاب = E124
آيدي استارست 200CI خشاب خور = E224
آيدي ******دور 5000FTA معمولي بدون كارت و خشاب = E127
آيدي ******دور 5000CI خشاب خور = E227
آيدي هايويژن 3000-3300-5000 و 7000 معمولي بدون كارت و خشاب = A136
آيدي هايويژن 5000CI خشاب خور = A236
این اصطلاح از ترکیب دو واژه "Check" به معنی مقایسه و تطبیق و "Sum" به معنی مقدار ایجاد شده است .
چک سام عموما قسمتی از یک فایل است که وظیفه آن حفاظت از کل فایل در برابر تغییرات میباشد . این قسمت از فایل شامل بایت یا بایتهایی (تیبلی) است که وظیفه آن نگهداری مقدار چک سام کل فایل منهای خود همین بایتها و ( Ignore Bytes ) میباشد . به زبان ساده تر میتوان گفت که اگر چک سام کل یا یک قسمت از فایلی را بر اساس الگوریتمی خاص محاسبه کرده و خروجی آن را در محلی از یک فایل و در لابلای بایتها یا پکتها قرار دهیم ، چک سامی برای فایل تعریف کرده ایم که در این فایل ،اگر تنها مقدار چک سام قسمتی از فایل را محاسبه کرده باشیم ، به قسمت محاسبه نشده این فایل اصطلاحا ( Ignore Bytes ) گقته میشود . یعنی این قسمت در محاسبه چک سام منظور نشده است و از آن چشم پوشی کرده ایم . پس در محاسبه بعدی چک سام هم بایستی از آن چشم پوشی کنیم .
مثال کاملا واضح :
در امیولیتور سامسونگ 9500 محل قرار گیری چک سام در بایتهای ابتدایی 10 و 11 فایل قرار دارند . اگر هر آفست را بر مبنای هگزادسیمال (16) در نظر بگیریم ، این چک سام در آفست اول و در بایتهای 10 و 11 اميوليتور قرار گرفته است . پس از تغییرات در پیکر فایل ، نوبت به محاسبه چک سام میرسد . ما در امولیتورسامسونگ با چک سام از نوع الگوریتم Chechsum16 بیتی روبرو استیم .
نکته : هر 1 بایت (Byte) برابر با 8 بیت (Bit) دیتا میشود .
پس چک سام 16 بیتی ما برابر با دوبایت میشود ! که گفتیم مکان قرار گیری آن در آفست نخست و در بایتهای 10 و 11 قرار دارد .
ولی در امیولیتور سامسونگ 9500 ما با بایتهای خنثی ( Ignore Bytes ) هم روبرو هستیم و میدانید که در الگوریتم محاسبه چک سام ، از بایتهای نامبرده باید چشم پوشی کرد . محل این بایتهای ایگنور در امیولیتور سامسونگ همان آفست نخست میباشد . یعنی آفست نخست این امیولیتور که 16 بایت فرض میشود شامل دو بایت چک سام و 14 بایت خنثی (Ignore Bytes) است . پس برای محاسبه چک سام این فایل بایستی آفست نخست را اصلا محاسبه نکنیم . به گویش ساده تر ما از آفست دوم یا بایت 17 تا آفست آخر فایل را بر اساس الگوریتم Chechsum16 بیتی محاسبه و مقدار بدست آمده را در بایت 10 و 11 آفست نخست (محل قرار گیری مقدار چک سام) مینویسیم ... همین !
برخی از الگوریتمهای چک سام :
برخی از الگوریتمهای سادهء چک سام ، الگوریتم 8 - 16 - 32 - 64 بیتی و CRC32 - CRC16 بیتی و ... میباشند .
دقت کنید که بین الگوریتم چک سام و الگوریتم CRC تفاوتهایی هم هست که بعدها براتان توضیح خواهم داد .
چک سام بر اساس هر الگوریتمی که باشد تعداد بیتهای (Bit) آن تقسیم بر 8 برابر با تعداد بایت (Byte) میشود .
مثلا اگر چک سام بر اساس الگوریتم Checksum8 بیتی باشد مقدار چک سام ما 1 بایت است .
اگر چک سام بر اساس الگوریتم Checksum16 باشد مقدار چک سام ما 2 بایت است .
و اگر چک سام بر اساس الگوریتم Checksum32 باشد مقدار چک سام ما 4 بایت است ... الی آخر ...
توضیحات بیشتر :
بطور کلی هر بیت از فایل دارای چک سام خود است که بر اساس الگوریتمی استاندارد و مطلق محاسبه میشود .از سوي دگر اگر در یک فایل چک سام ما بر اساس الگوریتم CRC16 بیتی باشد ، از آنجاییکه هر 8 بیت برابر با یک بایت میشود پس چک سام ما دو بایت از فایل را شامل میشود . حال جای قرار گیری آن در فایلکجاست ؟ این یکی از پرسشهای سخت است که لازمه درک آن ، محاسبات پیچیده ریاضیات و مهندسی معکوس میباشد و یا دسترسی به سورس (Source) آن برنامه میباشد .
الگوریتم ها برای محاسبه چک سام بر اساس محاسبات ریاضی و بصورت استاندارد و در دسترس میباشند .
دانستنیهای لازم برای محاسبه چک سام :
برای محاسبه چک سام یک فایل ، نخست باید بدانیم که چک سام ما بر اساس چه الگوریتمی محاسبه شده است .
سپس بایستی مکان قرار گیری چک سام را شناسایی کنیم .
... و در آخر هم باید بدانیم که آیا با " Ignore Bytes " هم طرف هستیم یا نه و اگر بله مکان آن کجاست ؟؟؟
اکنون در زمان تغییرات معقول یک فایل میتوانیم به سادگی چک سام تازه آنرا هم محاسبه و جایگزین کنیم .
گاهی وقتها هم در ویرایش یک فایل برای تعدیل مقدار چک سام ، بایتهایی به انتهای فایل اضافه میکنند که البته در این راه هم به دانستن الگوریتم چک سام در آن فایل و هم به اطلاعات پیش زمینه دیگری نیاز داریم . اين موضوع فعلا مورد بحث ما نيست ...
------------------------------------
مثالی بسیار مهم و قابل توجه برای دوستان گرامی
برای مثال در امیولیتور استارست 200 ، بایتهایی که مقدار (Value) چک سام در آن نگهداری میشود بایت 7 و 8 از آفست نخست امیولیتور میباشد . در این امیولیتور ما با الگوریتم Checksum16 روبرو هستیم .
پچها در استارست 200 معمولا حدود 800 تا 850 کیلو بایت حجم دارند ، اگر ما این امیولیتور را به رسیور منتقل و سپس دوباره آنرا به کامپیوتر آپلود (Dump) کنیم ، حجم آن حدودا برابر با 1,569,856 بایت خواهد شد ! يعني چيزي حدود دوبرابر .
( دلیل آن این است که در زمان بازگرداندن پچ ، اطلاعات دیگر درون فلش هم به کامپیوتر منتقل میشوند كه اين هم فعلا مورد بحث ما نيست)
اکنون آنرا در برنامه ادیتوری فرامیخوانیم . میبینیم که 64 بایت نخستین امیولیتور ( به جز بایتهای 7 و 8 که محل قرار گیری مقدار چک سام این امیولیتور است )شامل Ignore Bytes میشوند .
از طرفی اگر سری به انتهای این فایل بزنیم ، میبینیم که دقیقا 1 کیلوبایت ( دقیقا 1024 بایت ) آخر این امیولیتور هم جزء همان بایتهای ایگنور محسوب میشوند ! به گویش بهتر میتوان گفت که 64 بایت ابتدایی و 1024 بایت انتهایی فایل نامبرده در بالا ، در الگوریتم چک سام محاسبه نمیشوند . اکنون پس از دستکاری در این امیولیتور ، تنها کافیست که بر اساس الگوریتم Checksum16 چک سام کل فایل را منهای 64 بایت نخستین و 1024 بایت آخرین این فایل محاسبه و مقدار بدست آمده را ( که دو بایت است ) در بایتهای 7 و 8 از آفست نخست جایگزین کنیم و فایل را ذخیره کنیم ...
( از این ساده تر دیگه فکر نکنم جایی توضیح داده باشند )
نکته 1 : آدرس قرار گیری چک سام ولیو در این سری امیولیتورها( 6h , 7h ) که بایت7 و 8 هستند میباشد .
نکته 2 : مهم این نیست که شما چند بایت از امیولیتور را ویرایش کرده اید ، مهم این است که چون شما باید بر اساس الگوریتم Checksum16 ، مقدار چک سام را محاسبه کنید ، پس خروجی شما هم دو بایت میشود یعنی 16 بیت تقسیم بر 8 برابر با 2 بایت ! و این Value را در دو بایت 7 و 8 جایگزین میکنید ...
نکته 3 : همونطوریکه میدونید ، اگر اطلاعات فلش رو با جیتگ اینترفیس از روی آیسی فلش بک آپ بگیرید و سپس دیتای آنرا بطور معقول ویرایش و آنرا دوباره بارگزاری کنید ، نیازی به فیکس نمودن چک سام ولیو نخواهد بود . ولی این راه اصلا مورد بحث ما نیست . زیرا در فایل فلش رسیورهايی مانند هايويون 9090X ، نحوه قرار گیری اطلاعات بصورت باینری و در ضمن
" بایت به بایت معکوس " میباشد ... اطلاعات مورد نگر ما در این زمینه هم در نیمه دوم آفست های فلش قرار دارد ...
نکات مهم در محاسبه چک سام امیولیتورهای سری EMTECH :
1 - مقادیری که در ادیتورها بر مبنای هگزادسیمال برابر با " 00 " نمایش داده میشوند ، در مقدار چک سام تاثیری ندارند . ( یعنی میتوان آنها را نادیده گرفت ) . اگر بصورت صحیح در نگر بگیریم ، کلا 64 بایت نخستین این امیولیتورها برابر با بایتهای ایگنور اولیه محاسبه میشوند . ( یعنی 4 آفست نخستین )
2 - الگوریتم چک سام مورد نگر ما در این سری امیولیتورها از نوع Checksum-16 میباشد و بهتر است بدانید که مکان قرارگیری آن در آفست نخست و بایتهای 7 و 8 میباشد . پس به دنبال محاسبه الگوریتمهای دیگر گمراه نشوید .
3 - مکان قرارگیری بایتهای ایگنور در انواع امیولیتورها کمی تفاوت دارد اما با توجه به پروسه آزمون خطا ، محل قرار گیری قسمت نخست آن در این سری امیولیتورها شناسایی شده است که همانا 64 بایت نخستین و 128 بايت آخر میباشد . (البته اين نكته در آينده بيشتر توضيح داده ميشود )
4 - در امیولیتورهای 150-200 که از رسیور به کامپیوتر برگردانده شده اند ، اگر به انتهای فایل بروید احتمالا چندین خط کد " 00 " خواهید دید که اگر با توجه به نکته شماره 1 ، از آنها چشم پوشی کنیم خواهیم دید که کافیست 128 بایت انتهایی را برابر با مقدار ایگنور در نگر بگیریم . شایان ذکر است که جمع این 128 بایت انتهایی + مقادیر " 00 " که پس از آن قرار دارند ، برابر با همان 1024 بایت خواهند شد .
5 - برای درک بهتر از الگوریتم چک سام مورد نگر ما در این سری امیولیتورها ، از همین راه به نتیجه درست خواهید رسید . اما برای دوستانی که آشنایی کمی با این موضوع دارند یک راه ساه تر هم موجود است . از لیست کانالها یک بک آپ بگیرید ، این فایل بک آپ را در ادیتور فرابخوانید . اکنون چهار آفست نخستین را برابر با ایگنور بایتز در نگر گرفته و از خط پنجم به بعد را در الگوریتم چک سام Checksum-16 محاسبه کنید . مقدار بدست آمده را با مقادیر موجود در دو بایت 7 و 8 که در همان خط نخست قرار دارد مقایسه کنید ... .
6 - روش نبشتن آدرس بایتهای ایگنور در برنامه ادیتور 010 :
بین آدرس بایت نخست تا بایت انتهایی آفست مورد نگر ( .. ) قرار میگیرد .
بین آدرس آفست تا آفست ( , ) قرار میگیرد .
مثال :
در امیولیتور استارست 150 که از رسیور برگردانده شده است :
حجم آن میشود حدود 1438784 بایت از آفست "0000h " تا " 15f440h "
از بایت 1 در آفست "0000h" تا بایت 49 که در آفست "0030h" قرار دارد : ===>>> 0h..30h
از بایت 1437760 تا انتها که میشود بایت 1438783 ===>>> 15f040h..15f43fh
و همین آدرس بایت ایگنور این امیولیتور بطور کامل : ===>>> 0h..30h,15f040h..15f43fh
برای محاسبه چک سام پچ بالا گزینه Range باید روی Entire File باشد .
آدرسهای بالا شامل همان 49 بایت نخستین و 1024 بایت واپسین در امیولیتور میشوند ! (اگر مقادير 00 را نيز به حساب آوريم همان 64 بايت نخست رو شامل ميشود .)
از کجا این آدرسها را میشود بدست آورد ؟
اگر روی هر بایت دابل کلیک کنید ، آدرس آن بصورت هگزادسیمال در برنامه ادیتور و در Tab پایین برنامه (پایینترین قسمت برنامه ادیتور 010) نمایش داده میشود .
آموزش تغيير آيدي پچ براي تبديل پچهاي ******دور و هايويژن به پچهاي استارست :
نخست آيدي متناظر در رسيورهاي استارست ، ******دور و هايويژن :
آيدي استارست 120-130-150 معمولي بدون كارت و خشاب = E124
آيدي استارست 200CI خشاب خور = E224
آيدي ******دور 5000FTA معمولي بدون كارت و خشاب = E127
آيدي ******دور 5000CI خشاب خور = E227
آيدي هايويژن 3000-3300-5000 و 7000 معمولي بدون كارت و خشاب = A136
آيدي هايويژن 5000CI خشاب خور = A236