Hacking RELEASE AutoIPS sig Patcher

[masagrator]

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.

 

[duckbill007]

So, on new Atmosphere version we wont need to wait for new patch but wait while someone updates autoips. The same shit.

 

[mrdude]

So, on new Atmosphere version we wont need to wait for new patch but wait while someone updates autoips. The same shit.

No.

 

[mathew77]

No.

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?..

 

[mrdude]

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?..

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.

 

[mathew77]

Once the byte pattern changes (which could be the next version - or not until version 16 or whatever)

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.

 

[mrdude]

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.

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.

 

[mathew77]

It's simple to use

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.

only 1 byte is modded in the loader, so you shouldn't get any issues.

For now it's a purely misleading many users.

Meh.

 

[masterchan777]

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.

 

[ShadowOne333]

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.

 

[masterchan777]

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.

 

[mrdude]

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.

 

[masterchan777]

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.

 

[mrdude]

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.

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.

 

[ShadowOne333]

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.
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.

 

[mathew77]

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.

 

[masterchan777]

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.

Nope, that's not how AMS loader works afaik.

 

[ShadowOne333]

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.

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.

 

[mathew77]

The script works for Atmos releases currently up to the past two major versions.

Where it's mentioning in the OP's post?

If anything changes in upcoming ones, it will be updated accordingly.

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?

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.

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.

 

[mrdude]

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 :-)