Handling INI files can be a little tricky these days when you have to consider new security restrictions, virtualized environment restrictions (SoftGrid and Citrix) and legacy applications that don't install the way they should... Or, more importantly stay installed the way they were intended to.
INI files are configuration files used to store application, user or machine information. They have been used for the past 10 years and have been used really well (by Microsoft) and abused by some (IBM's Lotus Notes) to store information and help configure applications.
There is a reasonable definition of INI Files located here;
http://encyclopedia2.thefreedictionary.com/INI+file
The reason I making this post is that INI files are causing some considerable issues with Vista, Citrix and SoftGrid deployments. Application installations are installing and configuring INI files in semi or secure locations and either the user or the application is not able to properly read and/or write to these text based configuration stores. For example, under SoftGrid, the application will install correctly but when a user tries to run the application, critical information is either not stored or captured during the normal application loading/running process.
There are a few solutions;
1) Employ the MoveIniToRegistry Shim
Chris Jackson has an excellent posting on this technique found here
Http://blogs.msdn.com/cjacks/archive/2008/01/03/stock-viewer-shim-demo-application.asp
2) Use INIFileMapping
Frig (i.e. Hack) your local security settings and hope for the best (hint: turn off your mobile)
I prefer option 2, as the INI File Mapping allows use to replace your INI Files with entries (keys, names and values) in the Registry. This is great/useful as you can neatly avoid any local security restrictions as well as benefit from roaming profiles (e.g.. Not have to copy INI files on application start-up each time a new user logs onto a machine).
Microsoft has a great Knowledge Note/Support article which can be found here; http://support.microsoft.com/kb/102889
I won't replicate what has already been said in the Microsoft article but there are a few caveats;
- INI File Mapping works great for Vista and SoftGrid - but DO NOT use for Citrix when actually installing applications. See the Microsoft support note here: http://support.microsoft.com/kb/186504
- Your application needs to use the supported API's (GetPrivateProfileString and WritePrivateProfileString)
1 comment:
I'm looking for a forgotten article that detailed how to treat Autorun.inf as a "legacy .INI file" and thus redirect it to hell, as a way of killing Autorun.inf risks.
Is this the same topic?
I know about other ways of handling Autorun.inf risks, but AFAIK all have their weaknesses...
1) AutoRun = 0
Merely defers execution until the user browses the malware'd location via the shell, thus as useless as the old Win95 "disable Insert Notification" setting.
2) NoDriveTypeAutoRun
Not respected by unpatched Vista, DF misses U3 and other devices that spoof optical drives, and is prone to being changed by software "so that the disk works when inserted" (games, etc.)
3) NoDriveAutoRun
Useful when combined with (2), but relies on consistent lettering if you want to preserve Autorun for the optical drive. Thus fails when removable optical drive is not plugged in, and a USB stick is.
Post a Comment