Use standard payload files instead of converted ones.

[lordfriky]

This will make payload updates much easier. @ElijahZAwesome once tried to work on this but he never got it working. Now, I wanted to try it by myself to see if it can be actually possible.

After a few hours I got something working, a remote payload logger, which can be found here. Source is here. For this example I'm using the Atmosphère 0.10.2 fusee-primary.bin. Please note on the images above that the bytes on the remote payload logger matches the ones from the local payload generated on web-cfw-loader, meaning that the payload was retrieved sucessfully.

Remote Payload Logger

web-cfw-loader

This *may* be implemented now, but first I want to point out some things:

• Payloads can be retrieved directly from the web server ./payload.bin or from a entire url without redirections https://raw.githubusercontent.com/AtlasNX/web-cfw-loader/master/payload.bin, but for some reason it doesn't work with local files (opening the .html directly without a local server, via file:// protocol) nor with GitHub release files (these files redirect to a AWS link and XMLHttpRequest refuses to work with it). In the first case people can simply setup a local server on their machines, but may make WebUSB refuse to work.
• The image shows that the payload was retrieved on less than a second, but in reality it takes A LOT more. I tried to run it in both my Chromebook and my recently formatted Mac and in both machines took around ~1 minute and 30 seconds.

I don't know what actually could be causing this, and if someone knows how to fix it please let me know so I can implement it properly on a PR.

[Enovale]

Glad you're making progress on this! I remember running into issues with incredibly long convert times and issues with grabbing from servers. Check the debug log and look for CORS errors, that always bites me in the butt.

[lordfriky]

Yep, I'm actually using the Chrome developer tools a lot, but every time I do the test any error is shown on the console. :b

I tried changing the XMLHttpRequest for the fetch() function but it just got somehow worse (~2 minutes and 30 seconds in my Mac), so I'm actually wondering if the issue comes from the GitHub servers from what I read... :thonk:

[lordfriky]

Nope, there’s nothing wrong with GitHub servers, Mozilla proves it.

I really don't know what is causing it, but I won’t give up. I really hope I’ll have this working sooner or later.

[AnnsAnns]

There is one solution to this that works fine, which is just to simply create a backend for this project. For now I've however tried to circumvent that, though it might be the best solution if we actually want to keep this project updated actively.

[Wiilf]

Better requesting a remote JSON response containing the byte array from the GET parameter (eg. ?payload=fusee), I didnt do this as I didnt see the point as I have 5 active payloads available at all times.

This project is very much alive since we got our hooks into the code. And many improvements in just 3 days time. I've posted a update. There is a lot you can do with this code. And we are just getting started.

[lordfriky]

Hey there! It's nice to see people still carying about the project. :)

Two weeks ago I decided to take a look back at this specific issue since I've been properly learning JS lately and finally got it working (demo), so there's no need to keep storing the byte array of the payloads.

I do also have a draft for a GitHub Action to grab the latests versions of Atmosphere and Hekate, so no manual updates to the payloads would be required ever again.

There's still a lot of stuff I want to do with this project (such as rewriting the UI with React, turning it into a PWA, etc), but collage and competitive programming are on the top of my priorities right now. If you want to help with some stuff please hit me up @ Discord, you can find me as Lord_Friky#0223.

[Wiilf]

Very neat. I tend to pick up projects and work them to public attention and usage, often improving as I go. I'm well-versed in 5 languages, so this was clearly easy. A lot of the old code was updated and reduced.

I agree, the payloads are depreciated and we are developing a C# application to do this with more options and using native namespaces rather than a third-party library (UsbK bindings). We can just use WMI for this and read the properties in most frameworks.

Funny thing about your project here is it's split across 3 different angels (their all different w/ different payloads).

Most noticeably, this JS was missing device listing and resuming altogether, so we added that along with a progressbar (also JS). Keep up the good work!

[lordfriky]

After 3 years of making this issue, I can finally close it :)

[Wiilf]

What im updating going forward is the AJAX response, and offer binary parsing and delivering that byte array over a stream. Why? Because saving these payloads from .BIN files is incredibly easy. So we just run code similar to:

<?
$binaryFilePath = 'lockpick.bin'; // example
$binaryContents = file_get_contents($binaryFilePath);
$uint8Array = 'new Uint8Array([' . implode(',', array_map(function($value) { return '0x'.str_pad(dechex($value), 2, '0', STR_PAD_LEFT); }, unpack('C*', $binaryContents))) . ']);';
echo $uint8Array; // Outputs your byte array string
?>

Which delivers this data. Now we can sample the data over on the UI, and send to textarea and/or allow saving to .BIN file before sending payload to device.

So the flexibility is 100%. While I plan serve the constant byte arrays from the JS payloads file, I will soon serve these entirely over AJAX, removing the overhead of parsing very large payloads in client-end, and let the server do the heavy lifting.

I prefer to leave as much math and internal checks as server-side as possible for obvious reasons. Makes it difficult to follow memory leaks or security holes the same way you would by viewing page source. This is critical in our platform, and reduces so much security maintenance.

---

Also, its easy to implement a multi-list of payloads uploaded/selected that reside in memory and allow you to go back and forth on as many custom byte arrays as you would like, while only allowing 1 payload to be sent at any time.

I'll be making these updates in ~3 days.