2 Attachment(s)
vbPatcher - Patch your programs (for updates, etc.)
(I don't see how this could be used maliciously)
I wrote this for someone else, but maybe someone else might find it useful.
It's a class module you can add to your projects to create patch files, and then apply them.
Example: compare 2 files, create a file containing what is different (patch file), then applying that patch file, thus making the 2 files the same (useful for updating your software instead of redistributing entire files).
I wrote it really quickly and didn't test thoroughly so let me know if you come across any bugs.
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.
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).
Quote:
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. ;)
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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...
Quote:
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. :)
Re: vbPatcher - Patch your programs (for updates, etc.)
