<instruction>
As an experienced translator and native Simplified Chinese speaker, translate user's input into accurate, fluent and authentic Simplified Chinese. 
</instruction>

<response>
Ensure the output is neatly formatted and compliant with Markdown. Return the translation result, the complete result and nothing but the result. Strictly and faithfully translate all content provided by the user in accordance with the original text. 
**DO NOT** omit or substitute any part with self-fabricated content.
**DO NOT** return any other content, including: explanations to your decision, Markdown wrapper, XML tags, and anything you fabricate or that does not appear in the original text. 
Your response MUST contain ONLY the translated text, formatted exactly as shown in the examples. Do NOT add any explanations, commentary, summaries, introductions, sign-offs, or any other text before or after the translation itself.
</response>

<text>

## III. SYSTEM DESIGN

Penguin generates a configuration file that specifies the details of a rehosting environment. The initial configuration combines established defaults with information learned from static analysis of the target filesystem. A configuration is then realized into a rehosting environment and filesystem. This rehosting is executed and dynamic analysis results are recorded for the user. Through observation of the rehosting's runtime behavior, failures can be identified and the configuration file can be refined to address those failures. Using this iterative rehosting process, Penguin aims to be a framework for tailoring a rehosting to a specific firmware. To reproduce or share a rehosting a user simply needs the configuration file and original firmware image. The stages of the Penguin rehosting framework are shown in Fig. 1.

## A. Filesystem Analysis

We perform a series of static analyses to identify the firmware's filesystem and derive an initial rehosting configuration. Once a filesystem is generated, it is necessary to identify

![img-0.jpeg](images/img-0.jpeg.png)

Fig. 1: Rehosting a firmware with Penguin.

The original system's architecture, bit-width, and endianness to select appropriate parameters for CPU emulation. Additionally, the *init* program is identified.

Penguin extends the static analyses from both Firmadyne and FirmAE as well as supports several new analyses. While some analyses from Firmadyne and FirmAE are tailored to specific vendors (or even firmware), our novel analyses are designed to be firmware agnostic. The (configurable) suite of filesystem analyses in Penguin are summarized in Table I and given more detailed treatment in Appendix C.

### *B. Rehosting as a Configuration*

After the filesystem analyses are complete, the Penguin user has an initial rehosting configuration. A Penguin rehosting is a YAML file that is paired with a repackaged filesystem to precisely specify that rehosting. The configuration capabilities can be broadly categorized into three groups: static filesystem modifications, runtime environment, and dynamic analyses. A brief example of a configuration is in Appendix B.

*1) Static Filesystem Modifications:* Users can define a set of modifications to make this file filesystem before the rehosting starts. Files can be added, deleted, or moved.

*2) Runtime Environment:* The configuration specifies the emulated environment that the rehosting will execute under. This includes emulator configuration (e.g., which CPU architecture), Linux boot arguments, network device names, and initial NVRAM values. Additionally, the configuration can specify new pseudofiles in */proc*, */dev*, and */sys* as well as models for how those pseudofiles should behave.

*3) Dynamic Analyses:* While a rehosting runs it can be analyzed to identify failures and inform future refinement to the rehosting configuration. Beyond the rehosting process, dynamic analyses of a rebooted system can also be leveraged to reverse engineer system behavior, identify vulnerabilities, or otherwise exercise the functionality of a system.
</text>