Hubbry Logo
IBootIBootMain
Open search
IBoot
Community hub
IBoot
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
IBoot
IBoot
IBoot
View on Wikipedia
from Wikipedia
iBoot
DeveloperApple Inc.
Initial releaseJune 29, 2007
Stable release
iBoot-11881.80.57~171 (RELEASE, iOS 18.3 RC and iOS 18.3.1)
Preview release
iBoot-11881.80.57~107 (RELEASE, iOS 18.3 beta 1)
Operating systemDarwin, macOS,[1] iPadOS and iOS[2]
Platformx86, ARM
TypeBoot loader
LicenseProprietary software

iBoot is the stage 1 and stage 2 bootloader for iPhones, iPads, Apple silicon-based Macs, and the T2 chip in Intel-based Macs with such a chip.[3][4] Compared with its predecessor, iBoot improves authentication performed in the boot chain.[2]

For Intel-based Macs with a T2 chip, the boot process starts by running code on the T2 chip from the boot ROM. That boot ROM loads and runs iBoot onto the T2 chip; iBoot loads the bridgeOS operating system onto the T2 chip and starts it; bridgeOS loads the UEFI firmware; UEFI firmware starts the main Intel processor and completes the Power-On Self Test process. The UEFI firmware loads boot.efi, which loads and starts the macOS kernel.[4] For Intel-based Macs with a T2 chip, the UEFI firmware may be called iBoot UEFI.

For iPhones, iPads, and Apple silicon-based Macs, the boot process starts by running the device's boot ROM, which is integrated into the device's SoC. On iPhones and iPads with A9 or earlier A-series processors, the boot ROM loads the Low-Level Bootloader (LLB), which is the stage 1 bootloader and loads iBoot, and LLB is stored on an EEPROM; on iPhones and iPads with A10 or later processors, as well as Apple silicon Macs, the boot ROM loads iBoot, and LLB and iBoot are stored on NAND flash or internal SSD, which is a NOR-less boot flow.[5][6] If all goes well, iBoot will then proceed to load the iOS, iPadOS or macOS kernel as well as the rest of the operating system.[7][8][9] If iBoot fails to load or fails to verify iOS, iPadOS or macOS, the bootloader jumps to DFU (Device Firmware Update)[10] mode; otherwise it loads the remaining kernel modules.[2][11]

Once the kernel and all drivers necessary for booting are loaded, the boot loader starts the kernel’s initialization procedure. At this point, enough drivers are loaded for the kernel to find the root device.[12]

Build styles

[edit]

According to the leaked iBoot source code (from February 7, 2018),[13] in apps/iBoot/iBoot.mk, defines the valid build styles as "RELEASE", "DEVELOPMENT", "DEBUG", and "SECRET" when building a copy of iBoot.[citation needed] These build styles define specific information when the bootloader is compiled, such as adding more debugging commands for finding issues on a developmental device, or performing hardware tests using the iBoot command prompt over serial.

Meanings

[edit]

RELEASE - A release version

DEVELOPMENT - A build that is used on developmental hardware, allows access to some developmental tools, such as the 'diags' command.

DEBUG - A build used for debugging iOS and other lower-level components

Features

[edit]

iBoot features a command prompt when in recovery, DFU, or restore mode (it is also in "DEBUG" builds of iBoot, but was never seen in future builds). Command availability depends on the type of iBoot being used, especially the build style (can be RELEASE, DEVELOPMENT, DEBUG, SECRET, etc).[citation needed]

When using iBoot's command prompt, the included commands are used to manage the behaviour, such as its boot arguments (internally called the "boot-args" in the NVRAM), or if the startup command (fsboot) should be used when iBoot is automatically loaded (known as auto-boot).[14][15]

Memory safety

[edit]

Apple has modified the C compiler toolchain that is used to build iBoot in order to advance memory safety since iOS 14. This advancement is designed to mitigate entire classes of common memory corruption vulnerabilities such as buffer overflows, heap exploitations, type confusion vulnerabilities, and use-after-free attacks. These modifications can potentially prevent attackers from successfully escalating their privileges to run malicious code, such as an attack involving arbitrary code execution.[16]

Source code leak incident

[edit]

In 2018, a portion of iBoot source code for iOS 9 was leaked on GitHub for various iPhone, iPad, iPod touch, and Apple Watch models,[17] Apple then issued a copyright takedown request (DMCA) to GitHub to remove the repository. It was believed an Apple employee was responsible for the leak. However, this was not confirmed by Apple. It is known that a user by the name of "ZioShiba" was responsible for the publication of the iBoot source code.

History

[edit]
iBoot-87.1, the earliest known version of iBoot running on production hardware over serial. Screenshot by mcg29 on Twitter.

The earliest known version of iBoot was iBoot-87.1, seen on very early prototypes during the iPhone's production in 2006-2007.[18] It had the same features as the first known version of iBoot (iBoot-99), except it not having features before the final release. This version of iBoot could be considered the "first early beta" of iBoot. Following the release of the iPhone 2G and iPhone OS 1, the first release iBoot version was iBoot-159.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

IBoot

View on Grokipedia
from Grokipedia
iBoot is the stage 2 bootloader developed by Apple Inc. for iOS, iPadOS, and macOS devices equipped with Apple silicon, as well as Intel-based Macs featuring the T2 Security Chip; it serves as a critical component in the secure boot chain by verifying and loading the operating system kernel, such as XNU for macOS or the iOS kernel. In the boot process, iBoot is initially verified and executed by the device's Boot ROM, which uses Apple's root certificate authority public key to ensure the bootloader's signature and integrity before allowing it to proceed. Once active, iBoot handles additional tasks depending on the hardware: on iPhone and iPad devices with A9 or later processors, it loads and authenticates the kernel; on Apple silicon Macs, it loads macOS-paired firmware components like the Secure Neural Engine, verifies the signed system volume's root hash, and locks protected memory regions via System Coprocessor Integrity Protection (SCIP). If verification fails at any step, the boot process halts, often requiring a factory restore through tools like Finder or iTunes to reestablish the chain of trust. iBoot incorporates robust measures to prevent unauthorized modifications and exploits, including cryptographic signing by Apple to enforce only trusted execution. Starting with and on devices featuring the A13 Bionic chip or later (and A14 Bionic for ), Apple enhanced iBoot with a memory-safe implementation via modifications to its , which prevents buffer overflows through pointer bounds checking, mitigates heap exploits by separating data and metadata to detect double frees, reduces type confusion during pointer casts, and addresses use-after-free errors by segregating dynamic by type. On Macs, iBoot supports flexible modes—such as Reduced Security for legacy compatibility and Permissive Security for custom kernels signed by the Secure Enclave—while and enforce Full mode exclusively to boot only the latest verified software.

Overview

Definition and Role

iBoot is Apple's proprietary stage 2 bootloader, developed by . for initializing hardware and loading the operating system kernel in a secure manner across its devices. Introduced with the original on June 29, 2007, it serves as a critical component in the boot process, particularly for , , and macOS on . The core purpose of iBoot is to authenticate and load the kernelcache—such as for / or macOS—following verification by the Low-Level Bootloader (LLB) or directly by the , depending on the system-on-chip (SoC) generation. This ensures the chain of trust established by the immutable , where each stage cryptographically verifies the next to prevent unauthorized code execution. On devices with A9 or earlier A-series processors, the LLB loads and verifies iBoot; on later SoCs like A10 or , iBoot may be loaded more directly while maintaining the same security principles. Technically, iBoot operates on architectures—prevalent in iPhones, iPads, and Macs—and has implementations adaptable to x86 contexts in certain Intel-based systems with the T2 Security Chip, where it oversees initial hardware setup, memory mapping, and seamless kernel handoff. Its design prioritizes security, with features like signature verification using the Apple Root CA public key to uphold the integrity of the boot process.

Supported Devices and Platforms

iBoot primarily supports Apple's mobile devices, including all iPhones from the original model (2007, S5L8900 SoC) onward, iPod touches from the first generation, and iPads from the first generation (2010, A4 SoC) equipped with A-series processors running and , respectively. It serves as the stage 2 in the secure boot chain for these platforms, verifying and loading the kernel after the stage. The bootloader extends to desktop platforms through integration with Apple's custom silicon. On Apple silicon-based Macs featuring M-series chips (such as M1 through M4), iBoot handles the verification of macOS components, including the kernel and system volume, as part of the ARM64 architecture boot process. This support began with the introduction of Apple silicon in 2020, enabling a unified secure boot mechanism across mobile and computing ecosystems. For Intel-based Macs, iBoot operates via the T2 Security Chip, an ARM-based coprocessor introduced in 2018 models like the MacBook Pro, which manages secure boot for the x86_64 architecture while isolating security functions from the main CPU. Architecturally, iBoot is optimized for ARM-based systems on iPhones, iPads, and Macs, utilizing the Secure Enclave for cryptographic verification. On T2-equipped Macs, it bridges to x86_64 by loading firmware after initial checks on the T2 chip. This cross-architecture adaptability ensures consistent security enforcement, with iBoot loading the kernel tailored to the device's processor. As of November 2025, iBoot remains compatible with the latest software releases, including 19 and 19 on A-series devices (such as A17 Pro and A18), 16 (with Sequoia updates) on M-series Macs, and continued support for T2-equipped models running compatible versions. This encompasses all active A-series (A4 through A18), M-series (M1 through M4), and T2-integrated hardware, reflecting ongoing evolution from its initial iOS-centric role to a core component across Apple's unified hardware ecosystem.

Technical Architecture

Build Styles

iBoot employs four primary build styles during compilation: RELEASE, DEVELOPMENT, DEBUG, and SECRET. These configurations, defined in the project's makefile (iBoot.mk), tailor the bootloader's behavior, feature set, and optimization for different phases of development and deployment. The choice of build style influences code size, diagnostic capabilities, and security postures, ensuring that production versions prioritize efficiency while internal variants support extensive . The RELEASE style represents the standard production configuration deployed on consumer devices via firmware updates. It is optimized for speed and , while disabling logging, assertions, and unnecessary diagnostic features to reduce the potential . In this mode, iBoot enforces strict NVRAM environment variable restrictions using whitelists, limiting options like boot-command to values such as fsboot or recover, thereby ensuring stable and secure kernel loading without extraneous overhead. DEVELOPMENT builds include partial debugging aids for internal testing on engineering prototypes, enabling features like execution of untrusted images on Image3-compatible hardware and temporary overrides for hardware debugging interfaces such as . These configurations activate moderate verbosity in output and balance performance with accessibility. They are typically used during quality assurance and early to verify compatibility without compromising core mechanisms. DEBUG variants provide the most comprehensive support, incorporating full , assertions, and hardware tests like UART-based serial for in-depth issue diagnosis. These builds are reserved for advanced scenarios, such as root-causing failures on prototypes. Compilation facilitates step-through execution and variable inspection in tools like GDB, along with enhanced command availability in the iBoot prompt for verbose diagnostics. The SECRET style is referenced in the code but lacks definitions in the device map, rendering it unbuildable and likely serving as an rather than a functional configuration.

Integration in Boot Chain

iBoot integrates into Apple's secure boot process as a critical stage in the multi-stage , where each component verifies the integrity and authenticity of the subsequent one to prevent unauthorized code execution. The boot sequence begins with the immutable , which serves as the hardware root of trust and contains Apple's root public key to cryptographically verify and load the Low-Level Bootloader (LLB) on devices with A9 or earlier chips, or iBoot directly on later devices. The LLB, when present, then verifies iBoot using checks before execution, ensuring the chain remains unbroken from hardware initialization. Upon execution, iBoot performs essential verification and loading tasks, including signature checks on the kernelcache using Apple's public keys embedded in , initialization of the device tree for hardware configuration, and handover to the kernel for full system . This process enforces the loading of only Apple-signed components, with iBoot specifically verifying the or kernel before execution. Additionally, iBoot integrates with the Secure Enclave Processor (SEP) to manage key operations and secure verification, where the SEP runs its own sepOS and updates progress registers to support modes like recovery. The chain of trust is maintained through cryptographic verification at every stage, with each using Apple's certificates to validate signatures of the next component, thereby establishing a tamper-evident path from the onward. Failure in any verification step halts the and may require a restore to reestablish the chain. iBoot upholds this by enforcing SEP involvement for secure and anti-replay protections. In adaptations for devices, iBoot receives control from the LLB after the latter verifies system-paired , then handles loading of macOS-paired components such as the Secure Neural Engine , while managing unified memory allocation and GPU initialization as part of the kernel collection handover. For Intel-based Macs with the T2 chip, the T2's verifies iBoot, which in turn checks the kernel and extensions on the T2 before bridging to Intel and enabling macOS recovery paths if needed. These variations ensure the chain of trust extends across diverse hardware architectures while preserving core verification mechanisms.

Features

User Interfaces and Modes

iBoot provides user interfaces primarily through recovery mode and DFU mode, which serve as entry points for troubleshooting, firmware restoration, and low-level interactions during boot failures or updates. These modes are activated via specific hardware button combinations while connecting the device to a host computer via USB, allowing tools such as Finder or iTunes to communicate with the bootloader. For example, to enter recovery mode on an iPad without a Home button, connect the iPad to a computer with a USB cable, then quickly press and release the Volume Up button, quickly press and release the Volume Down button, and press and hold the Top button until the recovery mode screen appears (showing a computer and cable icon). In recovery mode, iBoot initializes and displays the Apple logo on the device screen, establishing a USB-based communication channel for firmware updates and restoration processes. This mode enables the loading of ramdisk images for diagnostic purposes, facilitating advanced recovery operations like filesystem verification or custom payload injection when supported by host tools. The command prompt in recovery mode, accessible via USB using utilities like iRecovery from the libirecovery library, allows developers and recovery tools to issue interactive commands for low-level device management. Representative commands include "reboot" to restart the device and "setenv" followed by an environment variable to configure boot parameters, such as setting auto-boot behavior. For example, the sequence "setenv auto-boot true" followed by "saveenv" persists the change for subsequent boots, while "go" can be used to manually load and execute a specified image file. DFU mode, or Device Firmware Upgrade mode, offers a more fundamental interface by bypassing the device's display and normal boot sequence, with the screen remaining black to indicate entry. In this mode, the device's BootROM loads iBoot as a from the host computer, enabling low-level upgrades without on-device output or user-visible feedback. iBoot then waits passively for host-initiated payloads, such as signed images injected via or specialized tools, supporting scenarios where recovery mode is inaccessible due to hardware or software issues. The command prompt is similarly available in DFU mode through USB communication, inheriting the same interactive capabilities as in recovery mode for command execution. The user interfaces in both modes are strictly text-based, relying on serial-like USB protocols for input and output, and are non-persistent across reboots unless environment variables are explicitly saved. In RELEASE builds of iBoot, access to the command prompt and certain commands is restricted to enhance , limiting functionality compared to DEBUG or DEVELOPMENT builds used in testing. These interfaces integrate within the broader boot chain, providing controlled entry points for host-assisted recovery without altering the automated normal boot process.

Configuration Options

iBoot provides several configuration options to customize boot behavior, primarily through boot arguments passed during the loading . These arguments function as command-line flags that influence device initialization, kernel loading, and . For instance, the "rootdev=md0" specifies booting from a memory disk (ramdisk), enabling temporary file systems for recovery or diagnostic purposes. Similarly, "debug=0x14e" sets detailed levels for , capturing events from kernel initialization to hardware bring-up. The "rootdev" argument selects the boot volume, such as specifying a memory disk (e.g., md0) for ramdisk-based . These options are particularly useful in development, restore, or jailbreak scenarios where standard boot paths need modification. Auto-boot settings in iBoot allow control over the timing and default paths for automatic startup. A configurable delay, such as the 5-second displayed in recovery mode, gives users a brief to the process before proceeding to the default kernel load. The default kernel path can also be specified, directing iBoot to load a particular kernelcache image. These settings are stored persistently in , such as NVRAM for Intel-based devices or secure integrated storage for , ensuring they survive reboots unless explicitly reset during a factory wipe or restore. Device-specific options tailor iBoot's behavior to hardware variations. On devices, secure boot policy flags define the posture, including Full Security for strict Apple-signed OS enforcement, Reduced Security to allow feature disabling without validation, and Permissive Security for third-party kernel support under owner authentication. These policies are embedded in the LocalPolicy file and applied during iBoot execution to validate the chain. For devices, configuration enforces jailbreak detection through mandatory signature checks on all loaded components, preventing unsigned code from proceeding in the sequence. Management of these options occurs primarily through external host tools or during device restore processes. Tools like libimobiledevice, via its libirecovery component, enable communication with iBoot over USB to upload custom images or inject arguments during recovery or DFU modes. Configurations set this way remain persistent across reboots but can be altered or wiped using the same tools or Apple's official restore methods in Finder or . This approach ensures controlled modifications without direct hardware access.

Security

Memory Safety Enhancements

Apple introduced memory safety enhancements to iBoot with the release of and in 2020, modifying the compiler specifically for building the to address common memory vulnerabilities. These changes incorporate bounds-checked pointers that verify access bounds at runtime, effectively preventing buffer overflows in code. The enhancements also include embedded in pointers, which is verified during casts to mitigate type confusion issues. Further mitigations target heap-related exploits by separating heap data from metadata, enabling detection of double free errors and reducing opportunities for heap manipulation. Dynamic allocations are segregated by static type, which helps prevent use-after-free vulnerabilities that could lead to type confusion. These proactive measures eliminate many traditional risks in iBoot's C codebase without requiring a full rewrite to a memory-safe . The impact of these enhancements is a significant reduction in the exploit surface for boot-time attacks, as they harden critical paths in iBoot against memory corruption and violations. Available on iPhones with A13 Bionic chips or later and iPads with A14 Bionic or later, the features have been verified and maintained in subsequent releases, including 18 and later. No major iBoot breaches have been publicly reported since implementation through 2025.

Notable Incidents

In February 2018, the source code for iBoot from was leaked on by a user named ZioShiba, prompting Apple to confirm its authenticity and issue a DMCA takedown notice to remove the repository. The leak, suspected to originate from an internal Apple employee sharing it with the jailbreaking community, exposed key components of the responsible for secure boot processes. The disclosure revealed details on routines, verification mechanisms, and other low-level operations, potentially aiding researchers in identifying exploit vectors within the boot chain. Despite this, the code pertained to an older version, and third-party analyses did not result in widespread jailbreaks for devices running updated , as Apple emphasized that modern implementations incorporate multiple layers of protection. Earlier, in February 2014, developer iH8sn0w publicly disclosed an iBoot exploit targeting A5 and A5X processor chips, enabling untethered jailbreaks on compatible devices such as the , , and iPad 3. This vulnerability, distinct from bootrom flaws, allowed persistent modifications to the boot process but was mitigated in subsequent versions and hardware generations beyond A5X. No major iBoot-related incidents have been confirmed through 2025.

History

Origins and Early Versions

iBoot was developed as part of Apple's secretive Project Purple, the internal initiative to create the first , which began in earnest around 2005 and intensified through 2006. This effort involved a team of top engineers working under strict nondisclosure to integrate hardware and software innovations, including the that would become iBoot. The component emerged to handle low-level device initialization for the ARM-based prototypes, replacing earlier loaders like BootX with a more secure and efficient stage 2 . The earliest known version, iBoot-87.1, appeared on prototypes during production in 2006–2007, predating more stable builds and serving as a foundational for testing hardware integration. This version was observed in early SwitchBoard builds, such as 1A396b, reflecting iterative development on pre-release hardware like the Nanshan prototypes. Internal testing relied on DEBUG build styles to facilitate diagnostics and during this phase. iBoot-159 marked the first public release, bundled with the iPhone 2G and iPhone OS 1.0 on June 29, 2007. It introduced a basic , leveraging a hard-coded in the SecureROM to verify subsequent boot components, ensuring only trusted code proceeded. Early features centered on ARMv6 processor support, initialization of NAND flash storage, and straightforward kernel loading from the kernelcache, prioritizing reliable boot-up without advanced recovery options. This version laid the groundwork for the iOS boot chain on 32-bit devices using IMG3 encoding for payload integrity.

Evolution and Recent Developments

Following the initial release with the in 2008, iBoot evolved to support emerging hardware capabilities, such as connectivity and GPS, with further enhancements for efficiency and security as Apple expanded its device lineup. Multi-core processor support was added in 2011 with the and the A5 chip, improving boot performance on subsequent devices. In 2013, with the and , iBoot began integrating support for the Secure Enclave Processor (SEP), enabling hardware-accelerated and secure during the boot process, alongside the shift to 64-bit architecture. These mid-period updates focused on enhancing efficiency and security, laying the groundwork for more complex boot chains. iBoot's role expanded beyond mobile devices in 2018 with the introduction of the T2 security chip in Intel-based Macs, where it served as a key component in the secure boot process alongside EFI firmware. This marked iBoot's entry into the Mac ecosystem, handling tasks like secure storage access and coprocessor initialization. Full integration arrived in 2020 with on Macs, replacing traditional EFI with iBoot as the primary , version 6723.41.11 in initial releases, to unify the boot experience across platforms and leverage custom silicon for faster, more secure startups. Recent iterations include iBoot-11881.80.57, released with 18.3 in January 2025. As of November 2025, 19 (released September 2025) and macOS Tahoe 26.1 (released November 2025) feature iBoot version 13822.41.1 on M4-equipped devices, introducing optimizations for unified architectures and enhanced boot efficiency, including refined kernel handoff mechanisms while maintaining the chain of trust. Key developments post-2018, following the public leak of iBoot source code from an iOS 9-era build, prompted Apple to strengthen code protections, though specific obfuscation techniques remain proprietary. Starting with , iBoot incorporated memory safety enhancements via modifications to the C compiler toolchain, reducing vulnerabilities in the bootloader by enforcing bounds checking and other runtime protections on supported devices.

References

  1. https://support.apple.com/guide/security/boot-process-for-iphone-and-ipad-devices-secb3000f149/web
  2. https://support.apple.com/guide/security/boot-process-secac71d5623/web
  3. https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web
  4. https://support.apple.com/guide/security/glossary-sec93292bfa6/web
  5. https://newosxbook.com/bonus/iboot.pdf
  6. https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
  7. https://theapplewiki.com/wiki/IBoot_(Bootloader)
  8. https://support.apple.com/guide/security/boot-process-sec5d0fab7c6/web
  9. https://support.apple.com/guide/security/boot-modes-sec10869885b/web
  10. https://nyansatan.github.io/building-iboot/
  11. https://support.apple.com/en-us/118106
  12. https://support.apple.com/en-us/108925
  13. https://github.com/libimobiledevice/libirecovery
  14. https://blog.elcomsoft.com/2020/01/ios-recovery-dfu-and-sos-modes-forensics/
  15. https://www.sciencedirect.com/science/article/pii/B9781597496599000055
  16. https://github.com/checkra1n/BugTracker/issues/830
  17. https://asahilinux.org/docs/platform/introduction/
  18. https://www.bbc.com/news/technology-43001911
  19. https://theverge.com/2018/2/8/16992626/apple-github-dmca-request-ios-iboot-source-code
  20. https://www.vice.com/en/article/how-iphone-iboot-source-code-leaked-on-github/
  21. https://thehackernews.com/2018/02/iboot-ios-source-code.html
  22. https://9to5mac.com/2018/02/08/iboot-source-code-leak-apple/
  23. https://securityaffairs.com/68853/hacking/apple-iboot-data-leak.html
  24. https://www.idownloadblog.com/2014/02/01/a5-exploit-jailbreak-for-life/
  25. https://wccftech.com/a5x-jailbreak-for-life-iphone-ipad-touch/
  26. https://www.macrumors.com/2018/02/09/iphone-source-code-leaked-by-apple-employee/
  27. https://www.techtarget.com/searchsecurity/answer/How-bad-is-the-iBoot-source-code-leak-for-Apple-security
  28. https://www.mac-history.net/2021/10/03/project-purple-2-how-apple-developed-the-iphone-as-a-secret-project/
  29. https://www.wired.com/story/iphone-10-jony-ive-project-purple-cult-of-mac/
  30. https://theapplewiki.com/wiki/IBoot-87.1
  31. https://theapplewiki.com/wiki/IBoot_%28Bootloader%29
  32. https://mrmacintosh.com/restore-macos-firmware-on-an-apple-silicon-mac-boot-to-dfu-mode/
  33. https://betawiki.net/wiki/MacOS_Big_Sur_build_20A5299w
  34. https://mrmacintosh.com/macos-tahoe-26-1-update-everything-you-need-to-know/
  35. https://www.macrumors.com/2018/02/07/iphone-source-code-github-leak/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.