Как изменить ios wii

Наконец-то я решился выложить на сайт Pimp my WII, программа, которая решит 1000 и 1 проблему для wii в умелых руках, и может наделать 1000 и 1 проблему в неумелых.

Да, именно так, программа Pimp my Wii — мощнейший инструмент, благодаря которому решаются практически все вопросы вылета, черного экрана и «что-то не работает». Если даже после использования Pimp my Wii наблюдаете вылет программы — все ясно: программа просто не рабочая.

Итак, суть Pimp my Wii заключается в следующем:

Программа сканирует все установленные IOS’ы и просто обновляет их, если некоторых IOS не хватает, она качает их и устанавливает.

Программа обновляет каналы WII в автоматическом режиме. Wii должна быть подключена к интернету!

Все, что вам необходимо — нажать Perform the test and fix problems и просто ждать.

Дефолтные YES и NO изменять не нужно для каждого иоса (т.е. грубо говоря просто всегда жмем «А»)

После чего Мы получаем консоль, с обновленными IOS, которые мы нигде не искали и не скидывали!

Программа может обновить Shop Channel!

Установка:

Скачиваем Pimp my Wii:

Скачать

 Скачать

Папку pimp_my_wii скидываем в папку apps на SD

3.Запускаем через homebrew channel

4.Пользуемся, согласно инструкции

Канал или, как его еще называют, форвадер для Pimp my Wii я не стал включать в сборку архива, ведь Pimp my Wii хорошая программа, но включать ее каждый день смысла нет!

Скачать

Дополнительные возможности:

Pimp my Wii умеет обновлять и различные лоадеры, но для этого папки в apps на SD должны иметь следующие названия:

-> Neogamma, in version R9 beta 50 minimum. Dirname : neogamma
-> Usb Loader gx, in version 2.2 minimum. Dirname : usbloader_gx
-> Uloader, in version 5.1 minimum. Dirname : uloader
-> Wiiflow, in version 2.2 (or r302) minimum. Dirname : wiiflow
-> Configurable usb loader, in version 70 minimum. Dirname : usbloader or usbloader_cfg

PS Данная версия Pipm my WII подходит и для WiiU! А также для всех регионов, кроме Корейского!!!(хотя вроде как и там должна работать)!

Have a nice day;)

---

---

This tutorial will tell you how to install Leseratte’s d2xl Wii mini cIOS (custom IOS). This is required if you want to load games with a USB Loader. Some homebrew might work better using cIOS.

This guide is only intended for Wii mini users. If you have a Wii, follow this guide instead.

If you need help with anything regarding this tutorial, please join the Wii mini Hacking Discord server (recommended)

This d2x cIOS installer was originally developed for the Wii U’s vWii by DaveBaol and custom cIOS was created by Leseratte for the Wii mini. The original download page can be found here. Leseratte’s Github page can be found here. Please note that this cIOS is still experimental, though no problem with functionality has been reported.

What you need

• A Wii mini with the Homebrew Channel installed
• A USB drive
• Leseratte’s d2xl cIOS Installer

Instructions

Section I — Downloading

1. Extract the d2xl cIOS Installer to the apps folder on your USB drive.
2. Insert your USB drive into your Wii mini and load the d2xl cIOS Installer from the Homebrew Channel.

Section II — Installing

1. Press continue, then set the options to the following:

    Select cIOS: d2xl-v1-beta2
    Select cIOS base: 57
    Select cIOS slot: 249
   

   Take a note of the version number under notes (IOS57-64- ending in either v31776 or v31775)

2. Once set, press A to install. Once done successfully, exit the installer.
   • If the install fails with a TMD version mismatch error, press left or right on the +Control Pad over the Select cIOS base option until the version number is different than the one you tried before. The number 57 will not change.

Enabling Ethernet

If you wish to use Wiimmfi with Ethernet on a Wii mini, you have to run the Ethernet Enabler Homebrew app made by Fullmetal5. To run it, just unzip it in the apps folder of your USB drive and run it from the Homebrew Channel.

The Wii and Wii mini consoles are only known to work with Ethernet adapters using the AX88772 chip. Please check that the product is compatible before you buy. This one from UGREEN is known to be compatible: Amazon Europe, Amazon US

Do not attempt to install a Wii IOS or System Menu on the Wii mini. Doing so will likely brick your console.

You can now use homebrew such as USB Loader GX and WiiFlow.

Continue to site navigation
We have many other tutorials that you might like.

---

Not to be confused with Apple’s iOS, which runs on the iPhone, which was released half a year after the Wii, or IOSU, which runs on the Wii U, sometimes referred to as IOS.

IOS (sometimes internally referred to as IOP — possibly «Input Output Proxy») is the operating system that runs on the Starlet (IOP) coprocessor (Starbuck on the vWii) inside the Hollywood package. It provides services that are used by Wii code to access many system devices: USB, networking, security, app management, NAND flash storage, SD card, optical disc, and also WiiConnect24 features.

All software using the Wii SDK or libogc relies on a running IOS on the Starlet (with a few exceptions in the latter case — it is possible to shut down IOS services from libogc and work without it). Typically, the only times IOS is not in use is when running GameCube software (which uses MIOS instead — effectively a dummy IOS), or when BootMii and related software is in use (which uses mini instead).

IOS is not a «hypervisor», as it runs on a dedicated, separate CPU. However, IOS does isolate its memory from access by the main Broadway CPU, has the ability to reboot (and hence bootstrap) it, and is designed to be secure if the PowerPC side is compromised (although in practice many exploits have been found). In that sense, IOS is higher in the security hierarchy than code running on the PowerPC.

Since the IOS API is largely forwards-compatible, it is often possible (though not recommended) to run official software with an alternate IOS branch or slot; BC-NAND takes advantage of this so that IOS does not need to be reloaded a second time every time a title is launched. Homebrew software will often run under a relatively large range of IOS versions, sometimes constrained by requiring newer features (e.g. USB EHCI support).

When the Wii is in WiiConnect24 standby mode (yellow LED), the main PowerPC CPU is off, but IOS is still running.

The IPC SDK library seems to have copies of some IOS syscalls such as IOS_AllocAligned; this may mean IOS was originally planned to be part of the SDK, but that was scrapped when there was no way to keep that secure.

See Also

• IOS — Questions and Answers
• IOS History
• IOS kernel
• IOS Syscalls
• Syscall IDAPython
• Resource request
• IoBuffer
• ARM Binaries
• vWii IOS List

Versioning

IOS is versioned in a somewhat unique way. Instead of there being a single canonical version of IOS, there are multiple branches, each typically corresponding to one or more versions of the Wii SDK. Each branch is apparently specified to have a completely frozen API, and old versions are only updated to patch bugs (often security bugs) — Nintendo at one point created an entirely new IOS branch that differed only in the default value for the TCP buffer size. A fully updated Wii contains one copy of the latest version of each branch of IOS. On a Wii, these are installed as separate titles, often called «IOS slots». Due to this design, it is generally considered safe to uninstall, reinstall, or patch an IOS or IOS module, as long as it is not the slot used by the System Menu — if anything goes wrong, the broken version can be safely uninstalled and a vanilla copy reinstalled. IOS slots have title IDs 1-3 through 1-255. Unused (high) IOS slots are often used to install patched versions of IOS or alternative Starlet software (e.g. BootMii as IOS is installed as IOS254, which when invoked will subsequently load armboot.bin from the SD card, typically mini). See IOS History for a comprehensive list of IOS slots and versions.

Some IOS branches are identical outside of minor build information, such as IOS14 and IOS15. These branches are referred to as «twins» on the respective pages about these branches. Most twins have identical version numbers for corresponding versions, which makes identifying possible twins simple. Twins are typically built at very similar times, and in some cases, certain modules are substituted, such as FS and FFS being switched.

There are also some cases (mainly in the 4.3 batch IOS update) where some IOS branches have been replaced with copies of other branches, such as IOS33 and IOS34 being replaced with copies of IOS35. Through content sharing, this reduces the storage space required by IOSes, and it reduces the number of IOSes that need to be reverse engineered in a batch update. Such IOSes have been marked as shadow versions.

Architecture

IOS is a Nintendo-proprietary, embedded operating system. It uses a microkernel architecture, where independent processes communicate using a standard file API (open/read/write/seek/ioctl/ioctlv/close) on resources identified by /dev/ entries in a virtual filesystem hierarchy. Real filesystems (chiefly the NAND filesystem) are also mounted this way (the NAND driver registers itself as the fallback handler for the root node, /).

Kernel

The kernel is the piece of code that is launched first; it consists of a small ELF-loader header followed by the ELF executable of the kernel proper. In addition to the core microkernel and the cryptography core, it contains the bare minimum set of processes/drivers necessary to load the rest of the modules from the NAND filesystem: FFS (Flash Filesystem), ES (E-Ticket Services), and IOSP (responsible for booting and managing the Broadway and its IPC interface). Older IOS versions (prior to IOS28) were monolithic and contained all modules inside the single main ELF kernel. boot2 is essentially a standalone IOS kernel with no additional modules or drivers, whose sole purpose is to locate the System Menu’s IOS and launch it.

The IOS kernel is able to handle up to 100 threads.

IPC

Communication with IOS from PPC code is done using an IPC mechanism. There are 7 calls that can be made using this system:

1. open
2. close
3. read
4. write
5. seek
6. ioctl
7. ioctlv

There is also a cmd value (8) that is used for messages that are automatically sent to an IOS queue when an asynchronous syscall completes, and another cmd value (9) used internally by IOSP to indicate that a new unprocessed message has arrived.

ipc struct size = 0x40, aligned to 0x20

00:     cmd     // 1=open 2=close 3=read 4=write 5=seek 6=ioctl 7=ioctlv 8=async response
04:     ret
08:     fd      // file handle returned by open that is passed to other calls
0c:     arg[5]  // see below

open:   fd = 0
        arg0, arg1: name, mode (1=read 2=write)

close:  fd

read:   fd
        arg0, arg1: addr, len

write:  fd
        arg0, arg1: addr, len

seek:   fd
        arg0, arg1: where, whence

ioctl:  fd
        arg0: ioctl #
        arg1, arg2: addr, len
        arg3, arg4: addr, len

ioctlv: fd
        arg0: ioctl #
        arg1: # in
        arg2: # out (or in-out)
        arg3: pointer to # in plus # out pairs of (addr, len)

async:  ret: result from asynchronous syscall
        arg[0-5]: will be untouched from when the ipcmessage struct was passed to the syscall, so you can put whatever you like in them beforehand.

Most non-trivial operations are performed by opening one of the below resources, then calling ioctl or ioctlv on it.

The Starlet kernel hands these calls over to the individual drivers / processes within the Starlet. The processes register themselves to handle requests by creating one or more queues and assigning them to handle requests from a particular /dev device. The IPC interface is essentially identical to the internal microkernel inter-process communication system calls, and indeed maps directly: PPC requests are marshalled by IOSP and appear to come from its process ID to other IOS modules. Oversights in checking whether a request comes from another IOS module or the PowerPC have resulted in several exploitable bugs.

Modules

IOS modules are ELF executables contained in separate title content entries within an IOS title. Modules roughly map to processes and drivers inside the kernel. The shared-content mechanism allows different IOS slots to reuse the same module binaries when they have not changed, to save space in the console’s Flash memory.

List of processes in IOS59

PID	Name	Notes
N/A	ELF Loader	Only used to boot kernel
0	Kernel
1	ES	ES sets its own UID and GID to 0 on startup.
2	FS
3	DI
4	OH0
5	OH1
6	EHCI
7	SDI
8	USB Ethernet
9	Net
10	WD
11	WL
12	KD
13	NCD
14	STM
15	PPCBOOT	The IPC server runs under this PID, meaning requests from the PPC (via the IPC mechanism) appear to come from this process.
16	SSL
17	USB	Several internal USB modules check the UID to make sure their resource managers can only be opened from /dev/usb/usb.
18	P2P (?)
19	Unknown	Literally «unknown» in IOS. This PID is used by the WFS modules.

Each process has an associated UID and GID, which can be only changed by the kernel or ES (PID <= 1). This is notably used to enforce filesystem permissions for requests coming from the PPC (PID 15), or to keep some resource managers and ioctls/ioctlvs internal to IOS itself. The UID assigned to PPCBOOT is identical to that listed in /sys/uid.sys for the active title.

Each process’s UID and GID default to their PID.

Kernel

• /dev/aes
• /dev/hmac
• /dev/sha

FS

Flash Filesystem

• /dev/boot2
• /dev/flash
• /dev/fs
• Normal FS (i.e. outside /dev) calls are also sent to FFS’s message queue

ES

ETicket Services (title installation/uninstallation and security)

• /dev/es

DIP

Disc Interface (optical drive I/O, including partition management and hashtree checks)

• /dev/di

ETH

USB-Ethernet driver

• /dev/net/usbeth/top
• Uses one of the USB modules

KBD

USB Keyboard driver

• /dev/usb/kbd

KD

WiiConnect24

• /dev/net/kd/request
• /dev/net/kd/time

NCD

Network interface management

• /dev/net/ncd/manage
• /dev/net/wd/top (Yes, this is actually created by NCD, not WD)

OH0/1

USB OHCI (1.1) driver

• /dev/usb/oh0 for the external USB bus
• /dev/usb/oh1 for the internal USB bus
• IOS57, 58 and 59: the OH0 module is gone and replaced by the OHCI0 module, which seems to implement a different, internal interface, similar to /dev/usb/ehc

EHCI

Present in IOS58. This module seems to be internally used as USB 2.0 backend for /dev/usb/usb.

• /dev/usb/ehc

USB

Present in IOS57, 58 and 59. This appears to be used internally by USB frontends (VEN, HID and MSC).

• /dev/usb/usb
• Uses /dev/usb/ehc
• Uses /dev/usb/oh0

USB_VEN

Present in IOS57, 58 and 59.

• /dev/usb/ven
• Uses /dev/usb/usb

USB_HID

There are two versions of this module: v4 and v5 (based on what the GETVERSION ioctl returns). v4 is in at least IOS37 and 60, while v5 is present in IOSes which have the USB module.

• /dev/usb/hid
• Uses /dev/usb/usb in the v5 version

USB_HUB

Present in IOS57, 58, 59. Its purpose is unknown.

• /dev/usb/hub
• Uses /dev/usb/usb

USB_MSC

Present in IOS57, 58, 59. It may be used for Mass Storage.

• /dev/usb/msc
• Uses /dev/usb/usb

USB_SHARED

Only present in IOS59. It is only used by the WFSI module.

• /dev/usb/shared

WFSI

Only present in IOS59. Used for installing WFS content (?)

• /dev/wfsi
• Uses /dev/es, likely for encryption
• Uses /dev/fs
• Uses /dev/usb/shared

WFSKRN

Only present in IOS59. WFS kernel? It seems to implement some sort of filesystem and uses encryption.

• /dev/usb/wfssrv — WFS service?
• Uses /dev/es, likely for encryption
• Uses /dev/fs
• Uses /dev/usb/msc for Mass Storage

SDI

SDHCI (SD card host) driver

• /dev/sdio/slot0
• /dev/sdio/slot1

SO

TCP/IP stack (sockets)

• /dev/net/ip/top — TCP/IP Socket operations
• /dev/net/ip/bottom
• Opens /dev/net/wd/top
• Opens /dev/net/usbeth/top

SSL

SSL sockets

• /dev/net/ssl

STM

Power and LED/etc management (State Transition Manager?)

• /dev/stm/eventhook
• /dev/stm/immediate
• Opens /dev/net/kd/request

WD

High-level WLAN driver (includes Nintendo DS comms)

• /dev/net/wd/command
• /dev/listen («Indication RM»)
• Opens /dev/wl0
• Opens /dev/stm/immediate

WL

Low-level WLAN driver

• /dev/wl0
• Opens /dev/listen

?

/dev/printserver