As quixel is being removed, all items are free to aquire. This script is to automate the process to add items to your account (As of writing, a total of 18874 items)
Note: This script only tested in the latest version of Chrome.
run.js)| #include <assert.h> | |
| #include <stdio.h> | |
| #include <time.h> | |
| #define COBJMACROS | |
| #include <windows.h> | |
| #include <d3d11_1.h> | |
| #include <d3dcompiler.h> | |
| ////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
After the recent release of ps5-kstuff with support for PS4 fpkg files, there is a lot of questions about porting this to other firmwares (4.50 and 4.51 are important in particular, because users of those firmwares can't update to 4.03, but they are still vulnerable to all of the used exploits). The main problem with these ports it the bespoke XOM, which prevents finding the offsets by simply examining the dumps. So in this document I'm going to go over what offsets are important for ps5-kstuff, and how I found them for 4.03.
These are the main categories of offsets:
So, how tf do rust modules work? and why tf are they not doing what I want right now???
Note: A bunch of things in here are defined by cargo and a few others by rust. I won't generally care about that distinction because two languages without standard build system is more than enough for my sanity.
➡️ Feel free to ask me on twitter if you have questions or remarks.
Core concepts
| bits 64 | |
| org 0x4000000 | |
| elf_header: | |
| .size equ .end - $ | |
| .e_ident db 0x7F, 'E', 'L', 'F' ; EI_MAG0 ... EI_MAG3 | |
| db 2 ; EI_CLASS: 1 => 32 bits, 2 => 64 bits | |
| db 1 ; EI_DATA: 1 => lil endian, 2 => big " | |
| db 1 ; EI_VERSION: original version | |
| db 0 ; EI_OSABI: 0 => System V ABI |
| org 0 ; We use "org 0" so Relative Virtual Addresses (RVAs) are easy. | |
| ; This means that when we want an absolute Virtual Address we have | |
| ; to add IMAGE_BASE to the RVA (or whatever the base of that section is) | |
| IMAGE_BASE equ 0x400000 | |
| SECT_ALIGN equ 0x200 | |
| FILE_ALIGN equ 0x200 | |
| msdos_header: | |
| .magic db 'MZ' |
| package d3d11_main | |
| import D3D11 "vendor:directx/d3d11" | |
| import DXGI "vendor:directx/dxgi" | |
| import D3D "vendor:directx/d3d_compiler" | |
| import SDL "vendor:sdl2" | |
| import glm "core:math/linalg/glsl" | |
| // Based off https://gist.github.com/d7samurai/261c69490cce0620d0bfc93003cd1052 |
Modern versions of Windows support GPU paravirtualization in Hyper-V with normal consumer graphics cards. This is used e.g. for graphics acceleration in Windows Sandbox, as well as WSLg. In some cases, it may be useful to create a normal VM with GPU acceleration using this feature, but this is not officially supported. People already figured out how to do it with Windows guests though, so why not do the same with Linux? It should be easy given that WSLg is open source and reasonably well documented, right?
Well... not quite. I managed to get it to run... but not well.
This is a systematic in-depth exploration of different ways of calling functions in Roc.
In Roc, functions are values that are defined using lambda-expressions. Here are two single-argument functions on integers, one that increments a given number and another that doubles it.
inc : I64 -> I64