5,579
edits
Changes
m
Added an anchor for every flaw
Line 11:
Line 11:
! Discovered by
! Discovered by
|-
|-
−| HW_BOOT0 not clear-only
+| HW_BOOT0 not clear-only {{Anchor|hw-boot0}}
| To prevent [[boot0]] from being dumped, [[boot2]] clears register HW_BOOT0 that allows the boot0 ROM to be read. However, Nintendo forgot to make this register clear-only, so simply re-enabling it allows boot0 to be dumped from 0xFFFE0000 or 0xFFFF0000 in memory.
| To prevent [[boot0]] from being dumped, [[boot2]] clears register HW_BOOT0 that allows the boot0 ROM to be read. However, Nintendo forgot to make this register clear-only, so simply re-enabling it allows boot0 to be dumped from 0xFFFE0000 or 0xFFFF0000 in memory.
| boot0 can be obtained on consoles that do not support custom boot2 installations.
| boot0 can be obtained on consoles that do not support custom boot2 installations.
Line 18:
Line 18:
| [[fail0verflow]]
| [[fail0verflow]]
|-
|-
−| DVD-Video support is inadequately protected
+| DVD-Video support is inadequately protected {{Anchor|hw-dvd}}
| While the Wii was initially meant to support DVD playback, it was scrapped to avoid needing to pay licensing fees. This support was removed in later revisions of the disc drive. However, when the [[Hardware/Hollywood_Registers|Hollywood register ahbprot]] is disabled (e.g. by [[Homebrew Channel]]), homebrew can be used to read DVDs.
| While the Wii was initially meant to support DVD playback, it was scrapped to avoid needing to pay licensing fees. This support was removed in later revisions of the disc drive. However, when the [[Hardware/Hollywood_Registers|Hollywood register ahbprot]] is disabled (e.g. by [[Homebrew Channel]]), homebrew can be used to read DVDs.
| DVDs can be read on the Wii.
| DVDs can be read on the Wii.
Line 25:
Line 25:
| tmbinc
| tmbinc
|-
|-
−| No mechanism to verify markings in GameCube disc BCA
+| No mechanism to verify markings in GameCube disc BCA {{Anchor|hw-gcbca}}
| GameCube discs are not signed; instead, they have 6 dents in the BCA region that are carefully checked by the GameCube IPL. This was done by checking for null bytes in that region, a result of the dents, and was easily bypassed by just overwriting those areas of the disc with null bytes. This was not fixed with the Wii; [[MIOS]] does the same null byte check, which makes it still accept unauthorized GameCube discs.
| GameCube discs are not signed; instead, they have 6 dents in the BCA region that are carefully checked by the GameCube IPL. This was done by checking for null bytes in that region, a result of the dents, and was easily bypassed by just overwriting those areas of the disc with null bytes. This was not fixed with the Wii; [[MIOS]] does the same null byte check, which makes it still accept unauthorized GameCube discs.
| Playing GameCube homebrew discs on Wii.
| Playing GameCube homebrew discs on Wii.
Line 34:
Line 34:
== boot0 ==
== boot0 ==
−{| class="wikitable sortable" border="1"
{| class="wikitable sortable" border="1"
|-
|-
Line 44:
Line 43:
! Discovered by
! Discovered by
|-
|-
−| Dead jump instruction after jump to panic
+| Dead jump instruction after jump to panic {{Anchor|boot0-skippanic}}
| [[boot0]] has a common panic routine that runs under a number of scenarios, one of which is when the [[boot1]] hash check fails. For unknown reasons, there is an extra jump to the normal boot1 loading code after panic returns ([[boot0/Code dump|offset FFFF04E0]]), despite panic never having any possibility of returning. It may be possible to time a voltage attack correctly to skip over the jump-to-panic instruction, allowing for certain recovery software.
| [[boot0]] has a common panic routine that runs under a number of scenarios, one of which is when the [[boot1]] hash check fails. For unknown reasons, there is an extra jump to the normal boot1 loading code after panic returns ([[boot0/Code dump|offset FFFF04E0]]), despite panic never having any possibility of returning. It may be possible to time a voltage attack correctly to skip over the jump-to-panic instruction, allowing for certain recovery software.
| Bypassing the boot1 hash check
| Bypassing the boot1 hash check
Line 62:
Line 61:
! Discovered by
! Discovered by
|-
|-
−| strncmp used to compare hashes
+| strncmp used to compare hashes {{Anchor|boot1-strncmp}}
| [[boot1]] verifies the signature of [[boot2]] before booting it, however, the [[signing bug]] is present, allowing a fake boot2 to be loaded.
| [[boot1]] verifies the signature of [[boot2]] before booting it, however, the [[signing bug]] is present, allowing a fake boot2 to be loaded.
| A custom bootloader can be installed, such as [[BootMii]].
| A custom bootloader can be installed, such as [[BootMii]].
Line 69:
Line 68:
| tmbinc
| tmbinc
|-
|-
−| HW_BOOT0 is not cleared until boot2
+| HW_BOOT0 is not cleared until boot2 {{Anchor|boot1-nolock}}
| When the Wii boots, boot2 clears HW_BOOT0 to unmap boot0 and prevent it from being dumped. However, when boot2 is replaced through the signing bug, HW_BOOT0 is not yet cleared.
| When the Wii boots, boot2 clears HW_BOOT0 to unmap boot0 and prevent it from being dumped. However, when boot2 is replaced through the signing bug, HW_BOOT0 is not yet cleared.
| Dumping of boot0
| Dumping of boot0
Line 87:
Line 86:
! Discovered by
! Discovered by
|-
|-
−| No signature checks
+| No signature checks {{Anchor|boot2-nosign}}
| Unlike [[boot1]], [[boot2]] does not check the signature of titles it launches, which means they can be freely modified.
| Unlike [[boot1]], [[boot2]] does not check the signature of titles it launches, which means they can be freely modified.
| Modifying the [[System Menu]] or System Menu [[IOS]] does not brick the system, and a custom [[MIOS]] can be loaded this way.
| Modifying the [[System Menu]] or System Menu [[IOS]] does not brick the system, and a custom [[MIOS]] can be loaded this way.
Line 107:
Line 106:
|-
|-
| Kernel
| Kernel
−| No sanity checks on arguments passed to get_kernel_flavor and get_unk_flavor
+| No sanity checks on arguments passed to get_kernel_flavor and get_unk_flavor {{Anchor|ios-flavorwrite}}
| System calls get_kernel_flavor and get_unk_flavor do not check to ensure that the pointers passed are appropriate to write to; they will write to any addresses.
| System calls get_kernel_flavor and get_unk_flavor do not check to ensure that the pointers passed are appropriate to write to; they will write to any addresses.
| If IOS code execution is gained, any address can be overwritten to some specific values by passing those addresses into get_kernel_flavor or get_unk_flavor.
| If IOS code execution is gained, any address can be overwritten to some specific values by passing those addresses into get_kernel_flavor or get_unk_flavor.
Line 115:
Line 114:
|-
|-
| Kernel
| Kernel
−| Default keys exist in the kernel binary.
+| Default keys exist in the kernel binary. {{Anchor|ios-defaultkey}}
| The Wii includes an [[Hardware/OTP|OTP]] bank of memory, which contains securely stored keys. However, IOS includes a copy of these keys, which it falls back to if the OTP keys are missing. Because these keys are identical, the OTP keys can easily be extracted from the IOS kernel binary if it is dumped.
| The Wii includes an [[Hardware/OTP|OTP]] bank of memory, which contains securely stored keys. However, IOS includes a copy of these keys, which it falls back to if the OTP keys are missing. Because these keys are identical, the OTP keys can easily be extracted from the IOS kernel binary if it is dumped.
| Most OTP keys can be obtained.
| Most OTP keys can be obtained.
Line 123:
Line 122:
|-
|-
| ES
| ES
−| Trucha bug
+| Trucha bug {{Anchor|ios-strncmp}}
| The Wii used the strncmp function to check signatures, which always stopped at the first null byte, weakening the security. More information can be found at [[signing bug]].
| The Wii used the strncmp function to check signatures, which always stopped at the first null byte, weakening the security. More information can be found at [[signing bug]].
| Custom titles can be installed, and fakesigned discs can be played.
| Custom titles can be installed, and fakesigned discs can be played.
Line 131:
Line 130:
|-
|-
| ES
| ES
−| [[Title]] signatures are only checked at installation time.
+| [[Title]] signatures are only checked at installation time. {{Anchor|ios-nosign}}
| NAND title signatures are checked on install, but never on launch. This means that if a title can be installed, it can be launched without further exploitation. This applies to both IOSes and apps, including the System Menu.
| NAND title signatures are checked on install, but never on launch. This means that if a title can be installed, it can be launched without further exploitation. This applies to both IOSes and apps, including the System Menu.
| One-time exploitation leads to trivial persistence.
| One-time exploitation leads to trivial persistence.
Line 139:
Line 138:
|-
|-
| ES
| ES
−| No address check in ES_GetTitles
+| No address check in ES_GetTitles {{Anchor|ios-gettitles}}
| One of the parameters of ES_GetTitles is a buffer address for the titles to be written, however, this address is not checked to ensure that it is a Broadway-accessible address. By passing an address to overwrite, the titles fetched will be placed there.
| One of the parameters of ES_GetTitles is a buffer address for the titles to be written, however, this address is not checked to ensure that it is a Broadway-accessible address. By passing an address to overwrite, the titles fetched will be placed there.
| Any address accessible from the ES module can be overwritten.
| Any address accessible from the ES module can be overwritten.
Line 147:
Line 146:
|-
|-
| ES
| ES
−| ES_DiVerify does not check the calling module
+| ES_DiVerify does not check the calling module {{Anchor|ios-esidentify}}
| ES contains no checks when ES_DiVerify is called, responding to any module that calls it. By sending this call from the [[Hardware/Broadway|Broadway]] over IPC, ES will receive this from the PPCBOOT process, and proceed normally.
| ES contains no checks when ES_DiVerify is called, responding to any module that calls it. By sending this call from the [[Hardware/Broadway|Broadway]] over IPC, ES will receive this from the PPCBOOT process, and proceed normally.
| Homebrew can identify as any title.
| Homebrew can identify as any title.
Line 155:
Line 154:
|-
|-
| ES
| ES
−| ES_AddTitleFinish does not check signatures
+| ES_AddTitleFinish does not check signatures {{Anchor|ios-importtitlefinishnosign}}
| ES_AddTitleFinish does not check the signature of the title passed to ES_AddTitleStart, as it expects the signature to be valid by that point. By changing the contents of [[:/import]] before calling ES_AddTitleFinish, any title can be installed.
| ES_AddTitleFinish does not check the signature of the title passed to ES_AddTitleStart, as it expects the signature to be valid by that point. By changing the contents of [[:/import]] before calling ES_AddTitleFinish, any title can be installed.
| Installation of any title
| Installation of any title
Line 163:
Line 162:
|-
|-
| ES
| ES
−| No out-of-bounds check when determining the common key from the [[ticket]]
+| No out-of-bounds check when determining the common key from the [[ticket]] {{Anchor|ios-anykey}}
| Korean titles have a byte that is set to 0 to use the normal common key, and 1 to use the Korean key. This value is used as an index in an array containing the locations of both common keys. However, the value is never sanity checked, so any value can be inserted.
| Korean titles have a byte that is set to 0 to use the normal common key, and 1 to use the Korean key. This value is used as an index in an array containing the locations of both common keys. However, the value is never sanity checked, so any value can be inserted.
| Arbitrary common key usage
| Arbitrary common key usage
Line 171:
Line 170:
|-
|-
| FS
| FS
−| [[:/dev/flash]] is unprotected
+| [[:/dev/flash]] is unprotected {{Anchor|ios-devflash}}
| Permission checks in IOS exist for files, but the FS module does not check for permissions when reading the raw [[Hardware/NAND|NAND]] contents. If the NAND key is obtained, the NAND can be freely modified.
| Permission checks in IOS exist for files, but the FS module does not check for permissions when reading the raw [[Hardware/NAND|NAND]] contents. If the NAND key is obtained, the NAND can be freely modified.
| Arbitrary NAND modification
| Arbitrary NAND modification
Line 179:
Line 178:
|-
|-
| DI
| DI
−| DVD access can be trivially enabled
+| DVD access can be trivially enabled {{Anchor|ios-diflags}}
| In a TMD's "access rights" field, there is a bit that controls DVD access, and code for handling DVDs. When it was decided that DVD support should not be present on the Wii, this code was not removed from IOS, and was in fact active code as well. (see hardware bug)
| In a TMD's "access rights" field, there is a bit that controls DVD access, and code for handling DVDs. When it was decided that DVD support should not be present on the Wii, this code was not removed from IOS, and was in fact active code as well. (see hardware bug)
| DVD access provided by IOS (used by [[DVDX]])
| DVD access provided by IOS (used by [[DVDX]])
Line 187:
Line 186:
|-
|-
| DI
| DI
−| Title ID in disc header is not checked against ID in [[TMD]]
+| Title ID in disc header is not checked against ID in [[TMD]] {{Anchor|ios-unsignedid}}
| On [[Wiidisc|Wii discs]], the title ID is present several times; once in the header, once in the TMD, and once in the [[ticket]]. While the latter two are coverer by a signature and therefore cannot be changed, the instance in the disc header is not, and is instead used by the [[System Menu]] to determine things such as refusing to boot the [[Wii Startup Disc]]. Although it does not make sense for this to be signed, it is nonetheless a flaw because it could have been compared to the value in the TMD.
| On [[Wiidisc|Wii discs]], the title ID is present several times; once in the header, once in the TMD, and once in the [[ticket]]. While the latter two are coverer by a signature and therefore cannot be changed, the instance in the disc header is not, and is instead used by the [[System Menu]] to determine things such as refusing to boot the [[Wii Startup Disc]]. Although it does not make sense for this to be signed, it is nonetheless a flaw because it could have been compared to the value in the TMD.
Line 197:
Line 196:
|-
|-
| STM
| STM
−| STM release bug
+| STM release bug {{Anchor|ios-stmrelease}}
| The state transition manager checks if a handle is invalid before releasing it, but forgets to actually refuse to release it if it is invalid. More information can be seen at [[STM Release Exploit]]
| The state transition manager checks if a handle is invalid before releasing it, but forgets to actually refuse to release it if it is invalid. More information can be seen at [[STM Release Exploit]]
| Control over IOS can be gained.
| Control over IOS can be gained.
Line 215:
Line 214:
! Discovered by
! Discovered by
|-
|-
−| Buffer overflow in mail parser
+| Buffer overflow in mail parser {{Anchor|menu-letterbomb}}
| When parsing a message saved to the SD Card, the Wii Message Board has a buffer overflow bug when copying the message body. By overwriting the memory allocation table this way, the next allocation address can be placed on the stack, allowing code to be returned to. [[LetterBomb]] and [[Wilbrand]] exploit this.
| When parsing a message saved to the SD Card, the Wii Message Board has a buffer overflow bug when copying the message body. By overwriting the memory allocation table this way, the next allocation address can be placed on the stack, allowing code to be returned to. [[LetterBomb]] and [[Wilbrand]] exploit this.
| Code execution in the [[System Menu]]
| Code execution in the [[System Menu]]
Line 222:
Line 221:
| [[fail0verflow]] and giantpune (independently)
| [[fail0verflow]] and giantpune (independently)
|-
|-
−| [[Twilight Hack]] check only checks one zeldaTp.dat
+| [[Twilight Hack]] check only checks one zeldaTp.dat {{Anchor|menu-tpone}}
| The savefile check to prevent Twilight Hack returns after checking one zeldaTp.dat. By placing a legitimate zeldaTp.dat somewhere else in the file, the real zeldaTp.dat can bypass the check.
| The savefile check to prevent Twilight Hack returns after checking one zeldaTp.dat. By placing a legitimate zeldaTp.dat somewhere else in the file, the real zeldaTp.dat can bypass the check.
| A new version of the Twilight Hack works.
| A new version of the Twilight Hack works.
Line 229:
Line 228:
| tmbinc and {{User|tehpola}}
| tmbinc and {{User|tehpola}}
|-
|-
−| [[Twilight Hack]] check allows all unaligned zeldaTp.dat sizes
+| [[Twilight Hack]] check allows all unaligned zeldaTp.dat sizes {{Anchor|menu-tpunalign}}
| The savefile check that prevents Twilight Hack checks the number of bytes read against the file size, aligned to 32 bytes. By leaving the size misaligned, the checker will go past it without deleting it.
| The savefile check that prevents Twilight Hack checks the number of bytes read against the file size, aligned to 32 bytes. By leaving the size misaligned, the checker will go past it without deleting it.
| The new Twilight Hack survives [[Broadway]] resets.
| The new Twilight Hack survives [[Broadway]] resets.
Line 236:
Line 235:
| tmbinc and tehpola
| tmbinc and tehpola
|-
|-
−| [[Twilight Hack]] check only looks at the last zeldaTp.dat file
+| [[Twilight Hack]] check only looks at the last zeldaTp.dat file {{Anchor|menu-tplast}}
| When fixing the 3.3 bugs in the Twilight Hack checker, Nintendo started only checking the final zeldaTp.dat found. By placing a legitimate save later in the WAD, the checker can be bypassed once again.
| When fixing the 3.3 bugs in the Twilight Hack checker, Nintendo started only checking the final zeldaTp.dat found. By placing a legitimate save later in the WAD, the checker can be bypassed once again.
| Another Twilight Hack works on 3.4.
| Another Twilight Hack works on 3.4.
Line 243:
Line 242:
| {{User|marcan}}
| {{User|marcan}}
|-
|-
−| Disc executable cache is not padded or truncated when writing a new executable over the old one
+| Disc executable cache is not padded or truncated when writing a new executable over the old one {{Anchor|menu-dumpcache}}
| For speed, every time a disc is inserted, the System Menu writes the main executable to [[:/title/00000001/00000002/data/cache.dat]]. However, overwriting the file may require relocation if the area allocated is too small, and there may be remnants of the old file if the allocated space is larger than what is needed. To prevent their repair discs (e.g. [[Check Disk for Pre-Repair Process]]) from being leaked, Nintendo inserts a normal game disc afterward, however, because this disc is almost guaranteed to not be the same size as the repair disc, remnants of the repair disc will remain on the [[Hardware/NAND|NAND]].
| For speed, every time a disc is inserted, the System Menu writes the main executable to [[:/title/00000001/00000002/data/cache.dat]]. However, overwriting the file may require relocation if the area allocated is too small, and there may be remnants of the old file if the allocated space is larger than what is needed. To prevent their repair discs (e.g. [[Check Disk for Pre-Repair Process]]) from being leaked, Nintendo inserts a normal game disc afterward, however, because this disc is almost guaranteed to not be the same size as the repair disc, remnants of the repair disc will remain on the [[Hardware/NAND|NAND]].
| Partial dumping of repair disc executables after the console returns to the consumer
| Partial dumping of repair disc executables after the console returns to the consumer
Line 250:
Line 249:
| {{User|bushing}}
| {{User|bushing}}
|-
|-
−| Icon.bin in [[content.bin]] is not verified
+| Icon.bin in [[content.bin]] is not verified {{Anchor|menu-unsignedbanner}}
| Channels stored on the SD card have their banner icon.bin stored outside of the main WAD for convenience. This section is not covered by any signature, which allows a hacked banner to be used without illegal keys.
| Channels stored on the SD card have their banner icon.bin stored outside of the main WAD for convenience. This section is not covered by any signature, which allows a hacked banner to be used without illegal keys.
| Custom banners on SD channels
| Custom banners on SD channels
Line 268:
Line 267:
! Discovered by
! Discovered by
|-
|-
−| strncmp used to compare hashes
+| strncmp used to compare hashes {{Anchor|bc-strncmp}}
| [[BC]] verifies the signature of [[boot2]] before booting it, however, the [[signing bug]] is present, allowing a fake boot2 to be loaded.
| [[BC]] verifies the signature of [[boot2]] before booting it, however, the [[signing bug]] is present, allowing a fake boot2 to be loaded.
| If a fakesigned boot2 is installed, GameCube mode will launch it fine.
| If a fakesigned boot2 is installed, GameCube mode will launch it fine.
Line 286:
Line 285:
! Discovered by
! Discovered by
|-
|-
−| Memory not cleared before booting GC game
+| Memory not cleared before booting GC game {{Anchor|mios-tweezer}}
| When [[MIOS]] loads a GameCube game, it never clears the 48MB of memory that the game should not have access to. By using a pair of [[Tweezer Attack|tweezers]] to change the address lines, the entire memory can be dumped.
| When [[MIOS]] loads a GameCube game, it never clears the 48MB of memory that the game should not have access to. By using a pair of [[Tweezer Attack|tweezers]] to change the address lines, the entire memory can be dumped.
| MIOS and the rest of memory can be dumped using GameCube homebrew.
| MIOS and the rest of memory can be dumped using GameCube homebrew.
Line 293:
Line 292:
| tmbinc
| tmbinc
|-
|-
−| Default keys are left in the binary
+| Default keys are left in the binary {{Anchor|mios-defaultkey}}
| Like IOS, MIOS falls back on a certain set of keys if it cannot locate them in OTP. These keys are usually the same as the OTP ones, providing easy extraction when dumping MIOS through the Tweezer Attack.
| Like IOS, MIOS falls back on a certain set of keys if it cannot locate them in OTP. These keys are usually the same as the OTP ones, providing easy extraction when dumping MIOS through the Tweezer Attack.
| Internal encryption keys can be dumped.
| Internal encryption keys can be dumped.
Line 300:
Line 299:
| tmbinc
| tmbinc
|-
|-
−| No [[boot2]] signature check
+| No [[boot2]] signature check {{Anchor|mios-nosign}}
| When the power button is pressed in GameCube mode, MIOS loads boot2 in a shutdown state. However, it has no signature verification, so it is easy to reboot into software such as [[BootMii]] this way.
| When the power button is pressed in GameCube mode, MIOS loads boot2 in a shutdown state. However, it has no signature verification, so it is easy to reboot into software such as [[BootMii]] this way.
| The Wii will not hang on shutdown from MIOS if a custom boot2 is installed.
| The Wii will not hang on shutdown from MIOS if a custom boot2 is installed.
Line 307:
Line 306:
| Everyone
| Everyone
|-
|-
−| Homebrew disc blocker only checks title GNHE
+| Homebrew disc blocker only checks title GNHE {{Anchor|mios-gnhe}}
| To prevent Datel's discs from being played, [[3.0]] updates MIOS to ensure the [[apploader]] behavior of any disc with title ID GNHE is normal. Because this check only exists for title GNHE, although it could have applied for all discs, Datel could simply move their discs to another title ID.
| To prevent Datel's discs from being played, [[3.0]] updates MIOS to ensure the [[apploader]] behavior of any disc with title ID GNHE is normal. Because this check only exists for title GNHE, although it could have applied for all discs, Datel could simply move their discs to another title ID.
| Playing GameCube homebrew discs
| Playing GameCube homebrew discs
Line 314:
Line 313:
| Datel
| Datel
|-
|-
−| No check to prevent homebrew discs from being played by disc swap
+| No check to prevent homebrew discs from being played by disc swap {{Anchor|mios-discswap}}
| While the 3.0 update changes the GameCube IPL to check for title GNHE, and ensure the apploader behaves as expected if so, it does not ensure other discs loaded by games (multi-disc games) follow these rules. By inserting the first disc of a multi-disc game, then inserting a homebrew disc instead of the second disc when prompted, the homebrew disc will boot.
| While the 3.0 update changes the GameCube IPL to check for title GNHE, and ensure the apploader behaves as expected if so, it does not ensure other discs loaded by games (multi-disc games) follow these rules. By inserting the first disc of a multi-disc game, then inserting a homebrew disc instead of the second disc when prompted, the homebrew disc will boot.
| Using GameCube homebrew discs
| Using GameCube homebrew discs
Line 333:
Line 332:
! Discovered by
! Discovered by
|-
|-
−| No upper bound to CCB array
+| No upper bound to CCB array {{Anchor|sdk-bluebomb}}
| The Fluoride Bluetooth stack includes a function to get a CCB from an ID. This function checks whether the ID is below the lower bound, however, no upper bound is enforced.
| The Fluoride Bluetooth stack includes a function to get a CCB from an ID. This function checks whether the ID is below the lower bound, however, no upper bound is enforced.
Line 341:
Line 340:
| [[User:Fullmetal5|Fullmetal5]]
| [[User:Fullmetal5|Fullmetal5]]
|-
|-
−| No size limit to BigInts in Opera
+| No size limit to BigInts in Opera {{Anchor|sdk-str2hax}}
| In Opera, the dtoa module includes a number of functions operating on big integers with a maximum size, however, any sizes passed in are never checked. By passing in a value too large, the BigInt allocation table will return a smaller BigInt, which leads to a buffer overflow.
| In Opera, the dtoa module includes a number of functions operating on big integers with a maximum size, however, any sizes passed in are never checked. By passing in a value too large, the BigInt allocation table will return a smaller BigInt, which leads to a buffer overflow.
| PPC code execution (used in [[str2hax]])
| PPC code execution (used in [[str2hax]])
Line 347:
Line 346:
| [[User:Fullmetal5|Fullmetal5]]
| [[User:Fullmetal5|Fullmetal5]]
|-
|-
−| Use-after-free in Flash objects
+| Use-after-free in Flash objects {{Anchor|sdk-flashhax}}
| Flash includes a feature to watch certain properties and get notified when they change, with the ability to easily change it again by returning a value from the event handler. If the event handler decides to delete the object holding that property, the caller still sets the value at that address.
| Flash includes a feature to watch certain properties and get notified when they change, with the ability to easily change it again by returning a value from the event handler. If the event handler decides to delete the object holding that property, the caller still sets the value at that address.