Homebrew WIP SXPD - Switch eXecutable Patch Delta, a new file format for exe patching + a patch utility.

[Slattz]

2047 Mb max for the target file, the individual internal IPS patches are supposed to be less than 7.99 Mb (Not sure why that would make a difference though), and if its that realistic I can easily make an app for ips files, heck I'll start working on it now .

Hmm, I didn't know there was a 16mb limitation. So I actually doubt atmosphere will use it, considering alot of switch files would probably be around that or even bigger.

 

[JordantheBuizel]

Hmm, I didn't know there was a 16mb limitation. So I actually doubt atmosphere will use it, considering alot of switch files would probably be around that or even bigger.

This is the format specification Luma3ds used https://zerosoft.zophar.net/ips.php
Again I'm not sure why usually IPS only supports files <= 16 Mb, but I haven't looked into it much. It probably has to do with integer type used for offset pointers in the format.

 

[SimonMKWii]

So, erm, why make a new file patching format when .ips exists? Sure theres somes benefits like the hash, but you could literally just apply the patch to the exefs using countless tools. Plus, if atmosphere's layeredfs will be anything like luma3ds's, surely it'll support .IPS too, making the patches easily future proof?

IPS is an extremely outdated format, not to mention that the EOF marker (454f46) happens to be the offset where the swim speed float is defined in Mario Odyssey...

 

[JordantheBuizel]

IPS is an extremely outdated format, not to mention that the EOF marker (454f46) happens to be the offset where the swim speed float is defined in Mario Odyssey...

The EOF bug can be easily avoided if you pay attention to the current read location of your stream.

E.g.
If "EOF" is read and current position is less than the length of the stream minus three, continuing reading.

 

[SimonMKWii]

The EOF bug can be easily avoided if you pay attention to the current read location of your stream.

E.g.
If "EOF" is read and current position is less than the length of the stream minus three, continuing reading.

You shouldn't need a workaround, that's why my format defines the number of listings in the header.

 

[JordantheBuizel]

You shouldn't need a workaround, that's why my format defines the number of listings in the header.

From what I see in a hex editor, you claim your file is supposed to be read in little endian, but then you use 0x110000 to define, correct me if I'm wrong, 11? Plus that isn't really a workaround, that's the way you should read any binary file.

 

[SimonMKWii]

From what I see in a hex editor, you claim your file is supposed to be read in little endian, but then you use 0x110000 to define, correct me if I'm wrong, 11? Plus that isn't really a workaround, that's the way you should read any binary file.

No, it's 0x00000011 to define 17, the number is in hexadecimal.

 

[JordantheBuizel]

No, it's 0x00000011 to define 17, the number is in hexadecimal.

at 0x50 to the end of the file, 0xD7, length of 88, as your specifications say each patch instruction is 8 bytes long, that seems to equal 11. Also reading bytes 00 00 00 11 that way is Big Endian.

 

[SimonMKWii]

at 0x50 to the end of the file, 0xD7, length of 88, as your specifications say each patch instruction is 8 bytes long, that seems to equal 11. Also reading bytes 00 00 00 11 that way is Big Endian.

0x88 = 0x8 * 0x11

 

[JordantheBuizel]

0x88 = 0x8 * 0x11

My bad I changed to HxD recently and I'm not sure where decimal lengths are, still though why are you reading header length in Big Endian?

 

[SimonMKWii]

My bad I changed to HxD recently and I'm not sure where decimal lengths are, still though why are you reading header length in Big Endian?

The whole file (apart from the magic numbers ofc) is currently in big endian coz it's easier to make in HxD, once I finish the maker portion of the app, I will rewrite the patcher portion to use little-endian.

 

[JordantheBuizel]

The whole file (apart from the magic numbers ofc) is currently in big endian coz it's easier to make in HxD, once I finish the maker portion of the app, I will rewrite the patcher portion to use little-endian.

I think its silly to mix endian formats without reason, especially when you are using .Net Framework which uses little endian exclusively in its BinaryReaders and BinaryWriters. SFML uses both Big Endian and Little Endian in packets, but that's because the implement their own primitive types to ensure the lengths of types when creating packets.

 

[SimonMKWii]

I think its silly to mix endian formats without reason, especially when you are using .Net Framework which uses little endian exclusively in its BinaryReaders and BinaryWriters. SFML uses both Big Endian and Little Endian in packets, but that's because the implement their own primitive types to ensure the lengths of types when creating packets.

The reason is convenience (and a little bit of laziness)

 

[JordantheBuizel]

This is an LE (little-endian) file format.

Why did you say this then?

 

[SimonMKWii]

Why did you say this then?

It will be one... eventually...

 

[JordantheBuizel]

You also claim if people follow that format and use it with your app it would work. Isn't that also false?

 

[SimonMKWii]

You also claim if people follow that format and use it with your app it would work. Isn't that also false?

No, it's true, if they follow the format it works fine

 

[JordantheBuizel]

No, it's true, if they follow the format it works fine

So you're telling me if someone reads/writes this file in little endian that it will just work? From what I can tell your entire file uses big endian. SHA256 is endian-agnostic, strings are as well, all your offsets are in "hex" which is big endian, your length and ARM instructions are as well. Also "BEGINDAT" is not in GodMode, instead it reads "ODYSSEY", is "BEGINDAT" interchangeable?

 

[SimonMKWii]

So you're telling me if someone reads/writes this file in little endian that it will just work? From what I can tell your entire file uses big endian. SHA256 is endian-agnostic, strings are as well, all your offsets are in "hex" which is big endian, your length and ARM instructions are as well. Also "BEGINDAT" is not in GodMode, instead it reads "ODYSSEY", is "BEGINDAT" interchangeable?

Well, if they were to follow all the instructions except the little-endian bit
Also, BEGINDAT is just padding data, not actually parsed (not necessary, data always starts at 0x50), so you can put whatever you want there, in this case I added "ODYSSEYH"

 

[JordantheBuizel]

Well, if they were to follow all the instructions except the little-endian bit
Also, BEGINDAT is just padding data, not actually parsed (not necessary, data always starts at 0x50), so you can put whatever you want there, in this case I added "ODYSSEYH"

I think, especially with something cool like this, people would appreciate it if you were as clear as possible with setting the files up.