Man I wish they open sourced some more stuff, like their older NFS games...
But no joke, EA's open source stuff is really nice and one of the few genuinely good things about them. EASTL and related stuff is genuinely useful for game developers.
True. But even in this case, the same code injection logic can apply (depending on where you make the changes). The IL itself can simply be seen as yet another platform.
A great example is Android - you can patch the .dex class files with Lucky Patcher (in cases where apktool smali changes cannot help you).
IL obfuscations may also be worked around by patching the IL code directly too, which depends on the use case again.
The gist always is - carve out a space for your own code. No matter the language, a computer program is a computer program.
Beside the games that do officially support it via modding APIs, or older games that are just naturally extensible like Unreal Engine games that ship with an editor; it is usually done by the way of code injection.
Think of code injection like a manually placed interrupt - you modify the flow of execution at some point to execute your own code.
For this, you need something known as an entrypoint - place where mod code begins executing. Usually, at the entrypoint, the mod code bootstraps itself further.
To obtain an entrypoint, you have 2 options:
On supported OSs, you can abuse dynamic library loading and make a library wrapper which masquerades as the original library. When its execution begins (on Windows this is usually very early in the importing stage, on Unix/Linux you need to swap functions), you can bootstrap your mod(s) further.
On other systems (game consoles, embedded, etc), you have to modify the game executable directly. Either via the way of memory injection of another tool or direct binary modifications. Depending on the platform, if it supports loading of libraries, you would either load your mod as a library or, if not, inject the mod elsewhere into memory (slack/unused space).
How do you figure all of this mumbo-jumbo out? Well, you use tools designed to disassemble the game binary into machine language. Most popular examples are IDA, Ghidra and Binary Ninja.
You usually won't have any information on what's what, but if you know a bit about code design of games, you come to realize that a lot of them follow similar principles/patterns (depending on the era and platform), so you can probably figure it out once you've seen a few games. Especially if the game is using the same game engines as others, then you can cross reference stuff.
However, if you're lucky, you can obtain something known as debugging symbols which have all of the information about the generated binary. Ideally, it'd be for your executable that you're working with directly, but if it's not, you can usually just cross reference it by either binary pattern matching or simple deduction (same execution flows, same data, etc). This will give you a nice map of where's what in your disassembler tool.
Thanks to standardization of binaries, ABIs (Application Binary Interfaces) usually allows you to match the types as they're defined originally and have them work directly in your bespoke code. This means, for example, that if a function takes 3 arguments, those 3 arguments will be passed in the same way (depending on its calling convention), so you can expect to receive them in your own code the same way. (This is what we call code reflection - you can reflect the game's types in your own code. If you're using the same compiler as the original, even better!)
And, ideally, you would be working with code directly and not with machine language, but some lower level stuff will need it inevitably.
Usually, in your mod source code, you would work with a library that is specifically designed for code injection. This is effectively a JIT compiler which emits machine code instructions which are needed to redirect the flow of execution to your own modded functions. (Usually is capable of memory editing and making branch instructions)
There are 2 ways to perform a code modification:
Inlined code - this means you write your own code in the middle of another game function. Usually, this is done via lower level assembly and a branch instruction to put it in. Requires decent knowledge of the target CPU to use it (to not corrupt any stack or registers)
High-level function hooks - this usually means that you interrupt a function call/branch with your own equivalent. Your equivalent function will have to do the job of the original usually, but depending on the case, you may replace it outright or simply pass the call onto the original function. Thanks to ABIs, this is possible.
With all of this being said, you need to have the knowledge being able to read machine language of CPUs. This isn't too difficult once you realize RISC CPUs are mostly very similar at a glance which helps out a lot.
But, in order to be able to read it, you have to first obtain it and, as we all know, DRMs, executable packers and anti-cheats/tampers protect this, so you may need to get your hands dirty a bit to bypass that (e.g. memory dumps). A lot of the same tricks that security researchers use in their rulebook apply to modding as well.
I hope I've explained enough. I'm aware I used a bunch of terms that may be foreign, so I hope you will get the gist at the very least.
The process to sideloading on iOS requires you to use something like AltStore and self-sign the app package (IPA) with your own Apple ID.
The signature is valid for 7 days and you can do it with up to 10 apps.
Normally you need a computer in the network with a server that communicates with the sideloading client on the device to perform the signatures, however there are workarounds to do this all on device too (just needs internet access).
Does this suck? Yes. But the reality is, I hadn't have had the need to use it. There are (mostly) niche reasons you'd do this (JIT emulation, modded apps, unapproved apps).
But to be real here, to most people this just isn't worth it. There are emulators on the App Store now too, so what's left there aren't things most people need.
Is there a bigger argument to be made here on how the need is also silenced by NOT having it easily accessible? Yes. But, do keep in mind, most people don't bother on Android today already anyway.
Plus, if something seemingly can't be terminated with that, 99% of the time it's a kernel level lockup (e.g. disk IO). At which point you only have 2 options: kill it via a kernel debugger or (the more likely scenario) perform a reboot.
Precisely. MS didn't do a very good job maintaining it for Ryzen CPUs recently, though. I remember the whole fiasco with Zen 4, when it just came out, it ran better on Windows 10 than 11.
Then, more recently, 9950X3D needs manual thread pinning to run some games better.
Like, come on... this isn't something any user should even be worried about.
But also keep in mind that "just talking to the hardware" is one hell of a reduction and oversimplification, too.
Keep in mind, these issues with Ryzen scheduling are fairly new. People yap about NT being an issue when it wasn't for many years and it still isn't even the primary issue (and it usually gets fixed by the vendors themselves in one way or another).
In fairness to Windows, the kernel and the drivers are the few of the objectively good things about it.
Neither NT nor its age are the problem. It should be a testament to how well it works for the things we're using it for today.
The problem is the userspace. The things that you interact with and see. That is what you're referring to when you mention "the format dialog". Not NT. Win32 isn't a kernel, it's an API that is used to sometimes talk to NT indirectly and give userspace functionality.
Where NT is truly starting to show its age is with things like scheduling on AMD Ryzen chips with 2 different CCDs. That is a Microsoft skill issue. Had this issue cropped up not even 10 years ago, they would've figured it out. This is what is gonna age NT. New hardware, not new software.
Not having CFW isn't the end of the world. It's a slight inconvenience having to press the button at boot and maybe sometimes randomly a game not launching.
Also, later super slims are using more modern chips and therefore are much quieter and nicer to use.
Lastly, currently there is a modchip being developed for a qCFW (quasi-CFW) which will allow for basically 99% CFW capabilities on later models anyway, so there is that going for it too.
From a glance, this is just a value parser that exports them by symbols and allows you to edit the static values from a file neatly.
I don't know how practical this is yet since I haven't seen the video, but in order for it to be more practical it needs to be easier to implement and use than other methods to accomplish tweakable values for debugging.
There are many already:
parsing a config/text file in runtime
parsing commandline args
parsing environment variables
using a debugger and a memory watch
using external tools that can edit memory
Now, not all methods are available on all platforms, but, it needs to be better than any of these methods in some way for it to have any point in using it.
Game devs often have their own frameworks that can communicate with the game via network to tweak exposed values anyway for realtime debugging. Adjust.h from what I can see requires the program to be reset on each iteration.
I'll preface this by saying that I do not follow any of these slop streamers (be it Hasan, Ethan/Hila, Destiny, etc.). I think they all suck. I'm just upset that the dog got hurt.
That being said - from my perspective and first impression I'm leaning towards this being a shock collar incident.
The "paw clipping" theory doesn't hold water to me currently. We don't know what kind of bed that is and it's not possible to determine this from the video. Maybe there is evidence that can prove this otherwise, but from what I've been reading, nobody provided anything to suggest this other than a slowmo of what we already can (or rather, cannot) see. The timing of the dog's reaction is interesting, I'll accept that, but that may as well just be a coincidence until there is something else to support it.
The "shock collar" theory looks more plausible because:
The dog has an electronic collar in the first place
Hasan's timing of doing something off-screen with his left hand also coincides with dog's reaction
Hasan's previous statements on the dog herself and alleged carelesness towards her
The mere possibility of the collar having that function is enough to make me lean towards that it actually is a shock collar. Granted, he showed the collar on stream, but that doesn't really prove us anything until he provides an exact product make and model and it being on the dog in that exact configuration as he presented it.
Besides, the collar being electronic at all is a major red flag in my opinion. If he needed to track his dog, he could easily attach an AirTag to a regular collar.
At the end, I don't care who or what it is. Just let the dog be happy. If he doesn't like having or caring for the dog, then why have it in the first place?
Man I wish they open sourced some more stuff, like their older NFS games...
But no joke, EA's open source stuff is really nice and one of the few genuinely good things about them. EASTL and related stuff is genuinely useful for game developers.
True. But even in this case, the same code injection logic can apply (depending on where you make the changes). The IL itself can simply be seen as yet another platform.
A great example is Android - you can patch the .dex class files with Lucky Patcher (in cases where apktool smali changes cannot help you).
IL obfuscations may also be worked around by patching the IL code directly too, which depends on the use case again.
The gist always is - carve out a space for your own code. No matter the language, a computer program is a computer program.
I do this quite a lot myself.
Beside the games that do officially support it via modding APIs, or older games that are just naturally extensible like Unreal Engine games that ship with an editor; it is usually done by the way of code injection.
Think of code injection like a manually placed interrupt - you modify the flow of execution at some point to execute your own code.
For this, you need something known as an entrypoint - place where mod code begins executing. Usually, at the entrypoint, the mod code bootstraps itself further.
To obtain an entrypoint, you have 2 options:
How do you figure all of this mumbo-jumbo out? Well, you use tools designed to disassemble the game binary into machine language. Most popular examples are IDA, Ghidra and Binary Ninja.
You usually won't have any information on what's what, but if you know a bit about code design of games, you come to realize that a lot of them follow similar principles/patterns (depending on the era and platform), so you can probably figure it out once you've seen a few games. Especially if the game is using the same game engines as others, then you can cross reference stuff.
However, if you're lucky, you can obtain something known as debugging symbols which have all of the information about the generated binary. Ideally, it'd be for your executable that you're working with directly, but if it's not, you can usually just cross reference it by either binary pattern matching or simple deduction (same execution flows, same data, etc). This will give you a nice map of where's what in your disassembler tool.
Thanks to standardization of binaries, ABIs (Application Binary Interfaces) usually allows you to match the types as they're defined originally and have them work directly in your bespoke code. This means, for example, that if a function takes 3 arguments, those 3 arguments will be passed in the same way (depending on its calling convention), so you can expect to receive them in your own code the same way. (This is what we call code reflection - you can reflect the game's types in your own code. If you're using the same compiler as the original, even better!)
And, ideally, you would be working with code directly and not with machine language, but some lower level stuff will need it inevitably.
Usually, in your mod source code, you would work with a library that is specifically designed for code injection. This is effectively a JIT compiler which emits machine code instructions which are needed to redirect the flow of execution to your own modded functions. (Usually is capable of memory editing and making branch instructions)
There are 2 ways to perform a code modification:
With all of this being said, you need to have the knowledge being able to read machine language of CPUs. This isn't too difficult once you realize RISC CPUs are mostly very similar at a glance which helps out a lot.
But, in order to be able to read it, you have to first obtain it and, as we all know, DRMs, executable packers and anti-cheats/tampers protect this, so you may need to get your hands dirty a bit to bypass that (e.g. memory dumps). A lot of the same tricks that security researchers use in their rulebook apply to modding as well.
I hope I've explained enough. I'm aware I used a bunch of terms that may be foreign, so I hope you will get the gist at the very least.
MacOS is just amazing in this regard. I remember accidentally having the output going to HDMI and remembering the latency being not that bad.
There is a build of Mario 64 for the PlayStation. It's pretty cool lol
pipotam
You're right.
The only decent-ish extension I know of is Sink It for Reddit. It's on App Store.
The website is still buggy as hell, though...
You do not need a dev account.
The process to sideloading on iOS requires you to use something like AltStore and self-sign the app package (IPA) with your own Apple ID.
The signature is valid for 7 days and you can do it with up to 10 apps.
Normally you need a computer in the network with a server that communicates with the sideloading client on the device to perform the signatures, however there are workarounds to do this all on device too (just needs internet access).
Does this suck? Yes. But the reality is, I hadn't have had the need to use it. There are (mostly) niche reasons you'd do this (JIT emulation, modded apps, unapproved apps).
But to be real here, to most people this just isn't worth it. There are emulators on the App Store now too, so what's left there aren't things most people need.
Is there a bigger argument to be made here on how the need is also silenced by NOT having it easily accessible? Yes. But, do keep in mind, most people don't bother on Android today already anyway.
There is a third party tool called AltDrag that brings this exact thing to Windows. See if you can sneak it into your work machine somehow.
Plus, if something seemingly can't be terminated with that, 99% of the time it's a kernel level lockup (e.g. disk IO). At which point you only have 2 options: kill it via a kernel debugger or (the more likely scenario) perform a reboot.
Precisely. MS didn't do a very good job maintaining it for Ryzen CPUs recently, though. I remember the whole fiasco with Zen 4, when it just came out, it ran better on Windows 10 than 11.
Then, more recently, 9950X3D needs manual thread pinning to run some games better.
Like, come on... this isn't something any user should even be worried about.
But also keep in mind that "just talking to the hardware" is one hell of a reduction and oversimplification, too.
Keep in mind, these issues with Ryzen scheduling are fairly new. People yap about NT being an issue when it wasn't for many years and it still isn't even the primary issue (and it usually gets fixed by the vendors themselves in one way or another).
In fairness to Windows, the kernel and the drivers are the few of the objectively good things about it.
Neither NT nor its age are the problem. It should be a testament to how well it works for the things we're using it for today.
The problem is the userspace. The things that you interact with and see. That is what you're referring to when you mention "the format dialog". Not NT. Win32 isn't a kernel, it's an API that is used to sometimes talk to NT indirectly and give userspace functionality.
Where NT is truly starting to show its age is with things like scheduling on AMD Ryzen chips with 2 different CCDs. That is a Microsoft skill issue. Had this issue cropped up not even 10 years ago, they would've figured it out. This is what is gonna age NT. New hardware, not new software.
Wow someone finally made a Yu-Gi-Oh community here. Nice!
Not having CFW isn't the end of the world. It's a slight inconvenience having to press the button at boot and maybe sometimes randomly a game not launching.
Also, later super slims are using more modern chips and therefore are much quieter and nicer to use.
Lastly, currently there is a modchip being developed for a qCFW (quasi-CFW) which will allow for basically 99% CFW capabilities on later models anyway, so there is that going for it too.
Super slims are a hidden gem imo
From a glance, this is just a value parser that exports them by symbols and allows you to edit the static values from a file neatly.
I don't know how practical this is yet since I haven't seen the video, but in order for it to be more practical it needs to be easier to implement and use than other methods to accomplish tweakable values for debugging.
There are many already:
Now, not all methods are available on all platforms, but, it needs to be better than any of these methods in some way for it to have any point in using it.
Game devs often have their own frameworks that can communicate with the game via network to tweak exposed values anyway for realtime debugging. Adjust.h from what I can see requires the program to be reset on each iteration.
My yugioh brain defaulted to D.D. Crow lmao
In this instance, I used "slop" to describe those streamers because that's what I actually see them as - sloppy.
Or would you prefer for me to use a different adjective? I could use "uninteresting" or "annoying" or even "lazy" for a good number of those.
I'll preface this by saying that I do not follow any of these slop streamers (be it Hasan, Ethan/Hila, Destiny, etc.). I think they all suck. I'm just upset that the dog got hurt.
That being said - from my perspective and first impression I'm leaning towards this being a shock collar incident.
The "paw clipping" theory doesn't hold water to me currently. We don't know what kind of bed that is and it's not possible to determine this from the video. Maybe there is evidence that can prove this otherwise, but from what I've been reading, nobody provided anything to suggest this other than a slowmo of what we already can (or rather, cannot) see. The timing of the dog's reaction is interesting, I'll accept that, but that may as well just be a coincidence until there is something else to support it.
The "shock collar" theory looks more plausible because:
The mere possibility of the collar having that function is enough to make me lean towards that it actually is a shock collar. Granted, he showed the collar on stream, but that doesn't really prove us anything until he provides an exact product make and model and it being on the dog in that exact configuration as he presented it.
Besides, the collar being electronic at all is a major red flag in my opinion. If he needed to track his dog, he could easily attach an AirTag to a regular collar.
At the end, I don't care who or what it is. Just let the dog be happy. If he doesn't like having or caring for the dog, then why have it in the first place?
Wii U
Except for CTR Nitro Fueled. I'm still annoyed that there's no PC port of it.