Bit Pattern কী — অর্থ কোথা থেকে আসে

যুক্তিটা উল্টো দিকে ভুল। “প্রথম bit 1 মানে negative” — এটা সত্যিই two’s complement convention-এর একটা নিয়ম। কিন্তু এখান থেকে “bit pattern নিজে বলে দেয় এটা signed” — এই সিদ্ধান্তে যাওয়া ভুল।

কারণ: MSB (most significant bit) 1 থাকা একটা bit pattern সমান বৈধভাবে একটা বড় unsigned সংখ্যাও হতে পারে।

1000 0001

signed (two's complement) পাঠ:    -127
unsigned পাঠ:                      129

দুইটাই “সঠিক” — নির্ভর করে আপনি কোন convention প্রযোজ্য বলে আগে থেকে স্থির করেছেন তার উপর। C-তে এটাই ঘটে যখন int8_t আর uint8_t-এর মধ্যে cast করা হয়: bit একই থাকে, শুধু compiler আপনাকে বলা convention অনুযায়ী পড়ে।

সঠিক বাক্য হওয়া উচিত: “যদি আমরা ধরে নিই এই bit pattern two’s complement-এ encoded, তাহলে MSB 1 মানে এটা negative।” Convention আগে আসে, উপসংহার পরে — কখনো উল্টো নয়। এটাই এই লেসনের কেন্দ্রীয় থিসিসের সবচেয়ে সাধারণ ভুল প্রয়োগ, আর পরের module-এর signed integer লেসনে আমরা এটা আরও গভীরে দেখব।

ASCII পাঠ:

→ "Hell" (সম্পূর্ণ "Hello"-র প্রথম চার অক্ষর — এটা ইচ্ছাকৃতভাবে বেছে নেওয়া উদাহরণ)।

Little-endian uint32 পাঠ: little-endian মানে সবচেয়ে কম গুরুত্বপূর্ণ byte সবার আগে (memory-তে সবচেয়ে ছোট address-এ) থাকে। তাই byte order উল্টে সংখ্যা বানাতে হয়:

$0x6c6c6548 = 6{\times}16^7 + c{\times}16^6 + 6{\times}16^5 + c{\times}16^4 + 6{\times}16^3 + 5{\times}16^2 + 4{\times}16^1 + 8{\times}16^0$

হিসাব করলে:

$0x6c6c6548 = 1{,}819{,}043{,}144$

দুইটা সম্পূর্ণ ভিন্ন ফলাফল, একই চারটা byte থেকে — একবার একটা পঠনযোগ্য শব্দ, একবার একটা প্রায়-এলোমেলো দেখতে বড় সংখ্যা। এই প্রশ্নটাই দেখায় কেন endianness (multi-byte সংখ্যা কোন দিক থেকে পড়া হবে) নিজেই একটা আলাদা convention, যেটার জন্য এই module-এর আলাদা একটা লেসন লাগবে।

কিছুই “নতুনভাবে” ইনজেক্ট হয় না প্রচলিত অর্থে — যা ঘটে তা হলো attacker এমন byte পাঠায় যেগুলো data হিসেবে গৃহীত হয়, কিন্তু পরে CPU সেই একই address-এ পৌঁছে সেগুলোকে instruction হিসেবে পড়ে ফেলে।

ধাপে ধাপে:

1. একটা program buf-এ user input নেয়, কিন্তু bound check করে না। Attacker buf-এর আকারের চেয়ে বড় input পাঠায়।
2. Overflow হওয়া data stack-এর পরের অংশ পর্যন্ত ছড়িয়ে পড়ে — বিশেষত return address (ফাংশন শেষে CPU কোথায় ফিরবে সেই ঠিকানা, নিজেও একটা bit pattern) overwrite করে দেয়।
3. Function শেষ হলে CPU সেই (এখন attacker-এর দেওয়া) return address-এ jump করে — যা আসলে attacker-এর পাঠানো data-রই একটা অংশ (shellcode) নির্দেশ করে।
4. CPU সেই ঠিকানায় পৌঁছে সেই bytes-কে instruction হিসেবে fetch করে চালানো শুরু করে।

কোনো নতুন data তৈরি হয়নি। যা ঘটেছে তা এই লেসনের থিসিসের সরাসরি প্রয়োগ: একই bytes ধাপ ১-এ “শুধু ডেটা” হিসেবে গৃহীত হয়েছিল, ধাপ ৪-এ “instruction” হিসেবে fetch হয়েছে — শুধু CPU-র Program Counter সেখানে পৌঁছেছে বলে। Convention (এখানে: “PC যেখানে পৌঁছায় সেটাই instruction”) পুরো পার্থক্যটা তৈরি করেছে, bit pattern নিজে না।

এই কারণেই আধুনিক প্রতিরক্ষা (NX bit, stack canary, ASLR) সবই এই থিসিসকেই লক্ষ্য করে কাজ করে — কোনো না কোনোভাবে “data” আর “instruction” অঞ্চলের মধ্যে convention-টা জোরদার করে, যাতে data হিসেবে চিহ্নিত memory কখনো fetch/execute করা না যায়। Level 10-এ এটা বিস্তারিত।

এই প্রশ্নটা সরাসরি জিজ্ঞেস করছে: bit নিজে convention বহন করে না, তাহলে সেটা আলাদাভাবে কীভাবে যোগ করবেন? বাস্তব ফাইল ফরম্যাট দুইটা প্রধান কৌশল ব্যবহার করে।

পদ্ধতি ১ — Type tag + length prefix (self-describing)।

প্রতিটা অংশের আগে একটা ছোট header রাখুন যা বলে দেয় ধরন আর দৈর্ঘ্য:

[TYPE:1 byte][LENGTH:4 byte][DATA:LENGTH byte] [TYPE][LENGTH][DATA] ...

TYPE = 0x01 মানে integer, 0x02 মানে text, 0x03 মানে image — একটা আলাদা lookup table দিয়ে সংজ্ঞায়িত।

• সুবিধা: reader schema আগে থেকে না জেনেও ফাইলের গঠন বুঝতে পারে (self-describing) — নতুন type যোগ করা সহজ, backward compatible রাখা যায়।
• অসুবিধা: প্রতিটা অংশে overhead (৫ byte বা তার বেশি)। ছোট ছোট অনেক value থাকলে এই overhead উল্লেখযোগ্য হয়ে ওঠে। PNG, ZIP, RIFF (WAV/AVI) — এই কৌশলই ব্যবহার করে (chunk-ভিত্তিক ফরম্যাট)।

পদ্ধতি ২ — Fixed schema (external convention)।

ফাইলে কোনো type tag থাকবে না। বদলে, একটা আলাদা spec ডকুমেন্ট (বা কোড-এ hardcode করা struct definition) বলে দেয় ঠিক কোন byte range-এ কী থাকবে:

struct MyFile {
    uint32_t magic;       // byte 0-3
    uint32_t num_records;  // byte 4-7
    float    records[];    // byte 8 থেকে, প্রতিটা ৪ byte
};

• সুবিধা: কোনো per-field overhead নেই — সবচেয়ে compact। Parsing দ্রুত (শুধু struct-এর উপর cast/memcpy)।
• অসুবিধা: reader-কে schema আগে থেকে জানতে হবে — schema বদলালে পুরনো reader নতুন ফাইল পড়তে পারবে না (backward compatibility ভেঙে যায়) যদি না version number আগে থেকে রাখা হয়। Protocol Buffers, বেশিরভাগ raw binary struct dump এই কৌশল ব্যবহার করে।

বাস্তব সিদ্ধান্তের নীতি: যদি ফরম্যাটটা সময়ের সাথে বিবর্তিত হবে, বহু independent reader/writer থাকবে (যেমন একটা public file format), তাহলে পদ্ধতি ১ (self-describing) নিরাপদ। যদি performance critical আর producer/consumer একই codebase-এর অংশ (যেমন একটা game engine-এর internal save format), পদ্ধতি ২ যথেষ্ট, দ্রুততর।

তৃতীয় বাস্তব বিকল্প (hybrid): একটা ছোট fixed header (magic number + version), তারপর version-নির্ভর schema। এটাই সবচেয়ে বেশি ব্যবহৃত বাস্তব প্যাটার্ন — PNG, ELF, class file — সবাই প্রথমে magic number রাখে যাতে reader অন্তত “এটা কোন ফরম্যাট” নিশ্চিত হতে পারে, তারপর নির্দিষ্ট parsing logic-এ যায়।