---
# System prepended metadata

title: 1. Understanding Magic Numbers of Files

---

# 1. Understanding Magic Numbers of Files

When I started exploring **FORENSICS** (specifically steganography), I worked on simple challenges where the flag might be hidden in an image. However, the image could have been altered or had its characteristic hex segments (magic numbers) removed, making it impossible to view. At that time, I only understood that fixing or restoring these segments would allow the file to be opened. This first task gave me the opportunity to deeply understand the nature of **magic numbers** in files.

**Concept**: **Magic numbers** are a sequence of bytes at the beginning of a file that identify its format, acting like a signature. They help software recognize and classify files based on their content, much like a key fitting a lock.

On Windows, I often use the **HxD** software to identify magic numbers:

![image](https://hackmd.io/_uploads/r1ZDEcpC0.png)

In Kali Linux, I typically use these two commands to determine a file's magic number:

![image](https://hackmd.io/_uploads/HyBMUqa0A.png)

Understanding magic numbers is highly beneficial for solving challenges and quickly identifying files. Specifically, it allows me to:
- Recognize the file type.
- Recover file data.
- Detect malicious code disguised as another file type (e.g., an `.exe` file modified to appear as a `.png`).

Here are some common magic numbers I encounter in challenges:

| File | Magic Number                        |
| ---- | ----------------------------------- |
| PNG  | 89 50 4E 47 0D 0A 1A 0A             |
| JPG  | FF D8 FF E0                         |
| BMP  | 42 4D                               |
| PDF  | 25 50 44 46 2D                      |
| ZIP  | 50 4B 03 04                         |
| MP3  | FF FB / FF F3 / FF F2               |
| WAV  | 52 49 46 46 ?? ?? ?? ?? 57 41 56 45 |
| MP4  | 66 74 79 70 69 73 6F 6D             |

Magic numbers are a critical concept, especially for those studying forensics. They are essential for identifying file formats, distinguishing file types, and performing file analysis.

> References:
> https://vi.wikipedia.org/wiki/%C4%90%E1%BB%8Bnh_d%E1%BA%A1ng_t%E1%BA%ADp_tin#:~:text=%E1%BB%9E%20%C4%91%C3%A2y%2C%20s%E1%BB%91%20ma%20thu%E1%BA%ADt%20l%C3%A0%20v%C4%83n%20b%E1%BA%A3n,s%E1%BA%BD%20%C4%91%C6%B0%E1%BB%A3c%20chuy%E1%BB%83n%20cho%20tr%C3%ACnh%20th%C3%B4ng%20d%E1%BB%8Bch%20l%E1%BB%87nh.
> https://en.wikipedia.org/wiki/List_of_file_signatures
> https://medium.com/@shailendrapurohit2010/beneath-the-bytes-a-deep-dive-into-magic-numbers-for-file-identification-4bff213121c4#:~:text=In%20computer%20programming%2C%20a%20magic%20number%20is%20a,also%20sometimes%20referred%20to%20as%20a%20file%20signature.

---

# 2. Reviewing LEARN FORENSIC DAY 1 to 9 and Summarizing PNG File Structure

## 2.1. Reviewing LEARN FORENSIC DAY 1 to 9 [here](https://birdcomesfirst.wordpress.com/author/khiemgamo123/)

---

### DAY 1

---

#### 1. FORENSICS

1. **What is Digital Forensics?** (done)
2. **Objectives of Forensics** (done)
3. **Why is Forensics Necessary?** (done)
4. **Locard's Exchange Principle** (done)
5. **Characteristics of Digital Forensics** (done)
6. **What Does Forensics Involve?** (done)
7. **Who Performs Forensics?** (done)
8. **Forensics in CTF**:
   - **A. Overview of Forensics in CTF**:
   - **B. Types of Forensics in CTF**:
     - **File Format Analysis**: Analyzing file formats.
     - **Steganography**: Analyzing and decoding messages hidden in images, audio files, text, or character sequences.
     - **Memory Dump Analysis**: Collecting, analyzing, and decoding data typically dumped from RAM.
     - **Network Packet Capture Analysis**: Collecting, analyzing, and decoding packets transmitted between endpoints.
   - **C. Required Skills**:
     - Proficiency in a scripting language, such as Python. (I’m still weak in this area, but I’ll keep practicing!)
     - Ability to manipulate binary data or byte-level data using that language.
     - Capability to identify formats, protocols, structures, and encodings.

#### 2. STEGO

1. **What is Steganography (Stego)?** (done)
2. **Applications of Stego** (done)
3. **Common Stego Methods**:
   - **A. LSB (Least Significant Bit) Method**:
     In image processing, each pixel is generally stored as 8-bit or 24-bit data. For 24-bit representation, each pixel spans three bytes, corresponding to red, green, and blue (RGB) colors. Colors are combinations of these three components, with each byte ranging from 0 to 255, representing color intensity (0 for darkest, 255 for brightest).

     ![image](https://hackmd.io/_uploads/B1SNnmg1kg.png)

     There are many methods to hide information in digital images, but the most common is embedding data in the **Least Significant Bit (LSB)**.

     > Least Significant Bits – LSB

     **Example**:
     ![image](https://hackmd.io/_uploads/Bkl7amx11e.png)

     Since each pixel consists of three color channels (RGB), up to 3 bits of a secret message can be hidden per pixel.

     > **Steps to hide a message in an image using LSB**:
     > - Convert the message to binary.
     > - Replace the LSB of consecutive pixels with 3 bits of the message until the entire message is embedded.
     > - Save the new image containing the hidden message.

     LSB can also be applied to other file types, such as audio. In audio stego, LSB is used to slightly modify pitch or echo bits to hide data. This is also known as **Audio Stego**, a variant of LSB.

   - **B. Palette-Based Technique**:
     > Read more [here](https://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and-images/stretch-function.htm#:~:text=Stretching%20improves%20the%20appearance%20of,results%20in%20the%20raster%20display) and [here](https://link.springer.com/chapter/10.1007/978-3-642-18440-6_46).

   - **C. Secure Cover Selection (SCS)**:

---

### Day 2

---

#### 1. Structure of an Image File

Every image file must include the following information:
- **Size**: The width and height of the image, measured in pixels.
- **Pixel Format and Color Pixel Information**: Pixel Format (pix fmt) describes how pixels are arranged in the image or video data.

> Pixel Format typically relates to the color channel or color space of visual data. It indicates how color data is encoded and organized. Common parameters of Pixel Format include bits per pixel (bpp) and the color model.

##### A. Common Color Models/Color Spaces
- RGB
- YCbCr
- YUV
- CYM/CYMK

##### B. Color Channel
A digital color image is composed of multiple pixels, each formed by combining basic colors represented as code sequences. A **channel** is a grayscale image of the same size as the color image, derived from one of the basic colors. For example, a digital camera image has three channels: red, green, and blue. A grayscale image has only one channel. The red channel is based on red intensity converted to grayscale, and the green and blue channels are similar.

I often use **StegOnline** to check channels.

##### C. Bits Per Pixel (BPP)
BPP represents the number of bits of data per pixel. The number of distinct colors in an image depends on the color depth or BPP.

![image](https://hackmd.io/_uploads/ryw6YBxJJg.png)

Image size can be calculated using BPP with the formula:
`Image size = rows * columns * BPP`

##### D. Common Image File Formats (File Extensions)
- **JPEG/JPG**: A popular image format introduced in 1992, using lossy compression to reduce file size at the cost of quality. Suitable for complex images, RGB, static images, and portraits.
- **PNG**: A lossless compression format introduced in 1996, widely used on the web, supporting transparent colors. Ideal for logos, simple images, and complex images when size is not a concern.
- **GIF**: A lossless compression format introduced in 1987, limited to 256 colors, suitable for simple images, animations, web icons, and illustrations with few colors.
- **TIFF**: A high-quality format introduced in 1986, retaining quality whether compressed or not, commonly used for printing and high-quality digital images.

##### E. File Signature and CTF
This is the same as the **magic number** I studied in the first part of the task!

---

### Day 3

---

**PNG**: A file extension format using lossless compression. PNG was designed as a replacement for GIF and can even replace TIFF in some tasks. It is optimized for online viewing, a robust format that provides both error checking and detection for common transmission issues.

#### I. Data Representation

1. **Integers and Byte Order**

   - **LSB and MSB**:
     - **LSB (Least Significant Bytes)**: Bytes with the least weight; changing their value has minimal impact on the overall data.
     - **MSB (Most Significant Bytes)**: More significant bytes; changing their value causes significant changes, such as noticeable color shifts.

   - **Byte Order**:
     The order in which bytes are arranged during data transmission. **Network Byte Order (Big Endian)** arranges bytes from most significant to least significant, ensuring consistency in network data transmission.

   - **Two’s Complement Notation**:
     A method for representing signed numbers in binary, used to calculate the complement of a binary number by inverting bits and adding 1.

   - **Network Byte Order in PNG**:
     PNG uses Network Byte Order for compatibility with most platforms supporting TCP/IP, ensuring high compatibility in digital environments.

2. **Integers, Byte Order, and CTF**

   - **A. Introduction**
   - **B. Required Skills**
   - **C. Manipulating Binary Data with Python**

     1. **Struct Module**
        Sometimes, you need to use Python to handle binary data for tasks like accessing files or operating sockets. The **Python Struct Module** is essential for this.

        
        
        
        
        
        
        
        
        
        
        

        The three most important functions for CTF in the Struct Module are:
        - **pack()**: Packs data into a byte string.
          ![image](https://hackmd.io/_uploads/r1IL_Ax1Jx.png)
          ```python
          import struct

          packed = struct.pack('i 4s f', 10, b'John', 2500)
          print(packed)
          ```
          > The first argument is the format string, specifying the layout for packing or unpacking data. The remaining arguments represent the data to be packed.

          Here is a table of characters representing common formats in the first argument:
          ![image](https://hackmd.io/_uploads/SyLfYRx1ye.png)

        - **unpack()**: Unpacks a byte string into its original data.
          ![image](https://hackmd.io/_uploads/HkZ4K0gyJx.png)
          ```python
          import struct

          packed = b'\n\x00\x00\x00John\x00@\x1cE'
          unpacked = struct.unpack('i 4s f', packed)
          print(unpacked)
          ```

        - **calcsize()**: Calculates the size of a byte string.
          ![image](https://hackmd.io/_uploads/rk1CK0e1Je.png)
          ```python
          import struct

          size = struct.calcsize('i 4s f')
          print("Size in bytes: {}".format(size))
          ```

---

### Day 4

---

#### C. Manipulating Binary Data with Python

1. **Struct Module (Part 2)**

   The three functions `pack()`, `unpack()`, and `calcsize()` all use an argument called **fmt**, which guides how data is packed into a byte stream containing a series of format strings.

   ```python
   import struct
   struct.pack('>I', 16)

   '\x00\x00\x00\x10'
   ```

   Notice that the first argument of `pack()` is a processing instruction. `'>I'` means: `>` indicates Big-Endian (Network Byte Order), and `I` represents a 4-byte unsigned integer.

   The number of subsequent parameters must match the processing instruction.

   Using `struct.unpack()`:
   Unpacks a byte string into its original data format. For example, reading the first 30 bytes of a BMP file:

   ```python
   import struct
   bmp = '\x42\x4d\x38\x8c\x0a\x00\x00\x00\x00\x00\x36\x00\x00\x00\x28\x00\x00\x00\x80\x02\x00\x00\x68\x01\x00\x00\x01\x00\x18\x00'
   struct.unpack('<ccIIIIIIHH', bmp)
   ```

   Result:
   ```
   ('B', 'M', 691256, 0, 54, 40, 640, 360, 1, 24)
   ```

   This decodes the first 30 bytes of a BMP file, corresponding to:
   ```
   'B', 'M': First 2 bytes, indicating a Windows bitmap (or 'BA' for OS/2 bitmap).
   691256: Bitmap size.
   0: Reserved bits, always 0.
   54: Image data offset.
   40: Number of bytes in the header.
   640: Image width.
   360: Image height.
   1: Always 1.
   24: Number of colors.
   ```

2. **Bytearray**

   To read a file into a binary array, use:
   ```python
   data = bytearray(open('chall.png', 'rb').read())
   ```

   After reading, you can access array elements like a regular array:
   ```python
   data[0] = '\x89'
   ```

   A **Byte Array** is a mutable version of bytes.

#### D. Common Tools and Commands (done)

---

### Day 5

---

#### 3. File Structure

The structure of a PNG file consists of a **PNG signature** at the beginning, followed by a series of **chunks**.

![image](https://hackmd.io/_uploads/SyCWJyZJkg.png)

> A **chunk** is a fragment of information commonly used in multimedia file formats like PNG, IFF, MP3, AVI, etc. In computing, a chunk is a set of data sent to a processor or computer component for processing.

1. **PNG File Signature**:
   The first 8 bytes of a PNG file always contain the following values:

   |  |  |
   | -------- | -------- |
   | HEX      | 89 50 4E 47 0D 0A 1A 0A |
   | DEC      | 137 80 78 71 13 10 26 10 |
   | ASCII    | \211 P N G \r \n \032 \n |

   **Signature**: This part, called the "signature," indicates that the file is a PNG image and helps quickly identify transmission issues. For example, if the signature is missing or incorrect, the file may be misidentified or encounter errors during transmission.

2. **Details of Each Signature Byte**:
   - **Byte 1 (89 or 137)**: A non-ASCII value to distinguish PNG files from text files and reduce misidentification if the 7th bit is lost.
   - **Bytes 2-4 (50 4E 47 or P N G)**: Indicate the file format as PNG.
   - **Bytes 5-6 (0D 0A or \r \n)**: Used to detect file transfer errors, ensuring accurate file reading.
   - **Byte 7 (1A or \032)**: The "ctrl-Z" character, used to stop file display on MS-DOS.
   - **Byte 8 (0A or \n)**: A newline character to verify transmission accuracy.

3. **Chunk Structure**:
   A PNG file is divided into multiple **chunks** (data blocks), with the two most important being:
   - **IHDR**: The first chunk, containing critical information like width, height, and other image parameters.
   - **IEND**: The last chunk, marking the end of the file.

   Each chunk consists of four parts:
   - **Length**: A 4-byte unsigned integer indicating the length of the chunk data (excluding Length and CRC).
   - **Chunk Type**: A 4-byte code identifying the chunk type, using ASCII characters (uppercase or lowercase).
   - **Chunk Data**: The actual data of the chunk, which may be empty.
   - **CRC (Cyclic Redundancy Check)**: A 4-byte checksum to detect errors in the chunk, ensuring data integrity.

4. **Significance of Signature and Chunk Layout**:
   - The signature identifies the file as PNG and quickly detects transmission errors.
   - The chunk layout allows software (decoders) to skip unimportant or unrecognized chunks, ensuring flexibility and safety in PNG processing.

5. **Chunk Naming Conventions**:
   Chunk names must follow naming conventions so decoders can determine basic properties even if the chunk is unrecognized. Each character in the chunk name has a specific meaning based on whether it is uppercase or lowercase.

   - **A. Ancillary Bit**:
     - 0 (uppercase): Critical chunk; cannot be ignored if unrecognized.
     - 1 (lowercase): Ancillary chunk; can be ignored if unrecognized.
   - **B. Private Bit**:
     - 0 (uppercase): Public chunk, part of the PNG standard or registered.
     - 1 (lowercase): Private chunk, used for specific purposes.
   - **C. Reserved Bit**:
     - Always 0 (uppercase): Currently unused but reserved for future updates.
   - **D. Safe-to-Copy Bit**:
     - 0 (uppercase): Unsafe to copy if the file is modified.
     - 1 (lowercase): Safe to copy regardless of file modifications.

---

### Day 6

---

#### I. Chunk Specifications

1. **Critical Chunks**

   ![image](https://hackmd.io/_uploads/rJXEOeZy1l.png)

   A valid PNG image must contain:
   ```
   One IHDR chunk
   One or more IDAT chunks
   One IEND chunk
   ```

   **A. IHDR Image Header**:
   The IHDR chunk must appear first. Its structure includes:

   ```
   Width: 4 bytes
   - Image width in pixels.
   - Cannot be 0.
   - Maximum value: 2^31-1
   ```

   ```
   Height: 4 bytes
   - Image height in pixels.
   - Cannot be 0.
   - Maximum value: 2^31-1
   ```

   ```
   Bit Depth: 1 byte
   - Number of bits per sample or palette index, not per pixel.
   - Common values: 1, 2, 4, 8, and 16.
   - Higher bit depth allows more colors to be stored.
   ```

   ```
   Color Type: 1 byte
   - Specifies how image data is interpreted.
   - Values: 0 (grayscale), 2 (truecolor), 3 (indexed color), 4 (grayscale with alpha), 6 (truecolor with alpha).
   - Color Type is the sum of: 1 (palette), 2 (color), 4 (alpha channel).
   ```

   ```
   Compression Method: 1 byte
   - Indicates the image data compression method.
   - Currently, only 0 (deflate/inflate).
   - Decoders must check this byte and report an error if the code is unrecognized.
   ```

   ```
   Filter Method: 1 byte
   - Indicates the preprocessing method before compression.
   - Currently, only 0 (adaptive filtering).
   - Decoders must check this byte and report an error if the code is unrecognized.
   ```

   ```
   Interlace Method: 1 byte
   - Specifies the transmission order of image data.
   - Values: 0 (non-interlaced) or 1 (Adam7 interlacing).
   ```

   **B. Interlaced Data Order**:
   Interlacing in PNG allows images to display progressively (fade-in effect) during loading, enabling viewers to recognize content before the image is fully loaded. While this slightly increases file size, it is useful for slow connections.

   Two methods:
   - **Method 0 (Non-interlaced)**: Pixels are stored sequentially from left to right, top to bottom.
   - **Method 1 (Adam7)**: Consists of 7 different scans in an 8x8 pattern, starting from the top-left corner. Decoders must support interlaced images.

---

### Day 7

---

#### I. Chunk Specifications

**A. PLTE Palette**:
The PLTE chunk contains 1 to 256 palette entries, each a 3-byte series in the format:

- Red: 1 byte (0 = black, 255 = red)
- Green: 1 byte (0 = black, 255 = green)
- Blue: 1 byte (0 = black, 255 = blue)

![image](https://hackmd.io/_uploads/BkCu4i-yJe.png)

> The number of entries is calculated from the chunk length. If the chunk length is not divisible by 3, it results in an error.

The PLTE chunk is mandatory for color type 3 (indexed color), optional for color types 2 and 6, and must not appear for types 0 and 4. If present, it must appear before the first IDAT chunk. Only one PLTE chunk is allowed.

![image](https://hackmd.io/_uploads/HJeC4jby1e.png)

> The highlighted data is the PLTE chunk. The first IDAT chunk is visible below.

For color type 3 (indexed color), the PLTE chunk is required. The first PLTE entry is referenced by pixel value 0, the second by pixel value 1, and so on. The number of entries may be fewer but cannot exceed the range representable by the image’s bit depth.

Excess entries are an error.

For color types 2 and 6 (truecolor and truecolor+alpha), the PLTE chunk is optional. If present, it provides a suggested set of 1 to 256 colors for quantizing truecolor images if the viewer cannot display truecolor directly.

![image](https://hackmd.io/_uploads/By8UHob1ke.png)

> Type 2 is like the left image; type 6 combines both.

If no palette is provided, the viewer must select colors itself. It’s recommended that the encoder selects the palette once.

Note that the palette uses 8 bits (1 byte) per sample, regardless of the image’s bit depth. Specifically, the palette has an 8-bit depth even for a suggested quantization table of a 16-bit color image.

Not all entries need to be used, nor must they be distinct.

**B. IDAT Image Data**:
> The IDAT chunk contains the actual image data. To create this data:

1. Use scanlines as described in the image layout (e.g., a 4×4 pixel image has 4 scanlines, each with 4 pixels from left to right, arranged top to bottom). The layout and total size of this raw data are determined by the IHDR fields.

![image](https://hackmd.io/_uploads/ByACSj-k1e.png)

> Each black/white line is a scanline.

2. Filter the image data based on the filtering method specified in the IHDR chunk. For filter method 0 (the only defined method), a filter-type byte is implicitly added to each scanline.

![image](https://hackmd.io/_uploads/ryEW8sZ1Je.png)

3. Compress the filtered data using the compression method specified in the IHDR chunk.

![image](https://hackmd.io/_uploads/Sy6XIj-11x.png)

> The IDAT chunk contains the output datastream from the compression algorithm.

Multiple IDAT chunks may exist in an image. If so, they must appear consecutively without interruption by other chunks. Concatenating the contents of these IDAT chunks yields the compressed data stream. Encoders can split the compressed data into IDAT chunks as desired, often matching the encoder’s buffer size.

**C. IEND Image Trailer**:
The IEND chunk must appear last, marking the end of the PNG data stream. Its data field is empty.

---

### Day 8

---

#### I. Chunk Specifications

1. **Ancillary Chunks**:
All ancillary chunks are optional, meaning encoders are not required to include them, and decoders may ignore them. However, encoders are encouraged to include standard ancillary chunks when data is available, and decoders should interpret them when appropriate and feasible.

**A. Transparency Information**:
> This chunk conveys transparency information in data streams without a full alpha channel.

The **tRNS** chunk provides transparency information for PNG images without a full alpha channel, supporting "simple transparency" to create transparent regions.

Use cases for tRNS:
- **Color Type 3 (Indexed Color)**:
  - tRNS contains a sequence of alpha values (1 byte each) corresponding to palette entries.
  - Example: Alpha values for palette indices 0, 1, etc., specify transparency/opacity for each color.
  - 0 = fully transparent, 255 = fully opaque.
  - If insufficient alpha values are provided, remaining entries default to 255 (fully opaque).
- **Color Type 0 (Grayscale)**:
  - tRNS contains a single gray value, specifying that pixels with this gray level are transparent.
  - Example: Pixels with the specified gray level have alpha 0 (transparent); others are 255 (opaque).
- **Color Type 2 (True Color)**:
  - tRNS contains a single RGB value, specifying a color that is transparent.
  - Pixels with that color have alpha 0; others are 255 (opaque).

**Note**:
- tRNS does not apply to color types 4 and 6, which already have a full alpha channel.
- For 16-bit images, both bytes of each sample must be compared to determine transparency accurately.

**B. Color Space Information**:
> These chunks relate image samples to the desired display intensity.

1. **gAMA (Image Gamma)**:
   - Gamma represents the transition from black to white on a display.
   - Formula: `sample = light_out ^ gamma`, where `light_out` is the output light intensity.
   - The gamma value is stored as a 4-byte unsigned integer, representing gamma multiplied by 100,000.
   - Example: Gamma 1/2.2 (~0.45455) is stored as 45455.
   - gAMA does not affect transparency (alpha).
   - If the gamma value is unknown, gAMA is not needed.
   - gAMA appears before IDAT and PLTE (if present) but is overridden by sRGB or iCCP chunks.

2. **cHRM (Primary Chromaticities)**:
   - Defines the chromaticities of primary colors (red, green, blue) and the white point.
   - Values are stored as 4-byte unsigned integers, multiplied by 100,000.
   - Example: 0.3127 is stored as 31270.
   - cHRM is unnecessary if chromaticities are unknown.
   - Appears before IDAT and PLTE, overridden by sRGB or iCCP chunks.

3. **sRGB (Standard RGB Color Space)**:
   - Specifies that the image follows the sRGB color space, ensuring correct color display.
   - Contains 1 byte for rendering intent (how the image is displayed):
     - 0: Perceptual – Optimizes color during conversion.
     - 1: Relative colorimetric – Maintains colors relative to the white point.
     - 2: Saturation – Preserves saturation.
     - 3: Absolute colorimetric – Maintains exact colors.
   - When sRGB is present, applications ignore gAMA and cHRM, as sRGB provides this information.
   - Must appear before IDAT and PLTE and cannot coexist with iCCP.

4. **iCCP (Embedded ICC Profile)**:
   - Contains an ICC profile to define the image’s color space.
   - The ICC profile must be RGB for color images or grayscale for grayscale images.
   - Includes a profile name and ICC data compressed using the deflate method (decompressed with zlib).
   - When iCCP is present, applications ignore gAMA and cHRM.
   - Appears only once, before IDAT and PLTE (if present).

These chunks manage brightness and color in PNGs to ensure accurate display across devices.

---

### Day 9

---

1. **Textual Information**:
   - **Text Chunks (iTXt, tEXt, zTXt)**: Used to store text information in PNG images.
   - Each chunk contains a **keyword** describing the content, such as "title" or "author."
   - Keywords can be registered or custom but must follow naming rules (max 79 characters, case-sensitive, no leading/trailing spaces).

2. **Processing Text Chunks**:
   - **tEXt**: Stores uncompressed text using Latin-1 encoding. Suitable for short text.
   - **zTXt**: Like tEXt but compresses text, suitable for longer text.
   - **iTXt**: Stores international text using UTF-8 encoding, optionally compressed. Supports multiple languages.

3. **Ordering Rules**:
   - Small text chunks like "title" should be placed before IDAT for faster display.
   - Larger text chunks should be placed after IDAT for better performance.

4. **Specific Content of Each Chunk**:
   - **tEXt**: Stores uncompressed text with a keyword and text string separated by a null byte (0).
   - **zTXt**: Like tEXt, but the text data is compressed using zlib.
   - **iTXt**: Like tEXt, but supports international languages with UTF-8 encoding. Text may be compressed based on a flag.

---

## 2.2. Summary of PNG File Structure

---

> **Definition**: PNG (Portable Network Graphics) is a popular file format for transmitting static images. It is widely used on the web and in various documentation systems, offering excellent lossless compression.

![image](https://hackmd.io/_uploads/Sy3bis-11g.png)

1. **PNG Signature**:
   ```
   The first 8 bytes identifying a PNG file: 89 50 4E 47 0D 0A 1A 0A.
   - 89: Detects errors during transmission on systems not supporting 8-bit data.
   - 50 4E 47: Corresponds to ASCII "PNG".
   - 0D 0A: CRLF (Carriage Return Line Feed) newline characters.
   - 1A: Prevents displaying the PNG file as text.
   - 0A: LF (Line Feed) newline character.
   ```

2. **Chunk Structure**:
   ```
   Each chunk in a PNG file has the following structure:
   - 4-byte Length: Length of the chunk data.
   - 4-byte Chunk Type: Chunk type, consisting of 4 ASCII characters (e.g., IHDR, IDAT, IEND).
   - Data: Actual chunk data, with length equal to Length.
   - 4-byte CRC: CRC32 checksum to detect errors in Chunk Type and Data.
   ```

3. **IHDR (Image Header)**:
   ```
   The first chunk in a PNG file.
   - Length: 13 bytes.
   - Data Structure:
     - 4-byte Width: Image width in pixels.
     - 4-byte Height: Image height in pixels.
     - 1-byte Bit Depth: Bits per color channel (e.g., 8-bit, 16-bit).
     - 1-byte Color Type:
       - 0: Grayscale.
       - 2: Truecolor (RGB).
       - 3: Indexed-color (uses palette).
       - 4: Grayscale with alpha.
       - 6: Truecolor with alpha.
     - 1-byte Compression Method: Always 0 (deflate/inflate).
     - 1-byte Filter Method: Always 0.
     - 1-byte Interlace Method:
       - 0: Non-interlaced.
       - 1: Adam7 interlacing.
   ```

4. **PLTE (Palette)**:
   ```
   Contains the image’s color palette for color type 3 (indexed-color).
   - Each palette entry is 3 bytes (RGB).
   - Chunk length must be a multiple of 3 and not exceed 2^bit_depth entries.
   ```

5. **IDAT (Image Data)**:
   ```
   Contains compressed image data using the deflate algorithm.
   - Multiple IDAT chunks may exist; their data is concatenated before decompression.
   - Decompressed data is filtered to reconstruct pixel scanlines.
   ```

6. **IEND (Image End)**:
   ```
   Contains no data (Length = 0).
   - Marks the end of the PNG file.
   ```

7. **Other Ancillary Chunks**:
   ```
   - tEXt, zTXt, iTXt: Store text information.
     - tEXt: Uncompressed text.
     - zTXt: Compressed text.
     - iTXt: Optionally compressed text, supports multiple languages.
   - gAMA: Stores the image’s gamma value for brightness adjustment.
   - cHRM: Defines primary color values.
   - sRGB: Specifies the sRGB color space.
   ```

8. **Interlace Method (Adam7)**:
   ```
   Adam7 interlacing divides the image into 7 scans, allowing progressive display during loading.
   - Scan 1: 1/8 of pixels.
   - Scan 2: Another 1/8 of the image.
   - Continues until Scan 7, completing the remaining pixels.
   This method allows users to see a blurry version of the image while it loads, instead of waiting for the entire image.
   ```

---

# 3. Understanding LSB and RGB

## 3.1. LSB

---

> **LSB (Least Significant Bit)**: The bit with the smallest value in a binary number. For a byte (8 bits), the LSB is the rightmost bit.

![encode](https://hackmd.io/_uploads/Hybn1LGyyl.png)

**Applications**:
- In **steganography**: LSB is widely used to hide data in images, audio, or video files. By altering the LSB of each pixel or audio sample, data can be embedded without noticeable changes to the human eye or ear.

![Screenshot 2024-06-03 231835](https://hackmd.io/_uploads/Ske1_CMJkl.png)

**Example**: Changing the LSB of a byte representing a color in an image (e.g., from 0 to 1) results in a negligible color change.

- In **cryptography**: LSB is used in algorithms requiring integer or binary data manipulation.

```
Example:
Binary number 1101 1010:
- LSB is 0.
- To hide a 1 using LSB:
  - Original byte: 1101 1010.
  - Modified byte: 1101 1011.
```

Since each pixel consists of three color channels (RGB), up to 3 bits of a secret message can be hidden per pixel.

**Steps to hide a message in an image using LSB**:
- Convert the message to binary.
- Replace the LSB of consecutive pixels with 3 bits of the message until the entire message is embedded.
- Save the new image with the hidden message.

LSB can also be applied to other file types, such as audio. In audio stego, LSB slightly modifies pitch or echo bits to hide data, also known as **Audio Stego**, a variant of LSB.

---

## 3.2. RGB

---

The **RGB color model** uses an additive model where red, green, and blue light are combined in various ways to produce different colors.

> Note that the RGB model itself does not precisely define "red," "green," or "blue." Thus, the same RGB values may represent slightly different colors on different devices with the same color model. While they share a common color model, their actual color spaces vary significantly.

![image](https://hackmd.io/_uploads/rJC3VwG1yl.png)

**Structure of an RGB Pixel**:
- Each pixel in an RGB image is represented by three color channels: **Red**, **Green**, and **Blue**.
- Each channel is represented by 8 bits, allowing 256 intensity levels from 0 to 255.
- Combining three 8-bit channels, each pixel in an RGB image can be represented by 24 bits (8 bits per channel).

**How RGB Works**:
- Each color component is represented by a value from 0 to 255 (8 bits, 1 byte). Combining these components creates a unique color.

```
Examples:
- (255, 0, 0): Red (maximum red, no green or blue).
- (0, 255, 0): Green.
- (0, 0, 255): Blue.
- (255, 255, 255): White (maximum of all three).
- (0, 0, 0): Black (none of the three).
```

Each pixel can represent 256 × 256 × 256 = 16,777,216 different colors, as each component has 256 values.

**Storage and Processing in RGB**:
- RGB images are typically stored as bitmaps, where each pixel contains three color values for red, green, and blue.
- **Data size**: Each pixel in a 24-bit RGB image occupies 3 bytes (1 byte per channel). For a 1000 × 1000 pixel image:
  - 1000 × 1000 × 3 bytes = 3,000,000 bytes ≈ 3 MB.
- Formats like PNG, JPEG, and BMP store images in RGB. PNG preserves RGB image quality, while JPEG compresses images, potentially losing some color quality.

**RGB in Steganography**:
RGB plays a crucial role in hiding data within image color channels.
- **LSB Technique**:
  - Data is hidden by altering the least significant bit of the red, green, or blue channel values.
  - Each channel’s LSB can be modified with minimal visual impact, allowing data to be embedded without significantly altering pixel colors.

```
Example, with a pixel (100, 150, 200):
- Bit to hide: 1.
- After hiding in the Blue channel: (100, 150, 201) (Blue channel increased by 1 in LSB).
```

|  | LSB (Least Significant Bit) | RGB (Red, Green, Blue) |
| -------- | -------- | -------- |
| **Definition** | A technique for hiding data by altering the least significant bit in data values. | RGB is a color model using three primary colors (Red, Green, Blue) to represent colors. |
| **Position** | The rightmost (lowest) bit in a binary number. | RGB represents three color channels in each image pixel. |
| **Primary Role** | Used in bit operations and data hiding, often embedding data in images with minimal quality impact. | Defines the color of each pixel in an image. |
| **Steganography Application** | Commonly used to hide data by altering the LSB of color values in RGB channels, embedding data in images. | RGB images are the foundation for hiding data by modifying channel values. |
| **Example** | Binary 1101 1010, LSB is 0. Changing LSB to hide 1 results in 1101 1011. | A pixel with RGB (255, 0, 0) is red. Changing the LSB of red may result in (254, 0, 0). |
| **Impact of Change** | Changing the LSB has minimal impact on the overall value or pixel color, making changes hard to detect. | Changing RGB values affects pixel color, but LSB changes are typically imperceptible. |
| **Bitwise Operations** | Used in operations like AND, OR, XOR to control or modify bit values. | RGB is not directly related to bitwise operations but can be manipulated via channel values. |
| **Compression and Image Encoding** | Used in image compression to maintain integrity by altering LSBs. | RGB is the basis for color encoding in formats like PNG, JPEG, where compression may alter RGB values. |
| **Security and Data Hiding** | LSB changes are hard to detect visually but may be found through statistical analysis. | Using RGB channels for data hiding distributes information across channels, making detection harder. |
| **Data Storage Capacity** | Limited storage if only using LSB (typically 1 bit per byte). | Higher storage capacity when combined with LSB, hiding data in all three RGB channels per pixel. |