So, on new Atmosphere version we wont need to wait for new patch but wait while someone updates autoips. The same shit.
If you care to read back the entire thread - I already stated that since Atmosphere 12 and above the byte pattern this uses for hasn't changed, so the scripts work on every version that's been releases since then + probable future versions. Once the byte pattern changes (which could be the next version - or not until version 16 or whatever), the script can easily be modded to accommodate for this. As the one of the scripts extracts the loader, and it's decompressed - it's trivial where to find (if needed) any new byte pattern.
Now I get this info is above some people's knowledge or understanding - if you are one of those people, just don't download this - and wait for someone else to upload a patch for you.
Loader patterns have been the same since version 12, this script finds the location automatically and writes a patch based on the address it's found at. As I said in my previous post - if it doesn't work for you - use alternative options.
You need to properly explain in bold & red in the first post that it WON'T WORK with the future versions of Atmosphere's loader — without modifying your scripts.
For now it's a purely misleading many users.
Meh.
Last edited by mathew77,
It's a pretty neat utility, but again things could ( and will ) change overtime. This could be as soon as the next AMS release, or much much later, so nothing is 100% guaranteed when generating such patches.
The Python script can be easily modified to account for newer byte patterns when they come, so it's as adaptable as it can be.
I'm aware of that, however, "finding" the new pattern is what usually takes the most effort, not adding it to a Python script.
It takes me about 20 seconds to find a new byte pattern - as the scripts already extract and decompress the loader and show the sha256 - this is making the job much faster, the uncompressed loader can then be loaded into IDA and new bytes & address found quickly. Once the pattern changes, I'll add them to the script - it's not an issue.
That could be the case "if" no drastic changes are made to the loader, finding the new byte offset and applying the same assembly code is very easy. But when new changes are introduced, the current assembly code done through IPS patching will most probably become obsolete, and things wouldn't be as simple as basically finding the new "bytes & address", it'd be slightly more complicated than that. I really hope that no major changes would be made into the loader so we can keep using the currently known patterns, and ofcourse having multiple solutions to any single problem is always healthy, and thanks for sharing your tool.
Last edited by masterchan777,
Well yes it could, we can all speculate about what's going to happen in the future - but when the future comes we can and will adapt and mostly we find all the speculation was quite wrong.
Dude, everything can be patched, You make it seem as if having a slightliest different code in loader will screw everything up.
It's nothing that complicated, it'll just be a matter of finding the code that changes and modifying accordingly, it's exactly finding new "bytes and addresses".
Also, don't forget we can also compile loader with the sigpatches reenabled from source (since Atmos disables them purposefully), so doing that could give a hint at whatever the new code that needs changing is.
It's not rocket science, but certainly not easy for those unfamiliar with actual RE and debugging.
Everything can be easily modified with the proper efforts, it's not about that.
The only wrong thing is that it claims that it's 'automatically creating', 'just', 'with no issues', 'simple' and all purely hassle like that, but in reality it is not compatible with the next modification of new AMS loader without script's modification and finding new bytes addresses using the IDA.
The only wrong thing is that it claims that it's 'automatically creating', 'just', 'with no issues', 'simple' and all purely hassle like that, but in reality it is not compatible with the next modification of new AMS loader without script's modification and finding new bytes addresses using the IDA.
Last edited by mathew77,
Ummm yes it is automatically creating them? That's what a script is for, to automate things.
And no one can know if this will be compatible with the nect release or not.
It could be a bug fix and don't change loader at all, like the last versions ave, or it could be the awaited 1.0 release and change, or not touch loader, no one can know.
The script works for Atmos releases currently up to the past two major versions.
If anything changes in upcoming ones, it will be updated accordingly.
Having this script would also be a good workaround for Nintendo going after sigpatches repos.
Where it's mentioning in the OP's post?
It's not magically updating, one must use IDA to find bytes array addresses and manually update the scripts.
And.. Where its's mentioning in the OP's post?
There's absolutely 0 of this important info in the OP's post.
All it has is 'automatically creating', 'just', 'with no issues', 'simple' and all the same crap.
Last edited by mathew77,
Also in IDA - it's easy to find where to patch, for example this is the decompiled loader - just changing this byte causes the instruction to compare 2 values and gives a result - if the result is false - we skip the sig check...
That's how the patches work - and that's why it's easy to automate things :-)
That's how the patches work - and that's why it's easy to automate things :-)
Similar threads
- No one is chatting at the moment.
-
-
-
@
Psionic Roshambo:
One thing that just occurred to me.... The sound on the 2600 sucked less back then the harsh sound we hear now is from infinitely better speakers we have now, back when the 2600 was new speakers produced a almost muffled sound, like CRTs made old graphics look slightly better. -
@
Psionic Roshambo:
I wonder if I could recommend that to some emulation devs that perhaps the sound could use some smoothing out to simulate those old TVs
-
@
Psionic Roshambo:
I think a few of the early systems could benefit from that, at least up to the 8 bit generation, by the 16 bit generation I think TVs had gotten a lot better in almost every way
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
it says it only works for the original R4, R4i Gold (r4ids.cn), R4iDSN (r4idsn.com) and Acekard R.P.G. -
-
-
-
-
-
@
Psionic Roshambo:
Just give it a try, but honestly if you have a 3DS you can play DS games without a card just off the internal SD card
-
-
-
-
