Sprint: Binary & Hexadecimal Mastery - Real World Projects

Goal: Build a first-principles understanding of positional number systems and why binary (base 2) and hexadecimal (base 16) are just different representations of the same underlying value. citeturn4search15turn1search1turn6search0 You will internalize bits, bytes (an 8-bit byte), and nibbles, and learn how hex digits map cleanly onto 4-bit groups. citeturn5search0turn5search1turn4search12turn6search12 You will reason confidently about bitwise operations, two’s-complement signed integers, and byte order in real systems. citeturn4search13turn3search6turn2search5 By building practical tools like converters, hexdumpers, and signature scanners, you will turn raw bytes into readable, testable evidence. citeturn3search1turn2search0

Introduction

Binary and hexadecimal are positional numeral systems that let you write the same numeric value in different bases; binary is base 2 and hex is base 16 with digits 0-9 and A-F. citeturn4search15turn1search1turn6search0 Computers store and process information as bits and bytes, so hex is the compact, human-readable way to view byte-oriented data without losing exactness. citeturn5search0turn5search1turn6search12 This guide teaches you to move between human-friendly representations and machine-native layouts so that files, memory, and protocols stop looking like mystery glyphs and start looking like structured evidence.

What you will build across the projects:

A universal base converter (decimal, binary, hexadecimal)
A hex color visualizer with RGB inspection
A bitwise logic calculator and mask tester
A two’s-complement range explorer and overflow detector
An endianness inspector and byte swapper
An ASCII/UTF-8 byte inspector
A flag/permission decoder for packed bitfields
A file signature identifier using magic-number rules
A hexdump clone with offset and ASCII columns
A binary diff and patch tool
A BMP header decoder
A packed bitfield simulator

In scope:

Positional notation and base conversion
Bits, bytes, nibbles, and hex notation
Bitwise operations, masks, and shifts
Signed integers and two’s complement
Endianness and byte order
ASCII and UTF-8 encoding basics
File signatures (magic numbers) and hexdumps

Out of scope:

Floating-point encoding (IEEE 754)
Full Unicode algorithm details beyond UTF-8 basics
Deep network protocol parsing beyond byte order and fields

Big-Picture ASCII Diagram

HUMAN INPUT                         MACHINE REALITY
"255" (dec)   "0xFF" (hex)   "11111111" (bin)
     \            |                 /
      \           |                /
       +----------v---------------+
       |    PARSER / DECODER      |
       +----------+---------------+
                  |
                  v
             value N (abstract)
                  |
                  v
     +------------+-------------+
     |                          |
     v                          v
format as hex             store as bytes
"FF"                     11111111
                          (endianness decides order)

How to Use This Guide

Read the Theory Primer first so the projects feel like practice, not puzzles.
Pick a learning path that matches your background (see Recommended Learning Paths).
After each project, verify your outputs using a known tool (xxd, file, or a trusted library).
Keep a conversion notebook: write conversions by hand until the patterns become automatic.

Prerequisites & Background Knowledge

Essential Prerequisites (Must Have)

Basic programming: variables, loops, functions, strings
Command line basics: running programs, passing arguments
Integer arithmetic: division, modulo, powers of two
Recommended Reading: “Computer Systems: A Programmer’s Perspective” by Bryant & O’Hallaron - Ch. 2

Helpful But Not Required

Binary file I/O (learn during Projects 8-10)
Debugging basics (print/trace; learn across all projects)
Basic HTML/CSS for the color visualizer (Project 2)

Self-Assessment Questions

Can you explain what a base is in a positional numeral system?
Can you write a loop that processes characters one by one?
Do you know why integer division and modulo are linked?
Can you describe the difference between a character and its numeric code?

Development Environment Setup Required Tools:

C compiler: gcc or clang
Python 3.x
A terminal with standard utilities

Recommended Tools:

Hex viewers: xxd, hexdump, od
File type inspector: file

Testing Your Setup:

$ echo "Hello" > sample.txt
$ xxd sample.txt
00000000: 4865 6c6c 6f0a                           Hello.

$ python3 -c "print(hex(255))"
0xff

Time Investment

Simple projects: 4-8 hours each
Moderate projects: 10-20 hours each
Complex projects: 20-40 hours each
Total sprint: 2-3 months

Important Reality Check This topic becomes easy only after repeated conversion and inspection. Expect the first few projects to feel slow and manual. That is the point: you are training your eyes to read bit patterns the way you already read decimal.

Big Picture / Mental Model

Binary and hex are not “different kinds” of numbers. They are different notations for the same value. The real system is a pipeline from symbols to bits to meaning.

SYMBOLS (text) -> PARSE -> VALUE (integer) -> BYTES -> INTERPRETATION

"FF"  (hex)        |       255            |  11111111  -> unsigned int
"11111111" (bin)   |                      |  0xFF     -> signed int (-1)
"255" (dec)        |                      |  0xFF     -> color channel

Key idea: bytes are neutral; interpretation gives them meaning.

Theory Primer

Concept 1: Positional Number Systems & Base Conversion

Fundamentals A positional numeral system is one where the value of a digit depends on its position, not just its symbol. citeturn4search15 In binary, the base is 2, so each position represents a power of 2 and only digits 0 and 1 are used. citeturn1search1 In hexadecimal, the base is 16 and the digit set expands to 0-9 and A-F to represent values 10-15. citeturn6search0 Decimal, binary, and hexadecimal can represent the exact same value; they just use different place-value weights. When you convert between bases, you are re-expressing the same quantity, not changing it. This is why 255, 0xFF, and 11111111 are all the same value written in different notations.

Deep Dive Positional notation works because every digit contributes a value equal to its digit value times a base-specific power. A decimal number like 123 means 110^2 + 210^1 + 310^0; the same expansion works for any base. citeturn4search15 For binary, each position is a power of 2 (1, 2, 4, 8, 16…), and for hex each position is a power of 16 (1, 16, 256, 4096…). citeturn1search1turn6search0 This is the root of all conversion algorithms. Converting *from another base to decimal is just weighted addition: multiply each digit by its place value and sum. Converting from decimal to another base is repeated division: divide by the target base, record the remainder, repeat with the quotient until it reaches zero. The remainder sequence, read backward, is the new representation.

If you understand place value, you can also convert directly between bases by grouping. Binary and hex are a special case: each hex digit maps to exactly four binary bits (a nibble). citeturn4search12turn6search12 This 4-to-1 mapping is the reason hex is the preferred human-readable representation of binary data: it compresses long binary strings into short hex strings without losing alignment. Concretely, the binary group 1111 corresponds to hex F (15), 1010 corresponds to hex A (10), and so on. This is not a trick; it is a consequence of 16 being 2^4.

When you do conversions by hand, do not memorize large tables. Memorize only the 16 nibble mappings (0-F). Everything else follows from the place-value rules. If you can convert 255 to binary, you can convert any integer: divide by 2, record remainders, reverse. If you can convert any decimal number to binary, you can convert to hex by grouping binary into four-bit chunks. If you can convert a hex number to binary by mapping each digit to four bits, you can convert to decimal by summing powers of 16. The method is consistent, repeatable, and testable.

Another crucial idea: a numeral system is just a representation. The physical computer stores bits and bytes; hex is merely a convenient, human-sized view of those bytes. That is why memory addresses, file offsets, and machine instructions are routinely displayed in hex. The representation is smaller, but it preserves exact values and byte boundaries. Conversion is not a feature; it is the foundation for all the project tools you will build.

How this fits on projects

Projects 1 and 2 implement base conversion directly.
Projects 8 and 9 rely on interpreting hex bytes in files.

Definitions & key terms

Base (radix): the number of unique digits used in a positional system.
Positional notation: a system where digit value depends on its position. citeturn4search15
Most significant digit (MSD): leftmost digit, highest place value.
Least significant digit (LSD): rightmost digit, lowest place value.

Mental model diagram

value = sum(digit_i * base^i)

     [d3] [d2] [d1] [d0]
       |    |    |    |
      b^3  b^2  b^1  b^0

How it works (step-by-step, invariants, failure modes)

Choose a base and a digit set (0-1 for binary, 0-9/A-F for hex). citeturn1search1turn6search0
For parsing: scan digits left to right, multiply accumulator by base, add digit value.
For formatting: repeatedly divide by base, collect remainders, reverse.
Invariant: the numeric value stays the same regardless of representation.
Failure modes: invalid digit for the base, overflow if accumulator exceeds numeric type.

Minimal concrete example (pseudocode)

INPUT: digits "7B" in base 16
acc = 0
for each digit:
  acc = acc * 16 + digit_value
OUTPUT: acc = 123

Common misconceptions

“Hex is a different kind of number.” It is the same value in base 16. citeturn6search0
“You must memorize full tables.” Only the 16 nibble mappings matter. citeturn4search12turn6search12

Check-your-understanding questions

Why does hex use letters A-F?
What is the decimal value of binary 10000000?
What is the binary value of hex 0xC0?

Check-your-understanding answers

Hex needs 16 digits; A-F represent decimal 10-15. citeturn6search0
10000000 is 2^7 = 128.
C=1100 and 0=0000, so 11000000.

Real-world applications

Memory addresses and offsets are displayed in hex.
File headers and protocol fields are shown in hex.

Where you’ll apply it

Project 1 (Universal Base Converter)
Project 2 (Hex Color Visualizer)
Project 8 (File Signature Identifier)
Project 9 (Hexdump Clone)

References

“Computer Systems: A Programmer’s Perspective” - Ch. 2
“Code: The Hidden Language of Computer Hardware and Software” - Ch. 7-8
Positional notation overview. citeturn4search15
Binary system definition. citeturn1search1
Hexadecimal digit set. citeturn6search0

Key insights The base changes the notation, not the value.

Summary Positional notation lets any value be represented in any base. Conversion is mechanical and testable, and hex is a compact, byte-aligned way to represent binary.

Homework/Exercises

Convert 200 (decimal) to binary and hex.
Convert 10101010 (binary) to decimal and hex.
Expand 0x1234 in place-value form.

Solutions

200 = 11001000 (bin) = C8 (hex).
10101010 = 170 (dec) = AA (hex).
0x1234 = 116^3 + 216^2 + 316^1 + 416^0.

Concept 2: Bits, Bytes, Nibbles, and Hex Notation

Fundamentals A bit is a binary digit that represents one of two possible states and is the fundamental unit of information. citeturn5search0 A byte is commonly defined as eight bits; ISO/IEC 80000-13 explicitly defines the byte as an eight-bit unit. citeturn5search1 A nibble is a four-bit group, often called a half-byte, and it maps directly to a single hexadecimal digit. citeturn4search12turn6search12 Because hex uses base 16, two hex digits exactly represent one byte, and this is why hex is used so heavily in debugging tools and file inspection. citeturn6search12 In POSIX systems, CHAR_BIT is 8, which reflects the practical expectation that a byte is eight bits in most modern environments. citeturn6search1

Deep Dive Bits are the raw currency of digital systems: each bit is one yes/no decision. citeturn5search0 When you group bits, you create units that are easier to address and interpret. The 8-bit byte became the dominant unit for characters, storage, and memory addressing, so most file formats, protocols, and instruction sets think in bytes, not bits. citeturn5search1 The nibble exists because hex is base 16, and 16 is 2^4; this means exactly four bits can encode a single hex digit. citeturn4search12turn6search12 Two nibbles make a byte, so every byte can be written as two hex digits. This simple alignment explains why hexdumps are readable: the hex column is a direct, lossless view of bytes.

Hex notation also serves as a practical boundary indicator. A 32-bit value is eight hex digits. A 64-bit value is sixteen hex digits. If you see 0x7f454c46 in a hexdump, you know you are looking at a 4-byte value (eight hex digits), and you can split it into bytes or interpret it as a single integer depending on context. That flexibility is exactly what systems work demands: the same bytes can be interpreted as characters, integers, addresses, or flags. The difference is not the bits; it is the lens you use to interpret them.

Byte order and alignment also matter. When bytes are displayed in hex, they are shown in the order they appear in memory or file layout, not necessarily in the order you would write the number in decimal. This can feel confusing until you internalize that the byte stream is the “ground truth” and numeric display is a post-processing step.

Finally, recognize that tools and protocols often use the term “octet” when they need to be unambiguous. An octet is exactly eight bits, removing any historical ambiguity around the word “byte.” citeturn5search1 In practice, you will see “octet” in networking RFCs and “byte” in programming language contexts, but both refer to 8-bit groups in modern systems.

How this fits on projects

Project 1 uses bytes as the unit of conversion output.
Project 2 uses hex pairs as RGB channel values.
Projects 8-10 require byte-aligned reading and display.

Definitions & key terms

Bit: a binary digit, 0 or 1. citeturn5search0
Byte: eight bits; often the smallest addressable unit. citeturn5search1
Nibble: four bits, half a byte. citeturn4search12
Octet: an explicit 8-bit byte. citeturn5search1

Mental model diagram

byte (8 bits) = nibble + nibble

[ b7 b6 b5 b4 | b3 b2 b1 b0 ]
[    high     |    low     ]
[   hex digit |  hex digit ]

How it works (step-by-step, invariants, failure modes)

Group raw bits into bytes for storage and addressing.
Group bytes into words or structures as needed by a file or protocol.
Render bytes as hex pairs for human inspection.
Invariant: hex rendering is a 1:1 mapping from byte values.
Failure modes: misaligned grouping, accidental base-10 interpretation.

Minimal concrete example (pseudocode)

INPUT: byte value 255
high_nibble = 15
low_nibble = 15
OUTPUT: hex "FF"

Common misconceptions

“A byte is always the same everywhere.” Historically not true, but modern standards define an 8-bit byte for practical systems. citeturn5search1
“Hex is only for memory addresses.” It is for any byte-aligned data.

Check-your-understanding questions

How many hex digits represent one byte?
How many bits are in a nibble?
Why do networking documents use the term “octet”?

Check-your-understanding answers

Two hex digits per byte. citeturn6search12
Four bits. citeturn4search12
To be explicit that the unit is exactly 8 bits. citeturn5search1

Real-world applications

Hexdumps and memory inspectors
Binary file headers and protocol fields

Where you’ll apply it

Project 2 (Hex Color Visualizer)
Project 8 (File Signature Identifier)
Project 9 (Hexdump Clone)

References

“Computer Systems: A Programmer’s Perspective” - Ch. 2
Byte and nibble definitions. citeturn5search1turn4search12

Key insights Hex is the human-friendly surface of byte-oriented reality.

Summary Bits combine into bytes, bytes into nibbles and words, and hex is the canonical way to show those bytes without ambiguity.

Homework/Exercises

Write the hex representation for bytes 0, 15, 16, 255.
Split the byte 0xAB into high and low nibbles.
Explain why two hex digits always map to one byte.

Solutions

00, 0F, 10, FF.
High nibble A (1010), low nibble B (1011). citeturn6search12
Each hex digit is 4 bits; two digits are 8 bits. citeturn4search12turn6search12

Concept 3: Bitwise Operations, Masks, and Shifts

Fundamentals C-style languages provide bitwise operators for AND, OR, XOR, NOT, and shifts. citeturn4search13 These operators act on individual bits rather than on whole-number truth values. Shifts move bit positions left or right and are commonly used for fast scaling, field extraction, and packing/unpacking data. citeturn4search16 Because bitwise operations are purely mechanical, they are ideal for defining flags, permissions, and compact data formats.

Deep Dive Bitwise operations are the grammar of low-level data manipulation. AND (&) is used to clear bits or test whether a bit is set; OR (|) sets bits; XOR (^) toggles bits; NOT (~) flips bits; shifts (« and ») reposition bits. citeturn4search13 Each operator is simple, but their composition creates powerful patterns. A mask is just a number with certain bits set to 1 and others set to 0. ANDing a value with a mask isolates specific bits; ORing with a mask forces certain bits to 1; XORing with a mask flips selected bits. These are the core tools for packed flags, permissions, and hardware registers.

Shifts are especially important for compact data layouts. Left shift by n multiplies an unsigned value by 2^n, while right shift divides by 2^n (for logical shifts). citeturn4search16 But shifts can be unsafe if the shift amount is negative or >= the width of the type, which is undefined behavior in C. citeturn4search16 This is why your projects should explicitly validate shift counts and keep intermediate values in a known width.

In practice, you will build higher-level operations from these primitives. For example, to extract a 5-bit field starting at bit 8, you would shift right by 8, then mask with 0b11111. To insert a field, you would clear the destination bits with an inverted mask, shift the new value into place, and OR it in. If you adopt a consistent bit numbering scheme and write small helper functions, bitwise logic becomes predictable and safe.

The key invariant is that bitwise operations are deterministic and reversible if you preserve the original bits. If you save an original value and the mask, you can always reconstruct or verify the transformation. The most common failure modes are off-by-one bit positions, forgetting to clear a field before inserting, or using signed values where you intended unsigned.

How this fits on projects

Project 3 (Bitwise Logic Calculator)
Project 7 (Flag/Permission Decoder)
Projects 10-12 (packed fields and binary patching)

Definitions & key terms

Bitwise AND (&): bitwise conjunction. citeturn4search13
**Bitwise OR ( ):** bitwise inclusive OR. citeturn4search13
Bitwise XOR (^): bitwise exclusive OR. citeturn4search13
Bitwise NOT (~): bitwise inversion. citeturn4search13
Shift («, »): move bits left or right. citeturn4search16
Mask: a bit pattern used to isolate or set fields.

Mental model diagram

value:  1101 0110
mask:   0000 1111
AND ->  0000 0110   (low nibble isolated)

How it works (step-by-step, invariants, failure modes)

Decide the bit positions that matter.
Build a mask with 1s in those positions.
Apply AND to extract, OR to set, XOR to toggle, NOT to invert.
Invariant: applying AND with a mask never sets new bits.
Failure modes: wrong mask, signed shift behavior, invalid shift count.

Minimal concrete example (pseudocode)

INPUT: value, mask
if (value AND mask) != 0:
  bit is set

Common misconceptions

“Bitwise and logical operators are interchangeable.” They are not; bitwise operates on every bit. citeturn4search13
“Shifts always divide or multiply.” Only safe for unsigned values and valid shift counts. citeturn4search16

Check-your-understanding questions

How do you test whether bit 5 is set?
Why is XOR useful for toggling bits?
What happens if you shift by a value equal to the width of a type in C?

Check-your-understanding answers

AND the value with (1 « 5) and check if result is nonzero.
XOR flips only the bits that are 1 in the mask. citeturn4search13
The behavior is undefined in C. citeturn4search16

Real-world applications

Permission bits in Unix files
Protocol flags and packed headers
Feature toggles and bitfields

Where you’ll apply it

Project 3 (Bitwise Logic Calculator)
Project 7 (Flag/Permission Decoder)
Project 12 (Bitfield Packing Lab)

References

“Computer Systems: A Programmer’s Perspective” - Ch. 2
Bitwise operators and shifts in C. citeturn4search13turn4search16

Key insights Masks turn raw bits into precise, testable meaning.

Summary Bitwise operators are the primitive tools for working with packed data, flags, and binary layouts. Mastery here makes later file and protocol work feel obvious.

Homework/Exercises

Write a mask to extract bits 4-7.
Describe how to clear bit 2 in a value.
Explain why shift counts must be validated.

Solutions

Mask = 0b1111 « 4.
AND with the inverse of (1 « 2).
Shifting by >= width is undefined and can corrupt results. citeturn4search16

Concept 4: Signed Integers and Two’s Complement

Fundamentals Modern instruction sets interpret registers as either unsigned binary integers or two’s-complement signed integers. citeturn3search6 Two’s complement lets the same bit pattern represent both a signed and an unsigned value; the interpretation depends on context. This is why 0xFF can be 255 (unsigned) or -1 (signed). Two’s complement is the dominant representation because addition and subtraction work the same for signed and unsigned values, simplifying hardware and software.

Deep Dive Two’s complement represents negative numbers by inverting bits and adding one. This makes arithmetic uniform: the same adder can handle signed and unsigned values. citeturn3search6 For an n-bit value, the representable signed range is -2^(n-1) to 2^(n-1)-1. This is not a rule pulled from thin air; it follows from the fact that the most significant bit is the sign bit and all remaining bits are magnitude bits. When the sign bit is 1, the value is negative, and the two’s-complement mapping guarantees a unique representation for each integer in the range.

Sign extension is another critical idea: when you widen a signed value from, say, 8 bits to 32 bits, you must replicate the sign bit into the new high bits so the numeric value remains the same. If you zero-extend instead, you silently turn negative values into large positives. This is a common bug in binary parsing, especially when reading file fields of smaller widths and storing them into larger types.

Overflow is also different in signed contexts. Adding two positive numbers may produce a negative result if the sign bit flips; subtracting can overflow in the other direction. Your projects should treat signed overflow as a diagnostic signal rather than a normal operation. The most reliable approach is to perform range checks in a larger width or to track overflow by checking sign-bit transitions.

Two’s complement also explains why bitwise NOT is equivalent to negation minus one: ~x == -x - 1. This identity is a useful sanity check when debugging bitwise transformations and helps you reason about masks and sign bits without memorizing formulas.

How this fits on projects

Project 4 (Two’s-Complement Range Explorer)
Project 7 (Flag/Permission Decoder, sign bits)
Project 9 (Hexdump Clone, signed vs unsigned display)

Definitions & key terms

Two’s complement: signed integer representation used by modern ISAs. citeturn3search6
Sign bit: the most significant bit indicating sign.
Sign extension: replicating the sign bit when widening.
Overflow: result exceeds representable range.

Mental model diagram

8-bit two's complement

0000 =  0
1111 =  127
0000 = -128
1111 = -1

How it works (step-by-step, invariants, failure modes)

Interpret the most significant bit as the sign.
For negative values, invert bits and add one to recover magnitude.
When widening, copy the sign bit into new bits.
Invariant: bit patterns do not change, only interpretation does.
Failure modes: zero-extending signed values, ignoring overflow.

Minimal concrete example (pseudocode)

INPUT: 8-bit value v
if highest_bit(v) == 0: value = v
else: value = -((invert(v) + 1) in 8-bit width)

Common misconceptions

“Signed and unsigned are different bit patterns.” They are the same bits with different meaning. citeturn3search6
“Negative numbers are stored with a minus sign.” No, they are stored as two’s-complement bit patterns.

Check-your-understanding questions

What is the signed value of 0x80 in 8-bit two’s complement?
Why must sign extension copy the sign bit?
What is ~0 in two’s complement?

Check-your-understanding answers

-128.
To preserve the numeric value when widening.
~0 is all 1s, which equals -1 in two’s complement.

Real-world applications

Signed fields in file formats
Arithmetic flags and overflow detection
Debugging hexdumps with signed/unsigned views

Where you’ll apply it

Project 4 (Two’s-Complement Explorer)
Project 9 (Hexdump Clone)

References

“Computer Systems: A Programmer’s Perspective” - Ch. 2
RISC-V ISA two’s-complement statement. citeturn3search6

Key insights Signedness is an interpretation choice, not a storage change.

Summary Two’s complement makes signed arithmetic consistent with unsigned arithmetic and explains negative values in binary.

Homework/Exercises

Convert -5 into 8-bit two’s complement.
Show the sign extension of 0x80 from 8 bits to 16 bits.
Explain why the signed range is asymmetric.

Solutions

0000 0101 -> invert -> 1111 1010 -> +1 -> 1111 1011.
0x80 (1000 0000) becomes 0xFF80 (1111 1111 1000 0000).
There is one extra negative value because zero is represented only once.

Concept 5: Endianness and Byte Order

Fundamentals Endianness describes the order of bytes when multi-byte values are stored or transmitted. Network byte order is big-endian (most significant byte first), while many host systems (such as i386) use little-endian ordering. citeturn2search5 This means the same numeric value can appear as different byte sequences depending on the context. Understanding byte order is essential for parsing files, protocols, and binary data structures correctly.

Deep Dive Consider a 32-bit value 0x12345678. In big-endian, the bytes appear in memory as 12 34 56 78. In little-endian, they appear as 78 56 34 12. The numeric value is identical; the difference is the ordering of bytes. This ordering is not arbitrary: protocols and file formats define a specific order for interoperability. The Internet uses network byte order (big-endian) so that hosts with different native ordering can communicate; conversion functions like htonl/ntohl exist to translate between host order and network order. citeturn2search5

Endianness bugs are subtle because data looks correct at the byte level but is interpreted incorrectly at the value level. For example, if you read a 2-byte length field from a file that is defined as big-endian but interpret it on a little-endian host without swapping, you will read a completely different length. The fix is not guesswork: you must read the specification and apply byte-order conversions explicitly.

There is also the concept of “mixed-endian” or word-swapped formats where 16-bit chunks are little-endian but 32-bit words are arranged differently. These are rare but do exist in legacy systems. Your projects will focus on the two mainstream orders and on detecting which one is required by a format.

The key invariant: byte order is a property of the representation, not the value. Always store values in a known order, and convert on input/output boundaries. You should also treat endianness as metadata in your tools: every dump or parse output should state the assumed byte order.

How this fits on projects

Project 5 (Endianness Inspector)
Project 9 (Hexdump Clone)
Project 11 (BMP Header Decoder)

Definitions & key terms

Big-endian: most significant byte first. citeturn2search5
Little-endian: least significant byte first. citeturn2search5
Network byte order: big-endian ordering for Internet protocols. citeturn2search5

Mental model diagram

Value: 0x12 34 56 78
Big-endian:    12 34 56 78
Little-endian: 78 56 34 12

How it works (step-by-step, invariants, failure modes)

Identify the required byte order from the spec or protocol.
Read bytes in that order into a value.
If host order differs, swap bytes before using the value.
Invariant: values are preserved across conversions.
Failure modes: reading without conversion, mixing orders within a structure.

Minimal concrete example (pseudocode)

INPUT: bytes b0..b3 in big-endian
value = b0<<24 | b1<<16 | b2<<8 | b3

Common misconceptions

“Endianness is only about CPUs.” Files and protocols define byte order too.
“Hex dumps show numbers.” They show bytes; you decide order.

Check-your-understanding questions

What is network byte order?
How would 0x00 01 be interpreted in big-endian vs little-endian?
Why are byte-order conversion functions necessary?

Check-your-understanding answers

Big-endian ordering used on the Internet. citeturn2search5
Big-endian: 1. Little-endian: 256.
To translate between host order and the order required by a protocol or file. citeturn2search5

Real-world applications

Network protocol headers
Cross-platform file formats

Where you’ll apply it

Project 5 (Endianness Inspector)
Project 11 (BMP Header Decoder)

References

“Computer Systems: A Programmer’s Perspective” - Ch. 2
POSIX htonl/ntohl byte-order behavior. citeturn2search5

Key insights Byte order is a contract, not a preference.

Summary Endianness determines how multi-byte values are laid out; always honor the specified order to avoid silent data corruption.

Homework/Exercises

Convert 0x1234 to little-endian byte order.
Explain how you would detect endianness in a file format.
Create a 16-bit swap operation using shifts and masks.

Solutions

Little-endian bytes: 34 12.
Read the spec or validate against known test vectors.
Swap = (value«8) (value»8) using a 16-bit mask.

Concept 6: Text Encoding and Binary File Forensics

Fundamentals ASCII is a 7-bit character code; it defines a standard 7-bit representation for text. citeturn2search7 UTF-8 encodes Unicode code points in 1 to 4 octets and preserves the full US-ASCII range, so ASCII text is valid UTF-8 text. citeturn1search2 File type identification tools use “magic” patterns or magic numbers: they check bytes at specific offsets to identify file types regardless of extension. citeturn2search0 Hexdump tools like xxd produce a byte-level view of files and can also reverse a hex dump back into binary. citeturn3search1

Deep Dive Text is just bytes interpreted through an encoding. ASCII maps 7-bit values to characters; UTF-8 extends this by using variable-length byte sequences for code points beyond the ASCII range. citeturn2search7turn1search2 The compatibility property of UTF-8 is crucial: any byte in the ASCII range (0x00-0x7F) is still that same character in UTF-8. citeturn1search2 This is why UTF-8 is a safe default for systems that evolved from ASCII-based tooling.

Binary files often embed readable text fields inside a larger byte structure. A hexdump lets you see both the hex bytes and a best-effort ASCII column so you can detect signatures, strings, and structure boundaries. Tools like xxd produce a consistent layout: offset, hex bytes, and an ASCII rendering. citeturn3search1 By default, you are reading raw bytes; if you interpret those bytes as ASCII or UTF-8, you will see human-readable strings where they exist.

File signatures (magic numbers) are another forensic lens. The file(1) utility checks magic patterns at specific offsets to decide file type, often using a database of rules called the magic file. citeturn2search0 This means you can identify files by content even if their filenames are misleading. Your projects will teach you to replicate this logic: read bytes at offsets, compare to known patterns, and report matches in a structured way. The technique is simple but powerful: it underpins malware analysis, digital forensics, and file-type detection in operating systems.

The key invariant: bytes are neutral; encoding and interpretation give them meaning. A sequence of bytes can be a valid UTF-8 string, a binary header, or an instruction stream depending on the context. Your tools must make that context explicit.

How this fits on projects

Project 6 (ASCII/UTF-8 Inspector)
Project 8 (File Signature Identifier)
Project 9 (Hexdump Clone)

Definitions & key terms

ASCII: 7-bit character set. citeturn2search7
UTF-8: variable-length Unicode encoding, 1-4 octets. citeturn1search2
Magic number: file-identifying byte pattern. citeturn2search0
Hexdump: byte-oriented textual rendering of binary data. citeturn3search1

Mental model diagram

bytes -> encoding -> text
bytes -> parser  -> header fields
bytes -> rules   -> file type

How it works (step-by-step, invariants, failure modes)

Read raw bytes without applying a text encoding.
If the context is text, decode using UTF-8 with ASCII compatibility. citeturn1search2
If the context is a file, test magic patterns at offsets. citeturn2search0
Invariant: raw bytes are unchanged; only the interpretation changes.
Failure modes: assuming ASCII when data is binary, ignoring offset rules.

Minimal concrete example (pseudocode)

INPUT: byte buffer
if bytes at offset 0 match a magic pattern:
  report file type
else if bytes decode as valid UTF-8:
  show text view
else:
  show hex view

Common misconceptions

“Text files are not binary.” All files are binary; text is an interpretation. citeturn2search7turn1search2
“Extensions determine file type.” Magic numbers often override extensions. citeturn2search0

Check-your-understanding questions

Why is ASCII text valid UTF-8?
What does a magic-number rule compare?
What does a hexdump show beyond raw bytes?

Check-your-understanding answers

UTF-8 preserves the US-ASCII range as single-byte values. citeturn1search2
Bytes at a defined offset in the file. citeturn2search0
Offsets and a best-effort ASCII rendering. citeturn3search1

Real-world applications

File type identification and forensics
Debugging corrupted text encodings
Malware triage and binary inspection

Where you’ll apply it

Project 6 (ASCII/UTF-8 Inspector)
Project 8 (File Signature Identifier)
Project 9 (Hexdump Clone)

References

RFC 20 (ASCII) and RFC 3629 (UTF-8). citeturn2search7turn1search2
magic(5) man page. citeturn2search0
xxd(1) man page. citeturn3search1

Key insights Bytes are inert; interpretation makes them meaningful.

Summary Understanding encoding and magic-number forensics turns opaque byte streams into readable, testable structures.

Homework/Exercises

Explain why UTF-8 is a safe default for legacy ASCII tools.
Describe how a magic-number rule is structured.
Sketch the columns of a standard hexdump line.

Solutions

ASCII bytes map directly to UTF-8 single-byte sequences. citeturn1search2
Offset + type + value comparison. citeturn2search0
Offset, hex bytes, ASCII view. citeturn3search1

Glossary

Bit: a binary digit; one of two possible states. citeturn5search0
Byte: an eight-bit unit of information. citeturn5search1
Nibble: four bits, half a byte. citeturn4search12
Hexadecimal: base-16 numeral system using 0-9 and A-F. citeturn6search0
ASCII: 7-bit character code. citeturn2search7
UTF-8: 1-4 octet Unicode encoding with ASCII compatibility. citeturn1search2
Endianness: byte order for multi-byte values. citeturn2search5
Magic number: byte pattern used to identify file types. citeturn2search0

Why Binary & Hexadecimal Matters

Most digital systems store data as bits and bytes, so reading hex is the shortest path from raw storage to meaning. citeturn5search0turn5search1
UTF-8 is used by 98.9% of websites with known encodings (W3Techs, 28 Dec 2025), so understanding byte-level encoding is directly relevant to modern software. citeturn0search0
Internet protocols use a defined network byte order (big-endian), so byte-order literacy is required for cross-platform correctness. citeturn2search5

ASCII diagram: old vs new mental model

OLD VIEW                            NEW VIEW
"Text is text"                      "Text is bytes + encoding"
File extension decides type         Magic-number rules decide type
"Numbers are decimal"               "Numbers are values + base"

Concept Summary Table

Concept Cluster	What You Need to Internalize
Positional Systems	Base determines place value; conversion is just re-expression.
Bits/Bytes/Nibbles	Bytes are 8 bits, nibbles are 4 bits, hex maps to nibble boundaries.
Bitwise Operations	AND/OR/XOR/NOT and shifts are the primitives of packed data.
Two’s Complement	Signed integers are the same bits with different interpretation.
Endianness	Byte order is a contract; always parse according to spec.
Encoding & Forensics	ASCII/UTF-8 decoding and magic-number rules make bytes readable.

Project-to-Concept Map

Project	Concepts Applied
Project 1	Positional Systems, Bits/Bytes/Nibbles
Project 2	Bits/Bytes/Nibbles, Encoding & Forensics
Project 3	Bitwise Operations
Project 4	Two’s Complement
Project 5	Endianness
Project 6	Encoding & Forensics
Project 7	Bitwise Operations, Two’s Complement
Project 8	Encoding & Forensics, Endianness
Project 9	Bits/Bytes/Nibbles, Encoding & Forensics
Project 10	Bitwise Operations, Endianness
Project 11	Endianness, Encoding & Forensics
Project 12	Bitwise Operations, Bits/Bytes/Nibbles

Deep Dive Reading by Concept

Concept	Book and Chapter	Why This Matters
Positional Systems	“Computer Systems: A Programmer’s Perspective” - Ch. 2	Core data representation chapter
Bits/Bytes/Nibbles	“Code” by Charles Petzold - Ch. 7-8	Builds intuition for binary and hex
Bitwise Operations	“Computer Systems: A Programmer’s Perspective” - Ch. 2	Operator semantics and masks
Two’s Complement	“Computer Systems: A Programmer’s Perspective” - Ch. 2	Signed integer representation
Endianness	“Computer Systems: A Programmer’s Perspective” - Ch. 2	Byte order and data layout
Encoding & Forensics	“The C Programming Language” - Ch. 7	Byte-level I/O and text handling

Quick Start: Your First 48 Hours

Day 1:

Read Theory Primer Concepts 1-2.
Start Project 1 and implement decimal <-> binary conversions.

Day 2:

Validate Project 1 with test vectors and a known tool.
Read Concept 3 and skim Project 3’s pitfalls and hints.

Recommended Learning Paths

Path 1: The Systems Programmer

Project 1 -> Project 3 -> Project 4 -> Project 5 -> Project 9 -> Project 11

Path 2: The Web Developer

Project 1 -> Project 2 -> Project 6 -> Project 9

Path 3: The Forensics/Reverse-Engineering Learner

Project 1 -> Project 8 -> Project 9 -> Project 10 -> Project 11

Success Metrics

You can convert any 16-bit value between decimal, binary, and hex without tools.
You can explain why a hexdump line shows certain ASCII characters.
You can correctly parse a multi-byte value from a known byte order.
You can write a bitmask to extract and insert fields without trial-and-error.

Project Overview Table

#	Project Name	Main Language	Difficulty	Time Estimate	Core Concepts	Coolness
1	Universal Base Converter	C/Python	Level 1	4-8 hrs	Positional Systems	Level 2
2	Hex Color Visualizer	JS/Python	Level 1	4-8 hrs	Nibbles, Encoding	Level 2
3	Bitwise Logic Calculator	C	Level 2	6-10 hrs	Bitwise Operations	Level 2
4	Two’s-Complement Explorer	C/Python	Level 2	8-12 hrs	Two’s Complement	Level 3
5	Endianness Inspector	C	Level 2	8-12 hrs	Endianness	Level 3
6	ASCII/UTF-8 Inspector	C/Python	Level 2	8-12 hrs	Encoding	Level 2
7	Flag/Permission Decoder	C	Level 2	6-10 hrs	Bitwise Ops	Level 3
8	File Signature Identifier	C	Level 3	10-20 hrs	Magic Numbers	Level 3
9	Hexdump Clone	C	Level 3	15-25 hrs	Hexdumps	Level 4
10	Binary Diff & Patch	C/Python	Level 3	15-25 hrs	Bitfields/Order	Level 3
11	BMP Header Decoder	C	Level 3	12-20 hrs	Endianness	Level 3
12	Bitfield Packing Lab	C	Level 3	12-20 hrs	Masks/Fields	Level 3

Project List

The following projects guide you from base conversion to practical binary forensics and tooling.

Project 1: Universal Base Converter

File: P01-universal-base-converter.md
Main Programming Language: C or Python
Alternative Programming Languages: Rust, Go, JavaScript
Coolness Level: Level 2 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 1 (See REFERENCE.md)
Knowledge Area: Parsing, Numeric Representation
Software or Tool: CLI
Main Book: “Computer Systems: A Programmer’s Perspective”

What you will build: A CLI tool that converts numbers between decimal, binary, and hex.

Why it teaches binary/hex: You will implement the exact conversion algorithms that make these systems equivalent.

Core challenges you will face:

Valid digit parsing -> Positional Systems
Division/remainder conversion -> Positional Systems
Output formatting -> Bits/Bytes/Nibbles

Real World Outcome

You can run the tool on any value and get verified conversions.

$ baseconv --from dec --to hex 255
FF

$ baseconv --from hex --to bin 7B
01111011

The Core Question You Are Answering

“How does the same value survive a change of representation without changing its meaning?”

This forces you to distinguish the value from its notation.

Concepts You Must Understand First

Positional notation
- What does each digit position mean?
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Hex digit set
- How do digits A-F map to decimal values?
- Book Reference: “Code” by Charles Petzold - Ch. 7-8
Remainder-based conversion
- Why do remainders form digits in reverse?
- Book Reference: “Grokking Algorithms” - Ch. 1

Questions to Guide Your Design

Input format
- How will you parse prefixes like 0x or 0b?
- How will you validate digit sets for each base?
Conversion engine
- Will you convert via decimal or support direct base-to-base?
- How will you avoid overflow for large inputs?

Thinking Exercise

Manual Conversion Walkthrough

Trace the conversion of 123 (decimal) to binary by hand. Then reverse the process by parsing the binary result back to decimal.

Questions to answer:

Where do remainders appear in the final string?
How does the place-value expansion recover the original number?

The Interview Questions They Will Ask

“Explain how you convert decimal to binary without using built-in functions.”
“Why does hex map cleanly to binary?”
“How would you validate a user-provided number in an arbitrary base?”
“What is the time complexity of repeated-division conversion?”
“How do you handle numbers that exceed standard integer sizes?”

Hints in Layers

Hint 1: Starting Point Use a left-to-right parser for base-to-decimal and a remainder loop for decimal-to-base.

Hint 2: Next Level Store digits as integers, then map 0-15 to 0-9/A-F during formatting.

Hint 3: Technical Details Pseudocode outline:

parse(digits, base):
  acc = 0
  for each digit:
    acc = acc * base + value(digit)
  return acc

format(value, base):
  remainders = []
  while value > 0:
    remainders.append(value % base)
    value = value / base
  return reverse(remainders)

Hint 4: Tools/Debugging Compare your outputs against python3 -c "print(hex(n))" for random inputs.

Books That Will Help

Topic	Book	Chapter
Data representation	“Computer Systems: A Programmer’s Perspective”	Ch. 2
Number systems	“Code” by Charles Petzold	Ch. 7-8

Common Pitfalls and Debugging

Problem 1: “Hex digits above 9 are rejected”

Why: You only accept 0-9 in the digit parser.
Fix: Extend the digit map to A-F and a-f.
Quick test: Convert FF to 255 and back.

Definition of Done

Converts between dec, bin, hex for all 0..65535
Rejects invalid digits for a base
Matches outputs from a trusted tool for random tests
Includes a small test vector file

Project 2: Hex Color Visualizer

File: P02-hex-color-visualizer.md
Main Programming Language: JavaScript or Python
Alternative Programming Languages: C, Rust, Go
Coolness Level: Level 2 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 1 (See REFERENCE.md)
Knowledge Area: Encoding, Visualization
Software or Tool: Web or CLI UI
Main Book: “Code” by Charles Petzold

What you will build: A tool that accepts a hex color code and displays RGB values and a color swatch.

Why it teaches binary/hex: Hex color notation encodes RGB values in hex pairs. citeturn0search3

Core challenges you will face:

Hex parsing -> Bits/Bytes/Nibbles
Pair-to-decimal conversion -> Positional Systems
Rendering feedback -> Encoding & Interpretation

Real World Outcome

For web UI: a page with an input box, a live color swatch, and numeric RGB values.

Example behavior:

Input: #33CC99
Output: RGB(51, 204, 153)
Swatch: a teal-green block filling a 200x200 square

The Core Question You Are Answering

“How do three pairs of hex digits become visible color?”

Concepts You Must Understand First

Hex digit pairs
- Why do two hex digits represent one byte?
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
RGB channels
- Why are colors stored as separate byte values?
- Book Reference: “Code” by Charles Petzold - Ch. 7-8
Hex color notation
- Why is #RRGGBB the standard? citeturn0search3
- Book Reference: “Code” by Charles Petzold - Ch. 7-8

Questions to Guide Your Design

Input handling
- How will you normalize 3-digit vs 6-digit input?
- How will you handle alpha if present?
Conversion
- Will you parse by pairs or convert through binary?
- How will you validate that digits are hex-safe?

Thinking Exercise

Color as Bytes

Imagine a pixel in memory as 3 bytes: R, G, B. Sketch what bytes correspond to pure red and pure green.

Questions to answer:

Why does 00 mean “none” and FF mean “full”?
What is the binary representation of 0x33?

The Interview Questions They Will Ask

“Why does CSS use hex for colors?” citeturn0search3
“How do you validate a hex color input?”
“How would you support 3-digit shorthand?” citeturn0search3
“What does the alpha channel represent?”
“How would you convert #FF00FF to RGB?”

Hints in Layers

Hint 1: Starting Point Strip the leading #, then split into pairs.

Hint 2: Next Level Support 3-digit input by duplicating each digit (e.g., F -> FF). citeturn0search3

Hint 3: Technical Details Pseudocode:

if length == 3:
  expand each digit to two digits
for each pair:
  value = parse_hex(pair)

Hint 4: Tools/Debugging Compare against a browser’s built-in color picker.

Books That Will Help

Topic	Book	Chapter
Number systems	“Code” by Charles Petzold	Ch. 7-8
Data representation	“Computer Systems: A Programmer’s Perspective”	Ch. 2

Common Pitfalls and Debugging

Problem 1: “My colors are inverted”

Why: You reversed byte order when parsing.
Fix: Ensure the order is R then G then B. citeturn0search3
Quick test: #FF0000 should be pure red.

Definition of Done

Accepts 3- and 6-digit hex colors
Displays correct RGB values
Shows a visible color swatch
Rejects invalid characters

Project 3: Bitwise Logic Calculator

File: P03-bitwise-logic-calculator.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 2 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 2 (See REFERENCE.md)
Knowledge Area: Bitwise Logic
Software or Tool: CLI
Main Book: “Computer Systems: A Programmer’s Perspective”

What you will build: A CLI tool that performs AND, OR, XOR, NOT, and shift operations and prints results in binary and hex.

Why it teaches binary/hex: Bitwise operations act directly on bit patterns. citeturn4search13

Core challenges you will face:

Operator semantics -> Bitwise Operations
Shift validation -> Bitwise Operations
Binary formatting -> Bits/Bytes/Nibbles

Real World Outcome

$ bitcalc AND 0xF0 0x3C
result_hex: 0x30
result_bin: 00110000

The Core Question You Are Answering

“How do I control individual bits inside a number?”

Concepts You Must Understand First

Bitwise operators
- What does AND/OR/XOR/NOT do per bit? citeturn4search13
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Shifts
- What are safe shift counts? citeturn4search16
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2

Questions to Guide Your Design

Input parsing
- Will you allow decimal and hex input?
- How will you display binary output consistently?
Validation
- How will you reject invalid shift amounts?
- How will you handle negative inputs?

Thinking Exercise

Mask Reasoning

Given a mask 0x0F, explain which bits are preserved after AND.

Questions to answer:

Which bits survive an AND with 0x0F?
What would OR with 0x80 do?

The Interview Questions They Will Ask

“Explain how AND is used to test a flag.” citeturn4search13
“What is the difference between logical and bitwise operators?” citeturn4search13
“Why is shifting by 32 undefined for a 32-bit integer?” citeturn4search16
“How would you toggle bit 7?”
“What is XOR useful for?” citeturn4search13

Hints in Layers

Hint 1: Starting Point Implement each operator separately and print both hex and binary results.

Hint 2: Next Level Normalize inputs to unsigned values before shifting.

Hint 3: Technical Details Pseudocode:

result = apply_op(op, a, b)
print hex(result)
print bin(result, width=8 or 16)

Hint 4: Tools/Debugging Use a trusted language REPL to compare outputs for random inputs.

Books That Will Help

Topic	Book	Chapter
Bitwise operators	“Computer Systems: A Programmer’s Perspective”	Ch. 2

Common Pitfalls and Debugging

Problem 1: “My shifts produce garbage”

Why: You are shifting signed values or shifting too far. citeturn4search16
Fix: Use unsigned values and validate shift counts.
Quick test: Shift 1 left by 1, 2, 3 and verify powers of two.

Definition of Done

Supports AND, OR, XOR, NOT, «, »
Prints results in hex and binary
Validates shift amounts
Includes a test suite of known vectors

Project 4: Two’s-Complement Range Explorer

File: P04-twos-complement-explorer.md
Main Programming Language: C or Python
Alternative Programming Languages: Rust, Go, Java
Coolness Level: Level 3 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 2 (See REFERENCE.md)
Knowledge Area: Signed Integers
Software or Tool: CLI
Main Book: “Computer Systems: A Programmer’s Perspective”

What you will build: A tool that prints the signed and unsigned interpretation of the same bit pattern for multiple bit widths.

Why it teaches binary/hex: Two’s complement shows how interpretation changes meaning while bits stay the same. citeturn3search6

Core challenges you will face:

Range calculation -> Two’s Complement
Sign extension -> Two’s Complement
Overflow detection -> Two’s Complement

Real World Outcome

$ twos-explore --width 8 --value 0xFF
unsigned: 255
signed:   -1
binary:   11111111
range:    -128 .. 127

The Core Question You Are Answering

“How can the same bits mean two different numbers?”

Concepts You Must Understand First

Two’s complement
- Why is it the standard for signed integers? citeturn3search6
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Bit width
- How does width determine range?
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2

Questions to Guide Your Design

Input
- Will you accept hex, binary, and decimal?
- How will you normalize to a fixed width?
Output
- How will you show signed/unsigned side by side?
- Will you display range boundaries?

Thinking Exercise

Signed vs Unsigned Table

Make a table of 4-bit values (0x0 to 0xF) and annotate their signed meaning.

Questions to answer:

Why does 0x8 become negative?
Which value has no positive counterpart?

The Interview Questions They Will Ask

“Explain two’s complement in your own words.” citeturn3search6
“Why is the signed range asymmetric?”
“What is sign extension and why does it matter?”
“How do you detect signed overflow?”
“What is the signed value of 0x80 in 8-bit?”

Hints in Layers

Hint 1: Starting Point Mask the input to the requested width.

Hint 2: Next Level If the sign bit is set, compute negative value by invert+1.

Hint 3: Technical Details Pseudocode:

if sign_bit_set(value, width):
  signed = -((invert(value) + 1) within width)
else:
  signed = value

Hint 4: Tools/Debugging Cross-check with a language that lets you set fixed-width integers.

Books That Will Help

Topic	Book	Chapter
Integer representation	“Computer Systems: A Programmer’s Perspective”	Ch. 2

Common Pitfalls and Debugging

Problem 1: “Negative values look wrong”

Why: You are not masking to width before interpreting.
Fix: Apply a width mask before any sign logic.
Quick test: 0xFF at width 8 should be -1.

Definition of Done

Shows signed and unsigned for any width 4-32
Displays binary form with sign bit highlighted
Handles overflow boundaries correctly
Includes a test table for 4- and 8-bit widths

Project 5: Endianness Inspector and Byte Swapper

File: P05-endianness-inspector.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 3 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 2 (See REFERENCE.md)
Knowledge Area: Endianness
Software or Tool: CLI
Main Book: “Computer Systems: A Programmer’s Perspective”

What you will build: A tool that detects host endianness and swaps byte order for 16-, 32-, and 64-bit values.

Why it teaches binary/hex: Endianness is the difference between byte order and value meaning. citeturn2search5

Core challenges you will face:

Byte-order detection -> Endianness
Swap correctness -> Endianness
Formatting -> Bits/Bytes/Nibbles

Real World Outcome

$ endian-check
host_order: little-endian

$ endian-swap --width 32 --value 0x12345678
swapped: 0x78563412

The Core Question You Are Answering

“When do the same bytes mean a different number?”

Concepts You Must Understand First

Network byte order
- Why is it big-endian? citeturn2search5
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Byte swapping
- How do you reverse byte order without losing bits?
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2

Questions to Guide Your Design

Detection
- How will you detect host order at runtime?
Swapping
- Will you implement swaps with shifts and masks or byte arrays?

Thinking Exercise

Byte Order Table

Write the bytes of 0x01020304 in both endian orders.

Questions to answer:

Which order matches memory on your machine?
Which order matches network order? citeturn2search5

The Interview Questions They Will Ask

“What is network byte order?” citeturn2search5
“How do you detect endianness at runtime?”
“Why do file formats specify byte order?”
“How do you swap bytes without using library functions?”
“What breaks if you ignore endianness?”

Hints in Layers

Hint 1: Starting Point Use a 16-bit value 0x0102 and inspect its byte order in memory.

Hint 2: Next Level Implement swap by shifting bytes into new positions.

Hint 3: Technical Details Pseudocode:

swap32(x):
  return (x>>24) | ((x>>8)&0xFF00) | ((x<<8)&0xFF0000) | (x<<24)

Hint 4: Tools/Debugging Compare against htonl and ntohl results. citeturn2search5

Books That Will Help

Topic	Book	Chapter
Byte order	“Computer Systems: A Programmer’s Perspective”	Ch. 2

Common Pitfalls and Debugging

Problem 1: “Swap works for 16-bit but not 32-bit”

Why: You are not masking intermediate shifts.
Fix: Mask each shifted byte before recombining.
Quick test: Swap 0x01020304 -> 0x04030201.

Definition of Done

Detects host endianness
Swaps 16/32/64-bit values correctly
Includes test vectors
Explains when to use network byte order

Project 6: ASCII/UTF-8 Byte Inspector

File: P06-ascii-utf8-inspector.md
Main Programming Language: C or Python
Alternative Programming Languages: Rust, Go, JavaScript
Coolness Level: Level 2 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 2 (See REFERENCE.md)
Knowledge Area: Encoding
Software or Tool: CLI
Main Book: “The C Programming Language”

What you will build: A tool that reads a file and prints the byte offset, hex value, and ASCII/UTF-8 interpretation.

Why it teaches binary/hex: ASCII is 7-bit and UTF-8 is 1-4 octets with ASCII compatibility. citeturn2search7turn1search2

Core challenges you will face:

Encoding detection -> Encoding & Forensics
Byte inspection -> Bits/Bytes/Nibbles
UTF-8 validation -> Encoding & Forensics

Real World Outcome

$ textinspect sample.txt
00000000  48 65 6c 6c 6f 0a   ASCII: Hello.

The Core Question You Are Answering

“What do bytes mean when I claim they are text?”

Concepts You Must Understand First

ASCII
- Why is it 7-bit? citeturn2search7
- Book Reference: “The C Programming Language” - Ch. 7
UTF-8
- How does it encode 1-4 octets? citeturn1search2
- Book Reference: “The C Programming Language” - Ch. 7

Questions to Guide Your Design

Output format
- How will you align hex and text columns?
Validation
- Will you reject invalid UTF-8 sequences or mark them?

Thinking Exercise

ASCII in Hex

Write the hex values for the string “Hi” and mark where ASCII ends in UTF-8.

Questions to answer:

Why does UTF-8 preserve ASCII bytes? citeturn1search2
How would you display a non-ASCII byte?

The Interview Questions They Will Ask

“Why is ASCII compatible with UTF-8?” citeturn1search2
“How do you validate UTF-8 byte sequences?”
“Why is ASCII only 7-bit?” citeturn2search7
“What should a hexdump show for control characters?”
“How do you display non-printable bytes?”

Hints in Layers

Hint 1: Starting Point Print offset, hex bytes, and a ‘.’ for non-printable bytes.

Hint 2: Next Level Implement a minimal UTF-8 validator that checks leading byte patterns.

Hint 3: Technical Details Pseudocode:

for each byte:
  if 0x20 <= byte <= 0x7E: print ASCII char
  else: print '.'

Hint 4: Tools/Debugging Compare your output with xxd for the same file. citeturn3search1

Books That Will Help

Topic	Book	Chapter
I/O and text	“The C Programming Language”	Ch. 7

Common Pitfalls and Debugging

Problem 1: “My UTF-8 validator rejects valid text”

Why: You mis-handle continuation bytes.
Fix: Ensure continuation bytes begin with 10xxxxxx. citeturn1search2
Quick test: Validate a pure ASCII file; it should pass. citeturn1search2

Definition of Done

Prints offset, hex, and ASCII columns
Handles non-printable bytes consistently
Validates UTF-8 sequences
Matches xxd output layout for ASCII files

Project 7: Flag and Permission Decoder

File: P07-flag-decoder.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 3 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 2 (See REFERENCE.md)
Knowledge Area: Bitfields
Software or Tool: CLI
Main Book: “Computer Systems: A Programmer’s Perspective”

What you will build: A CLI tool that decodes a packed integer into named flags and permissions.

Why it teaches binary/hex: Flags are compact bitfields controlled by masks and shifts. citeturn4search13

Core challenges you will face:

Mask extraction -> Bitwise Operations
Readable output -> Bits/Bytes/Nibbles
Edge cases -> Two’s Complement

Real World Outcome

$ flagdecode --mode 0x1ED
rwxr-xr-x
flags: USER_READ, USER_WRITE, USER_EXEC, GROUP_READ, GROUP_EXEC, OTHER_READ, OTHER_EXEC

The Core Question You Are Answering

“How do multiple boolean states fit inside one integer?”

Concepts You Must Understand First

Masks and shifts
- How to isolate a bit? citeturn4search13
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Octal/hex notation
- Why permissions are often shown in octal?
- Book Reference: “The C Programming Language” - Ch. 2

Questions to Guide Your Design

Mapping
- How will you map bits to names?
Output
- Will you provide both symbolic and numeric formats?

Thinking Exercise

Bitfield Sketch

Draw a 9-bit field and label user/group/other permission bits.

Questions to answer:

Which bit corresponds to “user write”?
How do you clear one permission without touching others?

The Interview Questions They Will Ask

“How do you extract multiple flags from one integer?” citeturn4search13
“Why is bit masking faster than multiple booleans?”
“How would you represent permissions in octal?”
“How do you toggle a flag bit?” citeturn4search13
“What bugs happen with signed values?”

Hints in Layers

Hint 1: Starting Point Define a table of bit positions and their names.

Hint 2: Next Level Use AND with (1«bit) to test each flag.

Hint 3: Technical Details Pseudocode:

for each flag:
  if (value AND (1<<bit)) != 0: emit name

Hint 4: Tools/Debugging Compare output to ls -l permission strings on real files.

Books That Will Help

Topic	Book	Chapter
Bitwise logic	“Computer Systems: A Programmer’s Perspective”	Ch. 2

Common Pitfalls and Debugging

Problem 1: “Flags are off by one bit”

Why: You mis-numbered bit positions.
Fix: Draw the bitfield and label each position explicitly.
Quick test: Use a value with only one bit set.

Definition of Done

Decodes at least 12 distinct flags
Outputs symbolic and numeric forms
Handles zero and all-bits-set values
Includes a test vector table

Project 8: File Signature (Magic Number) Identifier

File: P08-file-signature-id.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 3 (See REFERENCE.md)
Business Potential: Level 2 (See REFERENCE.md)
Difficulty: Level 3 (See REFERENCE.md)
Knowledge Area: File Forensics
Software or Tool: CLI
Main Book: “Practical Binary Analysis”

What you will build: A tool that reads bytes at offsets and identifies files based on magic patterns.

Why it teaches binary/hex: File identification relies on magic-number rules evaluated against byte sequences. citeturn2search0

Core challenges you will face:

Binary file I/O -> Encoding & Forensics
Pattern matching -> Bits/Bytes/Nibbles
Rule-driven parsing -> Encoding & Forensics

Real World Outcome

$ magicid samples/
file.bin: unknown
image.bin: matched rule "PNG"
doc.bin: matched rule "PDF"

The Core Question You Are Answering

“How can you identify a file by its bytes instead of its name?”

Concepts You Must Understand First

Magic patterns
- What do magic files test? citeturn2search0
- Book Reference: “Practical Binary Analysis” - Ch. 3
Offsets and types
- Why do rules specify offsets and data types? citeturn2search0
- Book Reference: “The C Programming Language” - Ch. 7

Questions to Guide Your Design

Rule format
- Will you define your own rule syntax or parse an existing one?
Matching
- How will you handle overlapping patterns?

Thinking Exercise

Offset Reasoning

Imagine a signature rule that checks bytes 0-3. Why might another rule check bytes at offset 512?

Questions to answer:

What does an offset mean in the file layout?
How do you avoid false positives?

The Interview Questions They Will Ask

“How does file(1) identify file types?” citeturn2search0
“What is a magic number?” citeturn2search0
“Why are offsets part of signature rules?” citeturn2search0
“How would you design a signature database?”
“How do you handle endian-specific fields in a signature?”

Hints in Layers

Hint 1: Starting Point Start with a small JSON or text file of rules: offset + bytes + label.

Hint 2: Next Level Read only the maximum offset you need for all rules to avoid full-file reads.

Hint 3: Technical Details Pseudocode:

for each rule:
  read bytes at offset
  if bytes match pattern: report label

Hint 4: Tools/Debugging Compare results with the file command for the same inputs. citeturn2search0

Books That Will Help

Topic	Book	Chapter
File signatures	“Practical Binary Analysis”	Ch. 3
Binary I/O	“The C Programming Language”	Ch. 7

Common Pitfalls and Debugging

Problem 1: “Matches are inconsistent”

Why: You are not reading at the correct offset.
Fix: Print the bytes you compare and verify offset math.
Quick test: Create a file with a known pattern at offset 0.

Definition of Done

Loads signature rules from a file
Tests multiple offsets per file
Matches at least 5 known file types
Includes a false-positive test set

Project 9: Hexdump Clone

File: P09-hexdump-clone.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 4 (See REFERENCE.md)
Business Potential: Level 2 (See REFERENCE.md)
Difficulty: Level 3 (See REFERENCE.md)
Knowledge Area: Binary Inspection
Software or Tool: CLI
Main Book: “The C Programming Language”

What you will build: A hexdump tool that mirrors xxd-style output, with offsets and ASCII columns.

Why it teaches binary/hex: Hexdumps are the canonical view of byte-level data. citeturn3search1

Core challenges you will face:

Byte formatting -> Bits/Bytes/Nibbles
Offset handling -> Endianness
ASCII rendering -> Encoding & Forensics

Real World Outcome

$ hexview sample.bin
00000000: 48 65 6c 6c 6f 0a 00 00  Hello...

The Core Question You Are Answering

“How do I render raw bytes so humans can interpret them?”

Concepts You Must Understand First

Hex encoding
- How do bytes map to hex pairs? citeturn6search12
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
ASCII rendering
- How do you show printable vs non-printable bytes? citeturn2search7
- Book Reference: “The C Programming Language” - Ch. 7

Questions to Guide Your Design

Line width
- How many bytes per line?
- Will you support a configurable width?
Output layout
- How will you align hex columns and ASCII columns?

Thinking Exercise

Dump Layout

Sketch the columns for a 16-byte hexdump line and label the offsets.

Questions to answer:

Why include offsets at all?
Why does an ASCII column help?

The Interview Questions They Will Ask

“What does xxd do?” citeturn3search1
“How do you represent non-printable bytes in a hexdump?”
“Why is hex preferred over binary for dumps?”
“How would you handle large files efficiently?”
“What is the relationship between a hexdump and encoding?”

Hints in Layers

Hint 1: Starting Point Read file in fixed-size blocks (e.g., 16 bytes).

Hint 2: Next Level Render offset as 8 hex digits, then bytes, then ASCII.

Hint 3: Technical Details Pseudocode:

for each block:
  print offset
  print hex bytes
  print ASCII or '.'

Hint 4: Tools/Debugging Compare with xxd output for the same file. citeturn3search1

Books That Will Help

Topic	Book	Chapter
File I/O	“The C Programming Language”	Ch. 7

Common Pitfalls and Debugging

Problem 1: “Columns drift after short last line”

Why: You do not pad the final line.
Fix: Pad missing bytes with spaces before ASCII column.
Quick test: Dump a 5-byte file and check alignment.

Definition of Done

Matches xxd layout for 16-byte lines
Prints offset, hex, ASCII columns
Handles short final line gracefully
Works on large files without loading entire file

Project 10: Binary Diff and Patch Tool

File: P10-binary-diff-patch.md
Main Programming Language: C or Python
Alternative Programming Languages: Rust, Go
Coolness Level: Level 3 (See REFERENCE.md)
Business Potential: Level 2 (See REFERENCE.md)
Difficulty: Level 3 (See REFERENCE.md)
Knowledge Area: Binary Editing
Software or Tool: CLI
Main Book: “The C Programming Language”

What you will build: A tool that compares two binary files and emits a minimal patch script (offset + byte values) and can apply it.

Why it teaches binary/hex: Patching requires exact byte-level reasoning and offset discipline. citeturn3search1

Core challenges you will face:

Offset tracking -> Endianness
Byte-by-byte comparison -> Bits/Bytes/Nibbles
Patch application -> Bitwise Operations

Real World Outcome

$ bindiff a.bin b.bin
offset 0x00000010: 3A -> 7F
offset 0x0000001F: 00 -> 01

$ binpatch a.bin patch.txt out.bin
patched: 2 bytes changed

The Core Question You Are Answering

“How do I describe changes in a binary file with absolute precision?”

Concepts You Must Understand First

Byte offsets
- Why are offsets shown in hex?
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Hex rendering
- How do you display byte changes? citeturn6search12
- Book Reference: “The C Programming Language” - Ch. 7

Questions to Guide Your Design

Patch format
- How will you encode offset and byte values?
Safety
- Will you support dry-run mode?

Thinking Exercise

Patch Reasoning

Given two hex strings, mark which offsets differ and how you would encode them.

Questions to answer:

How do you avoid ambiguity about byte order?
How do you ensure patches are deterministic?

The Interview Questions They Will Ask

“How would you design a binary patch format?”
“Why is offset accuracy critical?”
“How can you verify a patch applied correctly?”
“What is the difference between text diff and binary diff?”
“How would you optimize diffing large files?”

Hints in Layers

Hint 1: Starting Point Compare files byte-by-byte and record offsets that differ.

Hint 2: Next Level Write patch lines as: offset, old byte, new byte.

Hint 3: Technical Details Pseudocode:

for offset in 0..min(lenA,lenB):
  if A[offset] != B[offset]:
    emit offset, A[offset], B[offset]

Hint 4: Tools/Debugging Use xxd -r to verify patch output when needed. citeturn3search1

Books That Will Help

Topic	Book	Chapter
File I/O	“The C Programming Language”	Ch. 7

Common Pitfalls and Debugging

Problem 1: “Patch applies but file is corrupted”

Why: You wrote offsets in decimal but read them as hex.
Fix: Enforce a single notation and document it.
Quick test: Apply patch to a known small file and compare byte-by-byte.

Definition of Done

Emits deterministic patch files
Applies patches safely and reproducibly
Includes verification by byte comparison
Handles different file lengths

Project 11: BMP Header Decoder

File: P11-bmp-header-decoder.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 3 (See REFERENCE.md)
Business Potential: Level 1 (See REFERENCE.md)
Difficulty: Level 3 (See REFERENCE.md)
Knowledge Area: File Formats
Software or Tool: CLI
Main Book: “Practical Binary Analysis”

What you will build: A tool that reads a BMP file header and prints width, height, and pixel format.

Why it teaches binary/hex: You must parse structured fields with known byte order.

Core challenges you will face:

Field extraction -> Endianness
Offset-based parsing -> Encoding & Forensics
Display formatting -> Bits/Bytes/Nibbles

Real World Outcome

$ bmpinfo sample.bmp
width: 640
height: 480
bits_per_pixel: 24
pixel_data_offset: 0x00000036

The Core Question You Are Answering

“How do bytes become structured metadata in a real file format?”

Concepts You Must Understand First

Byte order
- Which fields are little-endian?
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Offsets and sizes
- How do you compute field boundaries?
- Book Reference: “Practical Binary Analysis” - Ch. 3

Questions to Guide Your Design

Parsing
- Will you parse by reading fixed offsets or by reading structs?
Validation
- How will you validate that input is really BMP?

Thinking Exercise

Field Map

Sketch a simple header layout: offset, size, meaning. Decide which fields must be validated first.

Questions to answer:

Why must you know endianness before reading integers?
Which field tells you where pixel data starts?

The Interview Questions They Will Ask

“How do you parse a fixed-width binary header?”
“Why is endianness essential for file formats?”
“How would you validate the signature bytes?”
“What problems arise with struct padding?”
“How would you extend your parser to other formats?”

Hints in Layers

Hint 1: Starting Point Read the first 64 bytes into a buffer and parse fields by offset.

Hint 2: Next Level Use explicit little-endian conversions when assembling integers.

Hint 3: Technical Details Pseudocode:

read header bytes
width = little_endian_32(bytes[18..21])
height = little_endian_32(bytes[22..25])

Hint 4: Tools/Debugging Compare your output with a known image viewer or metadata tool.

Books That Will Help

Topic	Book	Chapter
Binary formats	“Practical Binary Analysis”	Ch. 3
Data representation	“Computer Systems: A Programmer’s Perspective”	Ch. 2

Common Pitfalls and Debugging

Problem 1: “Widths are absurdly large”

Why: You treated little-endian fields as big-endian.
Fix: Implement explicit little-endian reads.
Quick test: Use a 2x2 image and verify width/height.

Definition of Done

Correctly parses BMP header fields
Validates signature before parsing
Reports width, height, bits per pixel
Works on at least three test files

Project 12: Bitfield Packing Lab

File: P12-bitfield-packing-lab.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 3 (See REFERENCE.md)
Business Potential: Level 2 (See REFERENCE.md)
Difficulty: Level 3 (See REFERENCE.md)
Knowledge Area: Bitfields
Software or Tool: CLI
Main Book: “Computer Systems: A Programmer’s Perspective”

What you will build: A simulator that packs multiple sensor values into a single 32-bit word and unpacks them.

Why it teaches binary/hex: Real systems pack fields to save space and bandwidth using masks and shifts. citeturn4search13

Core challenges you will face:

Field packing -> Bitwise Operations
Width validation -> Bits/Bytes/Nibbles
Error detection -> Two’s Complement

Real World Outcome

$ bitpack --temp 23 --humidity 55 --status 3
packed: 0x01C837

$ bitunpack 0x01C837
temp: 23
humidity: 55
status: 3

The Core Question You Are Answering

“How do I store multiple values inside one integer without collisions?”

Concepts You Must Understand First

Masks and shifts
- How do you insert and extract fields? citeturn4search13
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2
Range limits
- How do you enforce field widths?
- Book Reference: “Computer Systems: A Programmer’s Perspective” - Ch. 2

Questions to Guide Your Design

Field layout
- How many bits will each field get?
Validation
- What happens if an input exceeds its allotted width?

Thinking Exercise

Packing Plan

Design a 32-bit layout for three fields: 10 bits, 12 bits, and 4 bits. Draw the bit positions.

Questions to answer:

Which bits belong to each field?
How do you extract a middle field?

The Interview Questions They Will Ask

“How do you pack multiple fields into one integer?” citeturn4search13
“What is the role of masks in bitfield packing?” citeturn4search13
“How do you validate field widths?”
“What happens if a field overflows?”
“How would you document a bitfield layout for a team?”

Hints in Layers

Hint 1: Starting Point Create constants for field widths and bit offsets.

Hint 2: Next Level Use (value & mask) « offset to insert.

Hint 3: Technical Details Pseudocode:

packed = (a << offsetA) | (b << offsetB) | c
extractA = (packed >> offsetA) & maskA

Hint 4: Tools/Debugging Print binary output with labeled bit positions for verification.

Books That Will Help

Topic	Book	Chapter
Bitwise logic	“Computer Systems: A Programmer’s Perspective”	Ch. 2

Common Pitfalls and Debugging

Problem 1: “Fields overlap”

Why: Offsets or widths are miscalculated.
Fix: Draw the layout and add assertions for max values.
Quick test: Use max values for each field and verify no spillover.

Definition of Done

Packs and unpacks fields correctly
Rejects values that exceed allocated width
Provides a documented bit layout
Includes binary visualization output

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
1. Base Converter	Level 1	Weekend	Medium	★★★☆☆
2. Hex Color Visualizer	Level 1	Weekend	Medium	★★★☆☆
3. Bitwise Calculator	Level 2	Weekend	High	★★★☆☆
4. Two’s Complement Explorer	Level 2	Weekend	High	★★★☆☆
5. Endianness Inspector	Level 2	Weekend	High	★★★☆☆
6. ASCII/UTF-8 Inspector	Level 2	Weekend	High	★★★☆☆
7. Flag Decoder	Level 2	Weekend	High	★★★☆☆
8. Magic Number Identifier	Level 3	2-3 weeks	Very High	★★★★☆
9. Hexdump Clone	Level 3	2-3 weeks	Very High	★★★★☆
10. Binary Diff/Patch	Level 3	2-3 weeks	Very High	★★★★☆
11. BMP Header Decoder	Level 3	2-3 weeks	High	★★★★☆
12. Bitfield Packing Lab	Level 3	2-3 weeks	Very High	★★★★☆

Recommendation

If you are new to binary/hex: Start with Project 1 to master conversion algorithms. If you are a systems learner: Start with Project 3 and Project 5 to internalize bitwise logic and byte order. If you want forensics skills: Focus on Projects 8 and 9 for file identification and byte inspection.

Final Overall Project: Binary Forensics Toolkit

The Goal: Combine Projects 1, 6, 8, and 9 into a single toolkit that can convert values, inspect text encodings, identify file signatures, and render hexdumps.

Integrate a base converter into the hexdump UI.
Add encoding detection and ASCII/UTF-8 visualization.
Support signature matching with a rule file.

Success Criteria: Given an unknown file, the toolkit outputs a hexdump, decodes any text fields, and identifies the file type using magic rules.

From Learning to Production: What Is Next

Your Project	Production Equivalent	Gap to Fill
Project 1	`bc`, `python`, language REPLs	Big-number support, UX polish
Project 8	`file` command	Full magic database compatibility citeturn2search0
Project 9	`xxd`, `hexdump`	Performance, large-file streaming citeturn3search1

Summary

This learning path covers binary and hexadecimal through 12 hands-on projects.

#	Project Name	Main Language	Difficulty	Time Estimate
1	Universal Base Converter	C/Python	Level 1	4-8 hrs
2	Hex Color Visualizer	JS/Python	Level 1	4-8 hrs
3	Bitwise Logic Calculator	C	Level 2	6-10 hrs
4	Two’s-Complement Explorer	C/Python	Level 2	8-12 hrs
5	Endianness Inspector	C	Level 2	8-12 hrs
6	ASCII/UTF-8 Inspector	C/Python	Level 2	8-12 hrs
7	Flag Decoder	C	Level 2	6-10 hrs
8	File Signature Identifier	C	Level 3	10-20 hrs
9	Hexdump Clone	C	Level 3	15-25 hrs
10	Binary Diff & Patch	C/Python	Level 3	15-25 hrs
11	BMP Header Decoder	C	Level 3	12-20 hrs
12	Bitfield Packing Lab	C	Level 3	12-20 hrs

Expected Outcomes

Convert between decimal, binary, and hex confidently
Read and interpret byte-level data with hexdumps
Parse file headers and detect signatures reliably

Additional Resources and References

Standards and Specifications

RFC 20 (ASCII) citeturn2search7
RFC 3629 (UTF-8) citeturn1search2
CSS Color Module Level 4 (hex notation) citeturn0search3

Industry Analysis

UTF-8 usage statistics (W3Techs, 2025-12-28) citeturn0search0

Books

“Computer Systems: A Programmer’s Perspective” - data representation focus
“Code” by Charles Petzold - number system intuition