From 21a30bbf419eb4edda0d372d2209e43cc7328ba6 Mon Sep 17 00:00:00 2001 From: Josh Holland Date: Mon, 23 Apr 2018 18:16:27 +0100 Subject: [PATCH] Remove trailing whitespace --- fusee-launcher.py | 2 +- report/fusee_gelee.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/fusee-launcher.py b/fusee-launcher.py index e99afd3..3a3a6a5 100755 --- a/fusee-launcher.py +++ b/fusee-launcher.py @@ -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') diff --git a/report/fusee_gelee.md b/report/fusee_gelee.md index df38139..1d6187f 100644 --- a/report/fusee_gelee.md +++ b/report/fusee_gelee.md @@ -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.