-
Oct 5th, 2009, 12:12 AM
#1
-
Oct 5th, 2009, 11:08 AM
#2
Re: vbPatcher - Patch your programs (for updates, etc.)
Well, I wouldn't say it couldn't be used maliciously... Any patching software could be and same can be said for many API calls (legitimate usage or not).
The following is not criticism, just a couple of points/ideas.
1. Should the difference in apps be some string value, relatively near the beginning, that changed in size (say changed from 10 chars to 11 chars). Theoretically, I would expect every byte from the change start to the end of the app will change thus making your patch file at least 2x larger (or much larger) than the app itself since you are storing the position (4 byte long), along with the changed byte for each byte that changed. The reason why all bytes could be recognized as changed is because the entire app was shifted one character with the increase/decrease of that string.
If you want to upgrade the logic, you might want to scan ahead and write total bytes changed. Example: If byte 1024 changed and the next 2048 bytes are different, instead of reading/writing one byte, write position of change, nr of changed bytes, the changed bytes. The end result will be writing just 4 bytes more than what you are doing right now (the count). Many formats use similar logic. Even if relatively few bytes changed, the additional 4 bytes shouldn't adversely increase the patch file size.
Code:
' instead of
Put intHandle, , i
Put intHandle, , bytNew(i)
' maybe
Put intHandle, , i
Put intHandle, , nrChangedBytes ' also Long value
Put intHandle, , bytNew() ' cached range of bytes
' using ReadFile/WriteFile APIs would prevent needing to ReDim to store range of bytes.
2. A more robust solution may want to deal with handling patching running exes. And possibly in-use ocxs/dlls (assuming binary compatibility wasn't broken). I think the latter may be a tall task. Especially if registration is involved and users with non-admin privileges.
3. I guess it would be possible for anti-virus software alerting on modified apps; just a thought.
4. Have you tried patching a properly "Installed" app that has an uninstall package? If so, does the unistall still uninstall the patched app? Think it would, just curious.
Last edited by LaVolpe; Oct 5th, 2009 at 11:44 AM.
-
Oct 5th, 2009, 03:56 PM
#3
Re: vbPatcher - Patch your programs (for updates, etc.)
Thanks for the tips, LaVolpe. I wrote this really quickly and this was the first way that came to mind (really oversimplified I'm sure).
Originally Posted by LaVolpe
Well, I wouldn't say it couldn't be used maliciously... Any patching software could be and same can be said for many API calls (legitimate usage or not).
I stated that so the mods would know that what's contained isn't malicious. I'm sure if people know how to crack software or something, they'd probably know how to write their own patcher also.
Originally Posted by LaVolpe
1. Should the difference in apps be some string value, relatively near the beginning, that changed in size (say changed from 10 chars to 11 chars). Theoretically, I would expect every byte from the change start to the end of the app will change thus making your patch file at least 2x larger (or much larger) than the app itself since you are storing the position (4 byte long), along with the changed byte for each byte that changed. The reason why all bytes could be recognized as changed is because the entire app was shifted one character with the increase/decrease of that string.
I didn't think of that, but it doesn't seem to always be the case. I've tested it a few times and the patch file so far hasn't come close to exceeding the original EXE size. I'm not very keen to the PE file format, so I'm not really sure how everything is stored in the EXE file.
Originally Posted by LaVolpe
If you want to upgrade the logic, you might want to scan ahead and write total bytes changed. Example: If byte 1024 changed and the next 2048 bytes are different, instead of reading/writing one byte, write position of change, nr of changed bytes, the changed bytes. The end result will be writing just 4 bytes more than what you are doing right now (the count). Many formats use similar logic. Even if relatively few bytes changed, the additional 4 bytes shouldn't adversely increase the patch file size.
Code:
' instead of
Put intHandle, , i
Put intHandle, , bytNew(i)
' maybe
Put intHandle, , i
Put intHandle, , nrChangedBytes ' also Long value
Put intHandle, , bytNew() ' cached range of bytes
' using ReadFile/WriteFile APIs would prevent needing to ReDim to store range of bytes.
That seems like a much better way, I may update it later to use that approach.
Originally Posted by LaVolpe
2. A more robust solution may want to deal with handling patching running exes. And possibly in-use ocxs/dlls (assuming binary compatibility wasn't broken). I think the latter may be a tall task. Especially if registration is involved and users with non-admin privileges.
That sounds like a good idea, but like I said, I'm not really keen with the PE file format. Definitely sounds interesting and would be fun to try, though.
Originally Posted by LaVolpe
3. I guess it would be possible for anti-virus software alerting on modified apps; just a thought.
Yeah, a lot of anti-viruses alert you when a program has changed since it last ran, I figure it would be the same if they updated/overwrote the original with an installer? Not sure...
Originally Posted by LaVolpe
4. Have you tried patching a properly "Installed" app that has an uninstall package? If so, does the unistall still uninstall the patched app? Think it would, just curious.
Haven't tried that but it's a good point. Some installers leave files alone (don't overwrite or remove) if they are different from the originals.
Thanks for the reply.
-
Dec 10th, 2009, 09:30 AM
#4
Lively Member
Re: vbPatcher - Patch your programs (for updates, etc.)
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|