Support Center

VMware ThinApp imtwain#.ocx

Rick Bankers Jan 11, 2012 03:04PM EST

I spoke to someone from your technical support about a month ago in regards to imtwain#.ocx. You provided me testtwain.exe utility to test the imtwain8.ocx file and it works. We've been working with the vmware developers and we've identified a possible bug in the imtwain8.ocx. Is it possible to contact someone that we could explain what we've found?

Thanks,
Rick Bankers

2 Data Techniques Responses and 1 Community Responses

Up 1 Rated Down
DTI Support  Data Techniques Employee Jan 11, 2012 03:07PM EST

Hello,
I would suggest starting by emailing us at support@data-tech.com with your info and we can take it from there.

Thanks for your interest in our products and please let us know if you have any questions.

Sincerely,
John Davis
Data Techniques Support

Up -1 Rated Down
Rick Bankers  Data Techniques Employee Jan 11, 2012 05:01PM EST

I worked with Sean on an issue related to imtwain#.ocx and VMware Thinapp. We have an application which uses imtwain8.ocx to call a twain scanner. When we packaged this application using VMware ThinApp the scanner we were using didn't function. I worked with VMware and their thinapp developers and they discovered a possible bug in the imtwain8.ocx. I can't speak to the details because I don't understand it but they documented the issue which is below. They also indicated this could also be a security issue. Details on the possible bug are below:

In the case of the Fujitsu scanner without ThinApp, I observed this sequence of events.
NOTE: The Fujitsu calls occur from Twain_32!TwCallDataSourceEntry and the numbers are the parameters to the scanner driver.
1. ImTwain8.ocx makes internal function call from ImTwain8.ocx+0xE33B to function @ ImTwain8.ocx+0xF2A0
a. Call from ImTwain8.ocx+0x8E60 results in the following events:
i. Fujitsu(1, 3, 401) (Driver startup/load call?)
ii. Fujitsu(1, 1, 1) (Initialize?)
iii. ImTwain8.ocx initializes internal stack variable/object to 0xB. The initialization occurs @ ImTwain8.ocx+0xC220
b. After return, code @ ImTwain8.ocx+0x8E78 checks to see that [esp+0x98]==0xB (Initialization was above in step 1.a.iii)
c. If stack variable==0xB, then the following events occur:
i. Fujitsu(1, 1, 6) (Attempt to scan? Returns 0 for failure. Associated message is “Twain call was out of sequence. Make sure to call CloseSource(). Reported Current State = 4”)
d. Function returns to parent. Note that variable initialized in 1.a.iii is now out of scope.
2. Second call from ImTwain8.ocx+0xE33B to ImTwain8.ocx+0xF2A0
a. Call from ImTwain8.ocx+0x8E60 results in the following events:
i. Fujitsu(1, 1, 1) (Second initialize attempt?)
ii. After the second initialization attempt, the ImTwain.ocx module does NOT initialize the stack variable to 0xB even though it went out of scope in 1.d
iii. Fujitsu(1, 8, 1)
b. After return, code @ ImTwain8.ocx+0x8E78 checks to see that [esp+0x98]==0xB. Fortunately, the stack was not overwritten after the return in 1.d, so it still does. This is just a lucky break and represents a potential bug/security flaw – depending on the environment.
c. If stack variable==0xB, then the following events occur:
i. Fujitsu(1, 1, 6) (Successful scan returns 1)
With ThinApp, the process breaks in 2.b since the stack space has been overwritten by new data. Since the variable is not re-initialized, the stack variable != 0xB and the second scan attempt is skipped altogether.

Although ThinApp is causing the additional stack growth, there are other things that would more-than-likely trigger this same bug eventually, including:
1. OS Upgrade
2. OS Patch
3. Utility that installs COM/Wndow hooks
4. New version of Epic

Up -3 Rated Down
DTI Support  Data Techniques Employee Jan 12, 2012 09:21AM EST

Hello Rick,

I have passed this on to the dev team for their review.

Thanks,
Sean

This question is closed to new answers.

Contact Us