AppSync Fresh Capture and maintain SHA1 hash?

[bobbovine]

I'm currently evaluating ThinApp for inclusion in our environment and have run into a head scratcher. I'd like to try out AppSync. if I under stand it correctly each "fresh" capture will have a unique SHA1 hash, understandable, but that that will force AppSync to completely redownload the updated package. here's an example:

1.) I capture Adove Reader 9.3.3 on a clean VM, configuring the AppSync parameters in the package.ini. I also backup the 9.3.3 capture.

2.) I deploy my 'ThinApp'ed' Reader 9.3.3

3.) 9.3.4 is released by Adobe and I recapture a clean install from scratch on a clean VM, maintaining PDC names.

At this point I have two different App captures with unique SHA1 hashes. If I place the update on my web server it will force a complete redownload, correct?

How do I rectify the hash differences and thus allow AppSync to correctly pull down the delta and not the completely new package?

The only thing I can think of would be to perform a "throw-away" 9.3.4 capture, compare the capture file structure/virtual registry with the original 9.3.3 package, bring the updated files/registry entries over from the 9.3.4 capture, and rebuild the updated 9.3.3 capture?

Am I way off? It seems like there should be an easier way. I don't think SBmerge would be of any help; how would I be able to apply the 9.3.4 MSP to the captured 9.3.3 install. It occurs to me that I could create a CMD.exe entry point for the original 9.3.3 and apply the 9.3.4 update via the command line, then use SBmerge. I'll try that, but again it seems like a lot of contorsions to go through. Can I assign and then maintain a pre-set SHA1 hash somehow?

Thanks!

[admin]

If you place the 9.3.4 update on your webserver, AppSync will still only download the deltas, not the complete package. When you build the application, the ThinApp build tools will break up the package into blocks and compute hashes for individual blocks. The block sizes and hashes are then stored inside the generated package.

When AppSync detects a new version, it will first download the block hashes from the server. Then, for each block it will compare the hashes of the existing blocks against the hashes of blocks on the webserver. It will only download blocks for which the hash has changed.

The tricky part is in determining block boundaries. If you're using fixed block sizes and you insert an extra single byte into the first block, the hashes of all the blocks will change, so you'd still end up downloading all blocks. So, ThinApp doesn't use fixed block sizes but uses something called a "rolling checksum" to determine when to start a new block. The effect of this is that if you insert that extra byte into the first block, the sizes of the first few blocks are adjusted (and have a different hash), but after only 2 or 3 blocks the algorithm finds the "original" block boundary again and from there on all block boundaries will be the same, resulting in blocks with identical hashes which don't have to be downloaded.

[bobbovine]

OK, so if I understand correctly I was basicly overthinking the whole process and ThinApp is smart enough to deal with the block hashes itself.

Thanks for the help/info!

[bobbovine]

OK, I take that back; I'm still missing something. I captured 9.3.3 and 9.3.4 as outlined above. Put the 9.3.4 update up on my web server and launched 9.3.3 on my machine. It did identify that there was an update, downloaded it, and it launched 9.3.4 successfully; however it pulled down the whole updated DAT file. I'm still missing something.........

Any help, and the help I've gotten so far, is GREATLY appreciated!

Thanks!

[admin]

It didn't pull down the whole updated .DAT file, it reconstructed the whole updated .DAT file, there is a difference. It did this by checking (block by block) whether a block was changed between existing and updated version. If the block was not changed, it copied it from the existing .DAT file (local copy, no network traffic involved) to the updated .DAT file. If the block was changed, it downloaded the changed block from the webserver and wrote it to the updated .DAT file.

The end result is a complete updated .DAT file, but only the changed blocks were downloaded, the unchanged blocks were copied from the old file.

[ealaqqad]

Its funny how many admin I have met with who got confused by this as it really seems downloading the full package while its only constructing it. To be honest I was fooled as well at first glance when AppSync was first released. For that I have included this in my post documenting the methods of updating VMware ThinApp packages which can be found at:

VMware ThinApp Packages Update Mechanisms

I hope this help!

Regards,

Eiad Al-Aqqad

Senior Consultant @ VMware

b: http://www.VirtualizationTeam.com

b: http://www.TSMGuru.com

[TobyFruthParson]

Our issue is related, from the standpoint of the file size/hash.  We are moving toward application whitelisting.  Everytime an app is updated, our antivirus/antimalware suite will need to add the new checksum to its allow list.

[ealaqqad]

Hi,

What antivirus scan policy are you actually using? I have documented Antivirus Best practices for VMware ThinApp on the following post, check out and see if that help you any.

VMware ThinAPP Antivirus Best Practices

I hope this help.

Regards,

Eiad Al-Aqqad

Senior Consultant @ VMware

b: http://www.VirtualizationTeam.com

b: http://www.TSMGuru.com

[TobyFruthParson]

Nice write-up.  Thanks for sharing.  The issue for us, however, is that of the checksum of the exe and dat.  Whenever they change they must be added to the application whitelist.  We'll have to run them through the antivirus system management console or poll a staging area prior to AppSync publishing.