Patch* it's creating only loader patch.Does this mean we don't need to download the patches separately and put them on the SD card?
Patch* it's creating only loader patch.Does this mean we don't need to download the patches separately and put them on the SD card?
No.So, on new Atmosphere version we wont need to wait for new patch but wait while someone updates autoips. The same shit.
You mean, the loader will stay the same as it is for now, so there's no need to update AutoIPS when the future builds of AMS will come?..
You mean, the loader will stay the same as it is for now, so there's no need to update AutoIPS when the future builds of AMS will come?..
So we don't know the pattern of that loader's updates exactly? What a shame.Once the byte pattern changes (which could be the next version - or not until version 16 or whatever)
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.So we don't know the pattern of that loader's updates exactly? What a shame.
Looking through the history of AMS builds, it changes pretty often.
It's simple to use
only 1 byte is modded in the loader, so you shouldn't get any issues.
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.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.
I'm aware of that, however, "finding" the new pattern is what usually takes the most effort, not adding it to a Python script.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.
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.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.
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.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.
Dude, everything can be patched, You make it seem as if having a slightliest different code in loader will screw everything up.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.
Nope, that's not how AMS loader works afaik.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.
Ummm yes it is automatically creating them? That's what a script is for, to automate things.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.
Where it's mentioning in the OP's post?The script works for Atmos releases currently up to the past two major versions.
It's not magically updating, one must use IDA to find bytes array addresses and manually update the scripts.If anything changes in upcoming ones, it will be updated accordingly.
There's absolutely 0 of this important info in the OP's post.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.