چک سام (Checksum) چیست ؟

این اصطلاح از ترکیب دو واژه “Check” به معنی مقایسه و تطبیق و “Sum” به معنی مقدار ایجاد شده است .

چک سام عموما قسمتی از یک فایل است که وظیفه آن حفاظت از کل فایل در برابر تغییرات میباشد . این قسمت از فایل شامل بایت یا بایتهایی (تیبلی) است که وظیفه آن نگهداری مقدار چک سام کل فایل منهای خود همین بایتها و ( Ignore Bytes ) میباشد . به زبان ساده تر میتوان گفت که اگر چک سام کل یا یک قسمت از فایلی را بر اساس الگوریتمی خاص محاسبه کرده و خروجی آن را در محلی از یک فایل و در لابلای بایتها یا پکتها قرار دهیم ، چک سامی برای فایل تعریف کرده ایم که در این فایل ،اگر تنها مقدار چک سام قسمتی از فایل را محاسبه کرده باشیم ، به قسمت محاسبه نشده این فایل اصطلاحا ( Ignore Bytes ) گقته میشود . یعنی این قسمت در محاسبه چک سام منظور نشده است و از آن چشم پوشی کرده ایم . پس در محاسبه بعدی چک سام هم بایستی از آن چشم پوشی کنیم .

مثال کاملا واضح :
در  بعضی از امیولیتور محل قرار گیری چک سام در بایتهای ابتدایی 10 و 11 فایل قرار دارند . اگر هر آفست را بر مبنای هگزادسیمال (16) در نظر بگیریم ، این چک سام در آفست اول و در بایتهای 10 و 11 اميوليتور قرار گرفته است . پس از تغییرات در پیکر فایل ، نوبت به محاسبه چک سام میرسد . ما در امولیتورسامسونگ با چک سام از نوع الگوریتم Chechsum16 بیتی روبرو استیم .

نکته : هر 1 بایت (Byte) برابر با 8 بیت (Bit) دیتا میشود .

پس چک سام 16 بیتی ما برابر با دوبایت میشود ! که گفتیم مکان قرار گیری آن در آفست نخست و در بایتهای 10 و 11 قرار دارد .

ولی در بعضی از امیولیتور  با بایتهای خنثی ( 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 ” هم طرف هستیم یا نه و اگر بله مکان آن کجاست ؟؟؟

اکنون در زمان تغییرات معقول یک فایل میتوانیم به سادگی چک سام تازه آنرا هم محاسبه و جایگزین کنیم .

گاهی وقتها هم در ویرایش یک فایل برای تعدیل مقدار چک سام ، بایتهایی به انتهای فایل اضافه میکنند که البته در این راه هم به دانستن الگوریتم چک سام در آن فایل و هم به اطلاعات پیش زمینه دیگری نیاز داریم . اين موضوع فعلا مورد بحث ما نيست …

————————————
مثالی بسیار مهم و قابل توجه برای دوستان گرامی

برای مثال در یک  امیولیتور  بایتهایی که مقدار (Value) چک سام در آن نگهداری میشود بایت 7 و 8 از آفست نخست امیولیتور میباشد . در این امیولیتور ما با الگوریتم Checksum16 روبرو هستیم .

پچها بعضی از سخت افزارها  معمولا حدود 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 : همونطوریکه میدونید ، اگر اطلاعات فلش رو با جیتگ اینترفیس از روی آیسی فلش بک آپ بگیرید و سپس دیتای آنرا بطور معقول ویرایش و آنرا دوباره بارگزاری کنید ، نیازی به فیکس نمودن چک سام ولیو نخواهد بود . ولی این راه اصلا مورد بحث ما نیست . زیرا در فایل فلش برخی از سخت افزار ها ، نحوه قرار گیری اطلاعات بصورت باینری و در ضمن
” بایت به بایت معکوس ” میباشد … اطلاعات مورد نگر ما در این زمینه هم در نیمه دوم آفست های فلش قرار دارد …
نکات مهم در محاسبه چک سام امیولیتورهای سری EMTECH :

1 – مقادیری که در ادیتورها بر مبنای هگزادسیمال برابر با ” 00 ” نمایش داده میشوند ، در مقدار چک سام تاثیری ندارند . ( یعنی میتوان آنها را نادیده گرفت ) . اگر بصورت صحیح در نگر بگیریم ، کلا 64 بایت نخستین این امیولیتورها برابر با بایتهای ایگنور اولیه محاسبه میشوند . ( یعنی 4 آفست نخستین )

2 – الگوریتم چک سام مورد نگر ما در این سری امیولیتورها از نوع Checksum-16 میباشد و بهتر است بدانید که مکان قرارگیری آن در آفست نخست و بایتهای 7 و 8 میباشد . پس به دنبال محاسبه الگوریتمهای دیگر گمراه نشوید .

3 – مکان قرارگیری بایتهای ایگنور در انواع امیولیتورها کمی تفاوت دارد اما با توجه به پروسه آزمون خطا ، محل قرار گیری قسمت نخست آن در این سری امیولیتورها شناسایی شده است که همانا 64 بایت نخستین و 128 بايت آخر میباشد . (البته اين نكته در آينده بيشتر توضيح داده ميشود )

4 – در امیولیتورهای 150-200 که از سیستم به کامپیوتر برگردانده شده اند ، اگر به انتهای فایل بروید احتمالا چندین خط کد ” 00 ” خواهید دید که اگر با توجه به نکته شماره 1 ، از آنها چشم پوشی کنیم خواهیم دید که کافیست 128 بایت انتهایی را برابر با مقدار ایگنور در نگر بگیریم . شایان ذکر است که جمع این 128 بایت انتهایی + مقادیر ” 00 ” که پس از آن قرار دارند ، برابر با همان 1024 بایت خواهند شد .

5- روش نبشتن آدرس بایتهای ایگنور در برنامه ادیتور 010 :
بین آدرس بایت نخست تا بایت انتهایی آفست مورد نگر ( .. ) قرار میگیرد .
بین آدرس آفست تا آفست ( , ) قرار میگیرد .