The problem started with writing the correct plugin code to have BestCrypt working correctly.
Monitoring carefully the installation process, I managed to find most of what I needed.
The plugin Pepak wrote for the Volume Encryption also helped a lot.

For this problem I used Windows XP SP2 as my source and BartPE 3.1.10a with VMWare Workstation 8.

FIND HERE LINK TO PLUGIN(S): http://www.mediafire.com/?qzsqkhc116426o7

Problems:

A ) A mounted container does not show correctly in the BartPE interface. Although this is likely not a problem caused by BestCrypt, it is still very annoying.
You mount a container to drive T: and this drive will not be accessible or available after mounting!
This has been reported before, but never a good solution was given!
To show the actual problem, I uploaded some pictures:

http://tinypic.com/r/30uqqgl/6
http://tinypic.com/r/4r85li/6
http://tinypic.com/r/2ai0qo5/6

I did manage to somewhat fix the problem by doing the following actions:

1. diskmgmt.msc : assigning a drive letter and formatting the drive
2. Then the following commands (in random order and numerous times):
a ) HWPnP.exe +all /p /d /a /log
b ) HWPnP.exe -all +STORAGE\VOLUME +USB\ +USBSTOR\ /a /u /p /d /log
According to http://www.911cd.net/forums/lofiversion/in...php/t15086.html :
c ) HWPnP.exe -all =ROOT\FTDISK\0000 /u
d ) Removing HKEY_CURRENT_USER\Software\Jetico\BestCrypt\MountPoint

Eventually the drive shows up in explorer and after that the problem is history, which means that all future mounted drives show up instantly in explorer (** actually when mounting a new container, BestCrypt opens the wrong drive after mounting, usually the X: drive for some reason, but other than that, everything seems to work fine).

My question is of course, what is the definite fix for this problem?

-=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=

B ) Volume Encryption gives an error at starting: “Error in loading BestCrypt Volume Encryption driver.”.
This error is given once and on a second attempt to start Volume Encryption the error disappears (which probably means that the driver is loaded this time around).
Trying to fix the error, I added the following line to the plugin:

0x7, "ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}","UpperFilters","bcfnt","PartMgr"

This was an original monitored registry entry made by BestCrypt, but it gave some issues originally, so that is why I removed it.
When putting this line back in, a new error appears: “File system guard module is not active or version of the module is incorrect. It is also possible that you have not rebooted computer after installation of the software.”.
Now I cannot start the Volume Encryption as this warning will reappear every time.
The fsh.sys driver is the guard module, but now I am confused why this driver is not giving a problem the first time around.
So maybe not a smart idea to put this line back...

Also other two registry lines added originally by BestCrypt I removed, because they were giving a conflict with the mouse and keyboard driver:
0x7, "ControlSet001\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}","UpperFilters","kbdclass","mhk"
0x7, "ControlSet001\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}","UpperFilters","mouclass","moh"

-=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=

C ) I know the syntax for adding entries to txtsetup.sif is quite difficult, so to prevent going off topic I will not ask the exact explanation of errors, but can someone validate the first part of the plugin where I attempt to add the drivers to txtsetup.sif.

Also I should add that volsnap.sys driver was already added to my BartPE setup, so that is why you will not see this driver in the plugin.

-=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=-=--=-=-=

If you need any more information, please let me know!

Looking forward to hear some feedback and hopefully some answers to the few problems I have left to make BestCrypt work perfectly inside WinPE/BartPE.

Thanks!

Not at all my field of expereince, but are you meaning that Bestcrypt has changed in the version you are using?
(which BTW should be explicited)
There was a plugin maybe for an earlier version:
http://reboot.pro/5653/
that seems to me much "simpler" than the one you referred to:
http://reboot.pro/15199/

The TXTSETUP.INF "syntax" you can get from there, just in case:
http://www.msfn.org/board/topic/125480-txtsetupsif-syntax/
http://www.msfn.org/board/topic/127677-txt...tinf-reference/

But the real question being:
Does the plug-in for BartPE released by the manufacturer jetico work or not?
http://www.jetico.com/bestcrypt-volume-enc...gin-for-bartpe/
or is it somehow "limited"?

As an experiment, you may want to try having the BartPE NOT as "X:", maybe that is part of the reason of the "confusing" drive letter (that is if you are running it from a non-CD/DVD media):
http://reboot.pro/15199/
http://reboot.pro/1938/

Most of the problems you reported seem like connected with the "upper filter" connected with "Partmgr".
Similar issues in the past were reported for a number of other softwares like - if I recall correctly - Acronis Partition thingies, it seems like they represent a "delicate" part of the Registry/whatever.


Another (completely OT question, just for my curiosity ) is: WHY the HECK do you want/need Bestcrypt?


jaclaz

Yes, this plugin was probably copied from here: http://www.jetico.com/bestcrypt-volume-enc...gin-for-bartpe/
This all relates to problem B and maybe also problem C.
I must clarify though that this plugin is intended for the Volume Encryption (this is a separate software) and not the Container Encryption.
The plugin I tried to develop is a plugin for BestCrypt 8.24 (newest) which includes both (and some more tools).

Running DriverView from Nirsoft, showed me that bcfnt.sys driver was not loaded when booting BartPE! This must be some error in my plugin code.
I already changed the following line:
0x4, "ControlSet001\Services\bcfnt","Start", 0x00000001 (changed from 0x00000000)
But still the driver is not running after boot.

Furthermore, described in the Jetico url above:
"5. Two conflicts with other BartPE plugins are detected with "Acronis TrueImage" and "Shell: XPE: Windows XPE: PnP & Multimedia v1.0.7 [Sherpya]" plugins."

Now I am using XPE at the moment, so I changed the following line to prevent the conflict:
file: xpe-pnp.inf
line: 0x7,"ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}","UpperFilters","bcfnt","PartMgr","bcfnt.sys"

**EDITED: Removed the XPE module and problem B now reports the missing driver and after a 2nd attempt it will start the Volume Encryption ( so basically the same as without the line above - see start problem B ).
Removing XPE did not have any effect on problem A though.

Also changed the same line in LOCALIZE.inf, but not sure I did this all correctly.



No, gives the exact same problem for the Volume Encryption ( problem B ).



Will give this a try as that will be changed in the main build anyway.



Yes most likely. Because it is (still) giving conflicts with XPE to begin with, this can relate to problem A. Strange is however that when I 'fix' it like I described, it will not happen afterwards, just like it then knows how to do things properly...

Actually I don't know exactly what I am doing when I added this line to the plugin:
0x7, "ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}","UpperFilters","bcfnt","PartMgr"
(and also made the changes for XPE)

Am I making sure that the normal Partmgr now also can use bcfnt.sys driver, so it can see changes when an encrypted container is mounted to a drive?
Quite sure most of the problems start here...



Clients use the software and when recovering files it is best to have the actual software in PE running. I am personally not the biggest fan, because there are other freeware solutions available that do the same imo.

When you boot your PE, can you run good ol' sc.exe?
http://ss64.com/nt/sc.html

What happens when you run it?

(please note how there is a [SPACE] after the = sign)
Like:
Is the service/driver existing/installed?
If existing, was it started? (if not attempt starting it with SC.EXE)

Try also if this thingy here:
http://p-nand-q.com/download/pserv_cpl.html
works in the PE, it sometimes provides a handy environemnt to manage drivers and services:


If a conflict is existing with XPE and you are using XPE, try NOT using it (to verify that the plugin works in "plain" BartPE) then, if this is the case there should be remaining only one issue (the compatibility with XPE) to be troubleshot and (hopefully) solved.


jaclaz

** EDITED: Earlier comments are removed because they had nothing to do with the issue...

SOLVED: Problem B is solved for 90%.

The bcftn.sys driver was not loading correctly, because it needed the volsnap.sys driver loaded just like in the Volume Encryption plugin from Jetico.

Problems remaining are:
- Drives not become visible after mounting an encrypted container (problem A)
- Still not sure if my plugin code is 100% accurate, especially the txtsetup.sif code (which initializes the drivers if I am not mistaken).

All problems start where BartPE is not having full disk support and XPE is for example using volsnap.sys and partmgr.sys and you need to 'include' also the bcfnt.sys driver from Jetico (which is also a disk driver).
The same applies for when 'including' the mkb.sys and moh.sys which are keyboard and mouse (listener) drivers, that is why when I not do this correct (and I still don't know the correct way), they conflict with the main mouse and
keyboard drivers and make them stop functioning.
Having said that, I care not much at the moment about the mouse and keyboard listeners as the software can function fine without them, but of course you want to make the plugin 100% working...

Because of the not correct 'including' of the bcfnt.sys driver (and maybe volsnap.sys and others), the drives in explorer are not showing correctly when mounting a container and when trying to fix that within PE, you get things like
all the drives suddenly disappearing and things like that.
When the bcfnt.sys driver is loaded, as I can do now, the software works perfect though, it can create new containers, even volume encryption gives no error what so ever.

Hope this all make sense and someone can help to a final version of this plugin! would be nice...

PS. Also there was a post about the not showing of encrypted drives in PE explorer (as I mentioned in my first post), but the question was never really properly answered, as they tried to use HwPnP to have the drive visible in explorer.
As I wrote before, this behavior I can copy and eventually I can make the drive appear too, but this is not what we want of course. Also, after the drive is visible, then everything keeps working fine, where any encrypted drive is shown visible instantly when mounted! So I mean, this is the behavior you want from the start (and should be possible somehow).

Thanks for thinking with me!

From what you report it seems like by "fiddling" over and over with HwPnP or whatever, you finally "trigger" the loading (or starting) of a service (or driver) and once "it" is started/created, everything works allright.

A good idea would be to run a complete dump of running services and drivers with SC when the thingy is not working, then "fiddle" with the *whatever* makes it work until you have it working, and then run another dump of SC output.
Same goes for the Registry.
By comparing the two sets it should be possible to find the "culprit".


jaclaz

Ok, done the testing, but not much wiser yet.

Find the registry changes here: http://snipurl.com/regdiff

NOTE: I have limited down the actions to make the drives visible, now all I do is:
1. HwPnP -all =ROOT\FTDISK\0000 /u (must wait few seconds or so after this)
2. HwPnP -all +STORAGE\VOLUME /u

I removed the not related lines from the registry file.

I see quite some lines related to ftdisk.sys and the service related to this. I wonder if I enter some of the lines related to the service to the plugin, might give that a try.
If you can look at the registry file and see if it all makes sense? Of course you see the entries related to the storage volume, just I don't think you can copy those into the plugin, as they are created on the fly.
So my best bet now is that it is related to the ftdisk service and that I need to add those registry lines. But maybe you can come up with other results from reading the file?

Let me know and I will report too.

Report:

Really strange, but when I start PE, mount an encrypted container, then enter the registry settings for ftdisk and volume storage (simply with .reg files), then all I need to do after is "HwPnP -all +STORAGE\VOLUME /u".
But when I enter this exact same code in the plugin.inf, then boot PE, the same command will make all drives disappear :-)

Edited: It seems to 'allocate' a 'slot' where it can mount the container, because when I create a 2nd container, it will not show, even if the 1st container is showing. You need to "HwPnP -all +STORAGE\VOLUME /u" and then wait several seconds (can be up to half a minute sometimes) before the drive will show. For a third mounting this is exactly the same and so on.
The question is, how to 'allocate' this 'slot' ? I see some lines in the registry changes, but not sure how to recreate them, also you cannot allocate slots for every upcoming mount of a container! :-)
So this must somehow be better controlled, where probably BestCrypt gives a signal that a new drive is mounted... Something like: HKU\.DEFAULT\Software\Jetico\BestCrypt\MountPointNotify but Volume Storage should also know ...

Maybe anyone can still look at the registry changes and see what I am missing!?

So far reports, now waiting again for some help, I am stuck!

Rogierel, I don't want to seem grumpier than usual , but if I ask for two dumps of a SC complete log, maybe it is because I would like to see the output of SC....

The ftdisk.sys is one of those things that (AFAIK) cannot be "manipulated" fully from a "plugin" (or by "normal" registry additions), compare with:
http://www.911cd.net/forums//index.php?showtopic=8521
so you *need* to use HWPNP, but DEVCON should be "better".

The correct reference is this one:
http://www.911cd.net/forums//index.php?sho...=7893&st=55

An alternative being either this approach:
http://www.msfn.org/board/topic/142983-dri...on-for-project/
or possibly the alter or paraglider thingies listed here:
http://www.911cd.net/forums//index.php?sho...24100&st=29



jaclaz

I don't mind grumpy people I thought using SC was more like a suggestion, not a request

But seriously, I didn't understand SC in 10 seconds, and then decided to first look at the registry changes and then later on, totally forgot about SC.
Let me first have a look at the links in your reply and then the full dump from SC will follow! PROMISED!

Ok, find here the sc log output (command run: sc query type= all state= all > file)
As far as I can see the ftdisk service is the only addition.

The commands I entered in between the BEFORE and AFTER:
hwpnp -all =ROOT\FTDISK\0000 /u
hwpnp -all +STORAGE\VOLUME /u

---

Actually, after reading your comments, I thought the easiest approach would be just to use devcon.
Now when PE boots, I simply run the following command: devcon update %systemroot%\inf\machine.inf "root\ftdisk" (as suggested in the Acronis plugin talk)
Then when a container is mounted, I simply run the following command: devcon update %systemroot%\inf\volume.inf "storage\volume"

I think this is about similar to what the hwpnp.exe command does, right?

Now, I can limit it down most likely and look at the device ID that BestCrypt is creating and if this is always starting with a certain set of characters, then I can use devcon maybe to start it?

So the FTDISK I only need to load once now, just after boot. The STORAGE\VOLUME I need to update after every mount (this 'updates' all drives, so it is still a bit too much action I feel, but ok, getting closer)

Oh yes, and I need to suppress the unsigned driver messages from devcon (best method is the plugin and executable from Peter Schlang? I can find the winbuilder script, but would be nice if there is some BartPE plugin).

EDITED: Used the DriverSigning.exe from Peter Schlang, which I found in this script to suppress the unsigned driver warning when using devcon.

Also when monitoring STORAGE\VOLUME, it seems that the new mounted drive is within the same DeviceClass (Generic Volume) and therefore, since we don't know which the mounted drive is, we need to refresh most likely all generic volumes, which are 'saved' with ClassGUID {71A27CDD-812A-11D0-BEC7-08002BE2092F} but you cannot really use devcon in combination with the ClassGUID...
So basically, with the original C: drive being: STORAGE\VOLUME\1&30A96598&... and the mounted drive also starts with: STORAGE\VOLUME\1&30A96598& but has a different signature, offset and length.
I guess you can only update STORAGE\VOLUME so explorer finds the new drive.

I think, but not sure, that if you mounted a container once, then the volume is 'cached' or something, even if you unmount, because a new mount of the same container, instantly shows the drive.
But for every new container, you need to update the STORAGE\VOLUME and I am afraid there is no way around that.

But waiting jaclaz (or any other) who might say that is not (entirely) true

Ok, to close the topic, as sometimes in PE, you must be happy with a 95% solution and this is just that!
Let me describe in short what this solution is about, if you cannot get that from the discussion above.

Jetico BestCrypt 8.xx Windows Container Encryption (and Volume Encryption) plugin:

NOTE: All Jetico products are commercial products and if you plan to use them, you must acquire a license with Jetico (www.jetico.com).
This plugin is based on the trial software, as described by Jetico: "Fully functional versions for evaluation purposes will function for 21 days".

1. The shortcut to open the program is linked to a batch file that includes the following code:
StartBC.cmd


2. When you mount an encrypted container, device, partition or disk, afterwards you need to run the following file:
Updt.bat


3. A nice trick that you can do is to convert the batch files to executables (a nice tool for this can be found here).
Then you can rename the Updt.exe (converted from Updt.bat) to BCUpdt.exe (that is the actual name of the Automatic Update Application from Jetico).
Replace the original with your update tool and you can now refresh STORAGE\VOLUME from within the BestCrypt Control Panel
(you won't need the bestcrypt update application in PE anyway)

This way you have hardly any interference, except for a few seconds waiting when updating the storage volumes!

Link for plugin: http://www.mediafire.com/?a47311t7gmotylx

Thanks to Jaclaz for controlling his grumpiness and for his patience helping me on this subject !

Of course, feel free to find the missing 5%, but I am happy enough for the moment with the result.

It's strange.
I mean, the first devcon command is needed to properly "install" (or whatever) the ftdisk.sys, I presume that one could add this command to any of the auto-executing files of the BartPE (I mean having it "installed" should not prevent the working of all other software and should not add too muh delay to the boot).
What is queer is that once the thingy is functional the BartPE should be perfectly equivalent to a "normal" XP.
On a "normal" XP, if I get it right, there is no need to refresh the STORAGE.

The nest step (to go from your "95%" to 100%) is to try tracing the Bestcrypt when a new volume is mounted/accessed/whatever, it is possible that it sends a notification of some kind to some service that is in a "normal" XP, but that is not in your BartPE build.
First thing (semi-random ) that comes to my mind are the VSS thingies, but could be *anything*.

But it seems to me that it would be only an exercise, from what you write the 95% is IMHO "good enough" .



jaclaz

Yes quite right! there must be some sort of 'signal' when a mount is successful. I'll go through the registry changes again later tonight one last time, must be something I overlook.

When using the BestCrypt Traveller mode (just recently found out they had that), ftdisk is not even started !
But as I told you in PM, they use some kernel level driver and that concept might be a bit different.

The ONLY registry setting that refers to any new mount is this one:

Well, the HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\ is connected with Explorer .
Have you tried killing the Explorer process and re-start it?
(desperate attempt , but it costs nothing )

Have you tried running mountvol?

And dosdev?

Can you try to run showdrive or a similar tool?
http://reboot.pro/10169/


jaclaz