> ## Content Index > Fetch the complete content index at: https://niklas-heringer.com/llms.txt > Use this file to discover other available public pages before exploring further. # Digital Forensics Challenge: Basics, Mounting & Analyzing Disk Images (Day 1) - URL: https://niklas-heringer.com/digital-forensics/forensics-challenge-day-one/ - Published: 2025-06-11T12:18:00.000Z - Updated: 2025-11-14T21:15:10.000Z - Description: In this introductory forensics lab, we explore how to mount and examine disk images using loop devices, losetup, SleuthKit tools, and file system inspection techniques. A hands-on walkthrough for raw, split, and forensic image formats like AFF and EWF. - Author: Niklas Heringer - Tags: forensics-challenge, loopback-analysis, losetup, mounting-images, sleuthkit, aff, ewf, filesystem-analysis, disk-image, linux-forensics, forensics-lab, #digital-forensics, digital-forensics **Hello folks**, welcome to a new challenge of mine! I have been, admittedly, quite lazy with digital forensics itself. I've spent a lot of time on my [Forensic Log Tracker](https://github.com/mev0lent/forensic-log-tracker?ref=niklas-heringer.com) and other details of forensics, like file systems, but my actual uni course, which is mostly about computer forensics.. meh, i've been rather idle. > Today marks the first day of my Forensics Challenge, where i'll work through [Digital Forensics with Open Source Tools](https://elhacker.info/manuales/An%C3%A1lisis%20forense/Digital%20Forensics%20With%20Open%20Source%20Tools%20%282011?ref=niklas-heringer.com).pdf) by Cory Altheide and Harlan Carvey, to make amends and get up to speed in my prep for the course exam. **Are you ready?** # Chapter 1: Not so interesting for us, but definitely worth a read Chapter 1 proved very interesting to discover more about terminology, processes in criminal forensics, and especially about Open Source culture, which i'm a great fan of. > We'll skip it's content here, but feel free to give it a read, i'm sure most of you can take something out of it for themselves! # Chapter 2: Open Source Examination Platform ## Preparing our Lab Most of the open source tools discussed in this book come in source form, so often times, we'll need to **generate the executable software code** by ourselves. Also, some tools might require a specific interpreter to run. This section will **take good care** of that. We'll - Build Software (converting source code into usable form) - Installing Interpreters (source applications written in **interpreted** or **scripting** languages like Perl, Python or Ruby require prerequisites that these applications rely on.) - Introduce ourselves to working with Image Files aswell as **File Systems** In this series, we'll be using Kali Linux as the host, although the book also covers Windows, so you can choose freely! ## Extracting Software > Linux source code usually is distributed in compressed archives, or *tarballs* \- fittingly we will use the `tar` command and it's useful flags to extract. Use the `tar` command with the right flags depending on the compression type: **GZipped tarballs** (`.tar.gz` or `.tgz`): ```bash tar xzf filename.tar.gz ``` **BZipped tarballs** (`.tar.bz2`, `.tbz`, or `.tbz2`): ```bash tar xjf filename.tar.bz2 ``` > Add `-v` for verbose mode to see the files being extracted: ```bash tar xzvf filename.tar.gz ``` ## Preparing to Build From Source Before compiling or analyzing binaries from source, make sure your system has the necessary tools installed. On **Ubuntu or Debian-based systems**, install the essential build tools with: ```bash sudo apt-get update sudo apt-get install build-essential ``` This includes tools like `gcc`, `make`, and `libc` headers, all commonly required when working with source code. > **Tip:** Run `apt-get` commands with `sudo`, since package installation requires administrative privileges - **BUT ONLY** for known, trusted packages from official Ubuntu/Debian repositories. DON'T do `sudo apt-get install ./not-trustworthy-file.deb`. ## GNU Build System For most of the future software in use here we'll be preparing and executing builds using the [GNU Autotools](https://www.gnu.org/software/automake/manual/html%5Fnode/Autotools-Introduction.html?ref=niklas-heringer.com) system - a process generally involving three commands, in order: 1. `./configure` 2. `make` 3. `(sudo) make install` ### `configure` An included `configure` script will set in any configurable options that might exist. ```bash @:~/path/to/code$ ./configure --help ``` will enable you to view optional features, flags, to tune the options to your liking. > **Combine these option descriptions** with provided `README`'s to get to know more about dependencies and other important details. > E.g., what if, using this method, you found out your new software relied on openssl? Different Linux distributions will have libraries packaged under different namesn, but generally, you'll be able to locate them via searching for the development library name using: ```bash apt-cache search LIBRARY ``` This might again differ depending on your linux distribution, but for us now it's `apt-cache search openssl | grep dev` ```bash apt-cache search openssl | grep dev android-libboringssl-dev - Google's internal fork of OpenSSL for the Android SDK - devel apache2-ssl-dev - Apache HTTP Server (mod_ssl development headers) golang-github-mendersoftware-openssl-dev - OpenSSL bindings for Go. golang-github-youmark-pkcs8-dev - Go package to parse and convert private keys in PKCS#8 format (library) libbellesip-dev - SIP stack from the Linphone team (development files) libconduit-lwt-ocaml-dev - network connection establishment library for Lwt (dev) libconduit-ocaml-dev - network connection establishment library for OCaml (dev) libcurl4-openssl-dev - development files and documentation for libcurl (OpenSSL flavour) ... ``` Damn, that's a lot... --- # Sidequest: Finally learning `less` > **I've had enough** of my professor flexing off his amazing terminal skills, of which `less` has been a great part - the speed and efficiency of actions is always marvelous watching him. Let's take a minute to grasp it's basics here, as we need to search in the above results for a specific entry. I've used [this article](https://linuxize.com/post/less-command-in-linux/?ref=niklas-heringer.com). > Okay, so less can display contents of a file or command outputs one page at a time - it has more advanced features than `more`? **Ironic**. ## How to use `less` \- the Basics ```bash less [OPTIONS] filename ``` for files, or for commands: ```bash | less ``` ### Navigating with `less` - Going forward (next page): `f` or `Space bar` - Going back to previous page: `b` - Moving down `n` lines: `n f` or `n` `Space bar` - Moving up `n` lines: `n b` - Scroll forward one line: `Down arrow` or `enter` - Scroll backward one line: `Up arrow` - Quitting and going back to the command line: `q` When you're at the file's/ command output's end, the string `(END)` will show. ## Searching for a pattern with `less` To search for a pattern, type `/` followed by the (Regex) pattern you want to search. Hitting `Enter` will search **forward** for matches, Or change the `/` for a `?` to search **backwards**. ### Less Options ```bash less -N ``` will show **line numbers**. ```bash less -X ``` will prevent the contents from getting cleared once you exit `less`. ```bash less -X ``` tells `less` to watch for changes, good for e.g. working with **log files**. [See this very well-crafted post](https://linuxize.com/post/less-command-in-linux/?ref=niklas-heringer.com) for more commands. --- # Using `less` to search in config To apply what we've learned, let's continue our earlier example. ```bash apt-cache search openssl | grep dev | less ``` using the above commands came in very handy to comprehend the books search, discovering the `libssl-dev` and `zlib1g-dev` dependencies we then installed via `sudo apt-get install zlib1g-dev libssl-dev`. > This way, all is ready for the `./configure` to be run. Mind that simple programns without third-party dependencies might not have such a script, but maybe a prebuilt makefile. Check their `README`'s, maybe you'll also need to compile the code yourself. A successful execution of the `configure` script will generate a `makefile` \- this build script will be read by the `make` command. ### `make` Reading through the previously generated `makefile`, this command compiles and links each of the executable files and libraries making up the respective program. > This will take a lot of time and generate a lot of output. After completion, we go along with: ```bash sudo make install ``` That will copy the finished executables, libraries, docs, any materials and **move them to their configured locations** \- generally, under `/usr/local`. ## Other Build Systems than GNU Autotools GNU Autotools is the most commonly used build system, yet two of the most popular alternatives are [cmake](https://cmake.org/?ref=niklas-heringer.com) and [scons](https://scons.org/?ref=niklas-heringer.com). `Scons` is Python-based - a popular choice for software in.. well Python lol. `Cmake` is a really interesting one, it generates **native build files** for each target for it's cross-platform clients: Makefiles for Unix(ish) systems, Visual Studio Solution files for Windows targets, ... ## Interpreters As mentioned earlier, we'll need to be able to execute programs written in interpreted/ scripting languages. On Kali, all three, Ruby, Perl and Python are preinstaled, but if you want to [check out installation for them](https://elhacker.info/manuales/An%C3%A1lisis%20forense/Digital%20Forensics%20With%20Open%20Source%20Tools%20%282011?ref=niklas-heringer.com).pdf), feel free to do so. > **Now, the real fun begins.** We'll be getting into working with images and start out with the tools - let's gooo. ## Working with Images What if one of the following fancy tools *doesn't work as expected*? They could malfunction, possibly even **contaminating** our forensic material at hand. To give us some safety here, we need to be able to **work with image files natively** \- using "native system functionality", as the book calls it. ### Warning: Automounting of Volumes on Ubuntu 💡 One of the key reasons forensic analysts prefer Linux is the level of control it offers; especially over things like mounting drives. But as popular distributions like ****Ubuntu** become more user-friendly, they adopt behaviors that can be risky in forensic scenarios. #### What's the issue? By default, **Ubuntu will detect and automatically mount external storage devices** (USBs, hard drives, etc.), just like Windows. This means that as soon as you plug in a drive, it’s mounted and potentially **written to** by the OS (e.g., indexing, timestamps). > For forensic work, that's a big problem; it **violates the principle of non-intrusiveness**, possibly modifying evidence. #### Kali Linux: Better For Forensics? In contrast, **Kali Linux does *not* automount drives by default**, making it more suitable for forensic handling **out of the box**. You'll usually have to mount devices manually (we'll come to that in a minute). This manual process is ideal. It gives you the chance to: - Attach the disk as **read-only** - Decide whether to use a **hardware write blocker** - Control exactly what’s being accessed and logged --- # Best Practice for working with Images If you're using Ubuntu for forensics: - Disable automount behavior, or - Use a **live environment** like **Kali** or **Tsurugi Linux** - Always pair with a **hardware write blocker** when handling original evidence Perfect! this is an essential forensics workflow, and your audience will really appreciate a **clear, example-driven section** that explains not just the commands, but **why and how they work**, especially with disk images. ## Mounting Raw Disk Images for Forensic Analysis (Using `losetup` \+ `mmls`) In forensics, we often work with **raw disk images** (`.img` files) acquired from physical drives. To safely examine these images without altering them, we use a series of powerful Linux tools: **`losetup`**, **`mmls`** (from The Sleuth Kit), **`dd`**, and **`mount`**. Let’s break it down. ## What is a loop device? A **loop device** lets Linux treat a file like a disk image, as if it were a physical block device. This is perfect for mounting disk images for forensic review. ### Step 1: Analyze the Disk Image with `mmls` First, we inspect the image’s partition table to find the exact **offset** (in sectors) where a partition starts. ```bash mmls /mnt/forensic/testimg/testimg.img ``` What the output might look like: ``` DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0 0 1 Primary Table (#0) 01: ----- 0 16064 16065 Unallocated 02: 00:00 16065 312496379 312480315 NTFS (0x07) ``` > 💡 We want to mount the **NTFS partition**, which starts at sector `16065`. ### Step 2: Calculate the byte offset `losetup` needs the offset in **bytes**, not sectors. Multiply the sector offset by sector size (typically 512 bytes, **as to be read above**): ```bash 16065 * 512 = 8225280 ``` ### Step 3: Create a read-only loop device using `losetup` ```bash sudo losetup -r -o 8225280 /dev/loop0 /mnt/forensic/testimg/testimg.img ``` (The target folder structure is a mere example, you can `mkdir -p create/your/own`) Explanation of flags: - `-r`: **read-only:** protects the image from accidental modification. - `-o`: **offset in bytes:** tells `losetup` where the desired partition starts. You can see all `losetup` options with: ```bash man losetup ``` ### Step 4: Verifying the Filesystem in the Loop Device Before mounting anything, we want to be absolutely sure the data at the offset is a valid, recognizable filesystem, to **avoid errors and confirm our math**. We use a combo of `dd` (low-level read) and `file` (magic-bytes detection): ```bash sudo dd if=/dev/loop0 bs=512 count=1 | file - ``` ## What's happening here? - `dd` reads **just the first 512 bytes** from `/dev/loop0`, which represents the start of the partition. - The result is piped into `file`, which checks the binary data against known file signatures. **Example output:** ``` /dev/stdin: x86 boot sector, code offset 0x52, OEM-ID "NTFS", ... ``` This confirms that you're at the start of an NTFS file system. --- # Common `dd` Options (Quick Reference) | Option | Meaning | | --------------- | ---------------------------------------------------------------- | | if=... | **Input file/device** (e.g., the loop device or image file) | | bs=512 | **Block size**: read/write in 512-byte chunks | | count=1 | **Read only one block** | | skip=N | Skip **N input blocks** (starting point for reading) | | seek=N | Skip **N output blocks** (starting point for writing) | | status=progress | Show real-time progress during copy | | conv=noerror | Continue operation even if read errors occur | | conv=sync | Pad short blocks with null bytes to ensure consistent block size | | conv=notrunc | Do not truncate the output file if it already exists | ## Example: ```bash dd if=/dev/sdb of=disk.img bs=1M status=progress conv=noerror,sync ``` This creates a full disk image of `/dev/sdb`, reading in 1MB blocks, showing progress, and gracefully handling read errors. --- ### Step 5: Mounting the Partition (Read-Only!) Once you’ve confirmed there’s a valid filesystem, you can safely mount it to explore its contents. ```bash mkdir -p /mnt/testimg sudo mount -o ro /dev/loop0 /mnt/testimg/ ``` --- ## `mount` Command Breakdown | Option | Erklärung (de) / Explanation (en) | | ------------- | --------------------------------------------------------------------- | | \-o ro | Mountet das Dateisystem **read-only** → verhindert Veränderung | | /dev/loop0 | Das Loop-Gerät mit dem Dateisystem | | /mnt/testimg/ | Der **Mount-Point**, wo die Partition im Dateisystem eingebunden wird | Why `-o ro`? - This is **critical in forensics** — it ensures that the mounted volume **is not modified** (no new access times, metadata changes, etc.) - It helps preserve **evidentiary integrity** and supports **chain-of-custody compliance** > Never mount suspect evidence **read/write** unless you're working on a copy. **Then list the contents:** ```bash ls /mnt/testimg/ ``` Expected output might look like: ``` AUTOEXEC.BAT Documents and Settings Windows pagefile.sys ... ``` If you see familiar Windows directories, you’ve successfully mounted the NTFS partition from the image 🎯 ### Cleanup Tips To unmount when you're done: ```bash sudo umount /mnt/testimg sudo losetup -d /dev/loop0 ``` - For scripting: use `losetup --show` to capture the created loop device dynamically. - Want to explore deeper without mounting? Use `fls` and `icat` from SleuthKit instead - **we'll come to them soon!** # Summary Workflow | Step | Command Example | Purpose | | | ---- | ----------------------------------------- | -------------------------------------------------- | ----------------------------------------------- | | 1️ | mmls image.img | Analyze the partition layout and find start sector | | | 2️ | losetup -r -o OFFSET /dev/loop0 image.img | Attach partition to a loop device (read-only) | | | 3️ | \`dd if=/dev/loop0 bs=512 count=1 \\ | file -\` | Verify presence of a valid filesystem at offset | | 4️ | mount -o ro /dev/loop0 /mnt/testimg/ | Mount the partition read-only | | | 5️ | ls /mnt/testimg/ | Browse contents of the mounted filesystem | | ## Resources - [man losetup](https://man7.org/linux/man-pages/man8/losetup.8.html?ref=niklas-heringer.com) - [man mmls](https://wiki.sleuthkit.org/index.php?title=Mmls&ref=niklas-heringer.com) - [file command info](https://linux.die.net/man/1/file?ref=niklas-heringer.com) - [TSK (The Sleuth Kit)](https://www.sleuthkit.org/?ref=niklas-heringer.com) --- ## Sign up for Niklas Heringer Cybersecurity & Math: Aspiring penetration tester at ERNW, exploring risk, automation, and offense through analysis and experience. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. --- # Sidequest: Mounting Split Raw Images (Multi-Part .img Files) When working in digital forensics, especially when exchanging disk images between teams or tools, you’ll often run into **split raw images;** a full disk image divided into multiple smaller chunks, typically around **2 GB each**. This format is commonly used to: - Bypass filesystem limitations (e.g. FAT32's 4GB file size cap) - Simplify transfer over network or physical media - Align with tooling that handles data in segments (e.g., some forensic suites) ## Example of Split Raw Files ``` disk.E01 disk.E02 ... OR disk.img.001 disk.img.002 disk.img.003 ``` These files **don’t represent full, mountable disk images individually**. You can’t `losetup` them directly because each segment contains only a **portion** of the full image. ### Why can’t we just mount them? The Linux `loop` device requires a **complete, linear image file**. Trying to mount `disk.img.001` will fail or produce corrupted results, since the partition table and file structure are incomplete. ### Solution: Combine with `poorcase` To automate the reconstruction of split raw images, you can use [poorcase](http://code.google.com/p/poorcase/?ref=niklas-heringer.com), a Perl script by Richard Harman. It: - Detects and orders split image segments - Virtually reassembles them into a single image - Creates a unified loopback mountable device without altering the original files > 🔗 [poorcase project page (archived)](https://code.google.com/archive/p/poorcase/?ref=niklas-heringer.com) > > 💡 Alternative: You can manually concatenate with `cat`, **but only if you are absolutely sure the segments are raw and in the correct order**: ```bash cat disk.img.001 disk.img.002 disk.img.003 > full_disk.img ``` Once reassembled, you can apply the usual `mmls`, `losetup`, and `mount` steps as with any raw image. ## Summary | Problem | Solution | | -------------------------------- | ------------------------------- | | Split .img files (e.g. 001, 002) | Use poorcase to virtually merge | | Want to do it manually | Use cat, then losetup | | Cannot mount directly | True: segments are incomplete | Let's get on - the side missions are going crazy today hehe. --- # FUSE - "File Systems In User Space" FUSE not only lets us interprete filesystems, but through various FUSE modules, interpreting volumes and containers, allowing for access to their contents, is all possible. > There are maany FUSE modeuls - everything from cloud-based file systems to encrypted local file systems.. **to Wikipedia as a file system?** You can read [more about FUSE here](https://www.kernel.org/doc/html/next/filesystems/fuse.html?ref=niklas-heringer.com) ```bash sudo apt-get install zfs-fuse python-fuse fuse-zip sshfs ``` will install us: - `ZFS-Fuse` \- a driver for Sun's ZFS file system - `Python-Fuse` \- a python API for implementing FUSE file systems - `Fuse-Zip` \- a FUSE module presenting ZIP archives **as file systems** - `SSHFS` \- a FUSE module transparently presenting remote file systems as local over `SSH` (`SFTP`/`SCP`) --- # Sidequest: `apt` vs `apt-get`: What’s the Difference? We've now seen commands like ```bash sudo apt install package-name ``` or ```bash sudo apt-get install package-name ``` **But what’s the difference?** ## `apt` (modern, user-friendly frontend) - Introduced as a **newer, simplified interface** for package management - Combines common features of `apt-get`, `apt-cache`, etc. - Cleaner output, progress bars, and safer defaults for **interactive use** ```bash sudo apt install nmap sudo apt update sudo apt upgrade ``` > Recommended for **day-to-day use** by users and sysadmins ## `apt-get` (lower-level backend tool) - Older, more **script-friendly** tool used in automation - Offers **fine-grained control** and stability in scripts or package handling logic ```bash sudo apt-get install nmap sudo apt-get update sudo apt-get dist-upgrade ``` > Recommended for **scripts and legacy systems** ## 📌 `apt install` vs `apt-get install` | Command | Purpose | Notes | | --------------- | ---------------------------------- | ------------------------ | | apt install | Installs a package (user-friendly) | Preferred for most users | | apt-get install | Installs a package (classic tool) | Useful for scripting | ## TL;DR Use `apt` for everyday use. Use `apt-get` if you’re scripting or need full control. > Both do the same thing — **manage packages via APT**, the Advanced Package Tool. --- # Mounting `.E01` Forensic Images with `ewfmount` (Modern Tool) In digital forensics, it's common to encounter **EWF (Expert Witness Format)** disk images — typically split across `.E01`, `.E02`, etc. These contain not only the raw disk data, but also *case metadata*, *examiner info*, and built-in *integrity checks*. To extract and mount these images safely, we now use `**ewfmount**`, which comes with the `ewf-tools` suite. > The book uses `mount_ewf.py` here, which is now outdated, replaced by the `ewfmount` functionality in the `ewf-tools`. ## Installing `ewf-tools` on Kali Linux ```bash sudo apt update sudo apt install libewf-dev ewf-tools ``` Verify installation: ```bash ewfmount --help ``` ### What is `ewfmount`? - Mounts `.E01` images as **read-only raw disk files** - Uses **FUSE** - Outputs a raw device-like file (e.g. `ewf1`) that you can interact with directly ### Mount an EWF image Let’s say you have `WinXP2.E01` (example from the book): ```bash mkdir ~/mount_points/ewf ewfmount WinXP2.E01 ~/mount_points/ewf ``` This will **create a virtual file at**: ``` ~/mount_points/ewf/ewf1 ``` This `ewf1` file acts just like a raw `.img` disk: ready for `file`, `mmls`, `losetup`, or mounting. ### Workflow After Mounting Once `ewf1` is exposed, treat it like a raw image: **Mount read-only**: ```bash sudo mkdir /mnt/ewf_disk sudo mount -o ro /dev/loop0 /mnt/ewf_disk ``` ## Other `ewf-tools` **Calculate offset**, then attach as a loop device: ```bash sudo losetup -r -o 8225280 /dev/loop0 ~/mount_points/ewf/ewf1 ``` **Inspect partition layout**: ```bash mmls ~/mount_points/ewf/ewf1 ``` **Check the image info**: ```bash ewfinfo WinXP2.E01 ``` | Tool | Description | | ---------- | ---------------------------------------------- | | ewfacquire | Create .E01 forensic images from raw disks | | ewfinfo | View metadata inside .E01 files | | ewfverify | Check integrity and hashes of EWF containers | | ewfmount | Mount .E01 containers as virtual raw disk file | > We'll probably do a practical runthrough of this in a later session, currently there are too many tools to show each of them, as it sidetracks what i need to really learn for my uni course. --- # AFF: Outdated, But Not Gone The **Advanced Forensic Format (AFF)** was once a widely used open-source format for forensic imaging; but it's now largely **superseded** by newer formats like: - **AFF4** – adds support for logical evidence, faster access, better metadata handling - **ZFF** – simpler structure, faster processing, and modern design ## Why AFF Is Rarely Used Today - **Modern tools prefer AFF4 or `.E01`** - **ZFF offers better speed and simplicity** - **Legacy only**: AFF may still appear in older case files or forensic archives ## TL;DR Unless you're working with **legacy evidence** or specific older tools, you likely **don’t need to learn AFF in depth**. Focus instead on **AFF4, EWF (`.E01`)**, or **raw image workflows**. --- # XMount While MountEWF (and also AFFuse) both present a "raw "dd" style image", XMount is able to present a container's contents as a **VirtualBox** or **VMWare** format disk image. It can on-the-fly convert via FUSE, making it **extremely useful** for a Linux-based examiner, wishing to boot a virtual instance of an imaged system. XMount will **redirect any writes to a cache file in a directory specified by the examiner.** > Unfortunately, [since 2021, XMount received no updates](https://www.pinguin.lu/index.php?ref=niklas-heringer.com).. Maybe we'll have to examine further here. ## Understanding `uname` (Kernel Info) The `uname` command lets you query basic system and **kernel information** — essential for locating kernel modules or checking compatibility. ### Common Usage ```bash uname -a ``` Sample output: ``` Linux ubuntu 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux ``` ## What does this show? | Field | Description | | --------- | -------------------------------------------- | | Linux | Kernel name | | ubuntu | Hostname | | 2.6.32-21 | **Kernel version** — useful for module paths | | i686 | Architecture (32-bit x86 in this case) | | GNU/Linux | OS type | ## Why it's useful in forensics: You need the **exact kernel version** to: - Browse file system modules in `/lib/modules//kernel/fs/` - Check whether certain modules (like `ntfs`, `xfs`, etc.) are compiled in or loadable - View available file system support with: ```bash ls /lib/modules/$(uname -r)/kernel/fs/ ``` > That's it for today, that was chapter 2\. Tomorrow the real work here can begin after this introduction round.