چک سام (Checksum) چیست ؟
چک سام (Checksum) از ترکیب دو واژه “Check” به معنی مقایسه و تطبیق و “Sum” به معنی مقدار ایجاد شده است .
چک سام عموما قسمتی از یک فایل است که وظیفه آن حفاظت از کل فایل در برابر تغییرات میباشد. این قسمت از فایل شامل بایت یا بایتهایی (تیبلی) است که وظیفه آن نگهداری مقدار چک سام کل فایل منهای خود همین بایتها و ( Ignore Bytes ) میباشد. به زبان ساده تر میتوان گفت که اگر چک سام کل یا یک قسمت از فایلی را بر اساس الگوریتمی خاص محاسبه کرده و خروجی آن را در محلی از یک فایل و در لابلای بایتها یا پکتها قرار دهیم ، چک سامی برای فایل تعریف کرده ایم که در این فایل ،اگر تنها مقدار چک سام قسمتی از فایل را محاسبه کرده باشیم ، به قسمت محاسبه نشده این فایل اصطلاحا ( Ignore Bytes ) گقته میشود. یعنی این قسمت در محاسبه چک سام منظور نشده است و از آن چشم پوشی کرده ایم. پس در محاسبه بعدی چک سام هم بایستی از آن چشم پوشی کنیم.
مثال کاملا واضح :
در بعضی از امیولیتور محل قرار گیری چک سام در بایتهای ابتدایی 10 و 11 فایل قرار دارند . اگر هر آفست را بر مبنای هگزادسیمال (16) در نظر بگیریم ، این چک سام در آفست اول و در بایتهای 10 و 11 اميوليتور قرار گرفته است . پس از تغییرات در پیکر فایل ، نوبت به محاسبه چک سام میرسد. ما در امولیتور سامسونگ با چک سام از نوع الگوریتم Checksum16 بیتی روبرو هستیم.
نکته : هر 1 بایت (Byte) برابر با 8 بیت (Bit) دیتا میشود.
پس چک سام 16 بیتی ما برابر با دوبایت میشود ! که گفتیم مکان قرار گیری آن در آفست نخست و در بایتهای 10 و 11 قرار دارد .
ولی در بعضی از امیولیتور با بایتهای خنثی ( Ignore Bytes ) هم روبرو هستیم و میدانید که در الگوریتم محاسبه چک سام ، از بایتهای نامبرده باید چشم پوشی کرد. محل این بایتهای ایگنور در امیولیتور سامسونگ همان آفست نخست میباشد. یعنی آفست نخست این امیولیتور که 16 بایت فرض میشود شامل دو بایت چک سام و 14 بایت خنثی (Ignore Bytes) است. پس برای محاسبه چک سام این فایل بایستی آفست نخست را اصلا محاسبه نکنیم. به گویش ساده تر ما از آفست دوم یا بایت 17 تا آفست آخر فایل را بر اساس الگوریتم Checksum16 بیتی محاسبه و مقدار بدست آمده را در بایت 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 :
بین آدرس بایت نخست تا بایت انتهایی آفست مورد نگر ( .. ) قرار میگیرد.
بین آدرس آفست تا آفست ( , ) قرار میگیرد.