The-Homebrew-Cloud/fusee-launcher
2
0
Fork 0
mirror of https://github.com/Qyriad/fusee-launcher.git synced 2024-11-22 02:19:17 +01:00
Code Issues Packages Projects Releases Wiki Activity

Remove trailing whitespace

Browse Source
This commit is contained in:
Josh Holland 2018-04-23 18:16:27 +01:00 committed by Mikaela Szekely
parent afe5aa04ac
commit 21a30bbf41
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
fusee-launcher.py
View File

@ -434,7 +434,7 @@ print("Found a Tegra with Device ID: {}".format(device_id))
# Prefix the image with an RCM command, so it winds up loaded into memory
# at the right location (0x40010000).
# Use the maximum length accepted by RCM, so we can transmit as much payload as
# Use the maximum length accepted by RCM, so we can transmit as much payload as
# we want; we'll take over before we get to the end.
length = 0x30298
payload = length.to_bytes(4, byteorder='little')

10
report/fusee_gelee.md
View File

@ -139,7 +139,7 @@ while (1) {
// Handle the received and validated command.
// For a "load miniloader" command, this sanity checks the (validated)
// miniloader image and takes steps to prevent re-use of signed data not
// miniloader image and takes steps to prevent re-use of signed data not
// intended to be used as an RCM command.
rcm_handle_command_complete(...);
}
@ -199,7 +199,7 @@ while (total_rxd < total_to_rx) {
}
}
/* copy any data _past_ the command into a separate payload
/* copy any data _past_ the command into a separate payload
buffer at 0x40010000 */
/* -code omitted for brevity - */
@ -244,7 +244,7 @@ data that should be included in the response. Per the specification, the device
should respond with either the *amount of data specified* or the *amount of data
available*, whichever is less.
The bootloader's implementation of this behavior is conceptually implemented as
The bootloader's implementation of this behavior is conceptually implemented as
follows:
```C
@ -298,7 +298,7 @@ respond_to_control_request(dma_buffer, length_to_send);
In most cases, the handler correctly limits the length of the transmitted
responses to the amount it has available, per the USB specification. However,
in a few notable cases, the length is *incorrectly always set to the amount
in a few notable cases, the length is *incorrectly always set to the amount
requested* by the host:
* When issuing a `GET_CONFIGURATION` request with a `DEVICE` recipient.
* When issuing a `GET_INTERFACE` request with a `INTERFACE` recipient.
@ -408,7 +408,7 @@ careful sequence of interactions:
6. If the next write would target the lower DMA buffer, issue another write
of a full 0x1000 bytes to move the target to the upper DMA buffer, reducing
the total amount of data to be copied.
7. Trigger the vulnerable memcpy by sending a `GET_STATUS` `IN` control
7. Trigger the vulnerable memcpy by sending a `GET_STATUS` `IN` control
request with an `ENDPOINT` recipient, and a length long enough to smash the
desired stack region, and preferably not longer than required.