If we want to store critical information, like passwords and server addresses, inside the executable file generated by the Delphi compiler, how can we do that, without knowing the final executable size and binary structure, like at the end of the file for example?
Side note:
The text to be stored is already encrypted; and in some computers the windows don't give access to write in the registry, specially when the user is not administrator, and there are hacks to monitor registry changes and the smart user can find the new windows registry entry.
Comment
Why this question was down voted? This is achievable! Doesn't meter if not interesting for most people.
I think about the bios and other firmware upgradeable, like satelite tv signal decoders that update themselves. How is that possible?
You can use an .rc file to put your data into a custom resource inside the final .exe file. You can then access that resource at run-time, such as with a TResourceStream, and decrypt and use its content as needed. However, you cannot write new data into the resource while the .exe is running, as the file is locked by the OS. If you need to write new settings, and do not have write access to the Registry, you will have to use a separate file instead. Windows has special folders set aside that users have write access to within their user profiles.
Create a string table resource is one way.
Create a text file. say secretstuff.rc (has to have .rc extension)
with something like this in it.
STRINGTABLE
{
1,"This is my encrypted password in say Base64"
}
Compile it to a .res file with BRCC32.
Include it in the relevant code with a compiler directive
{$R secretstuff.res}
After that you access with TResourceStream.
If you want to manage it a bit better might be wise to stuff them in a dll instead of an exe, then you can update things by delivering a new version of the dll.
There's an example with a it more detail, another purpose but same principle here
Related
I want to sign the user application with the user name if he makes a donation. For that I need to write the user name into the exe file. But the file cannot change itself because it is in use at that time. Do you know if anything can be done ? Of course, I can store the signature in a separate file or in registry, but in this way the signature can be lost. I want the modification to be permanent and cannot be changed by the user. I will accept any idea that help me accomplish this...
You can let the application make a copy of itself, then modify the copy, and then start the copy (with ShellExecute).
The modification could be inspired by the UpdateResource examples here: How to attach a resource file to an existing executable file?
The "signature" would be stored in a resource, so your application would have to read it from the resource, for example with Delphi's TResourceStream class.
For years I've put my application data files in c:\MyCompany\MyDataFileFolder\App where 'App' is my application name. I made this choice in the early days of Wild-West-Windows when Microsoft seemed to keep changing its own mind (My Documents, Documents, Program Data etc). As I've learnt more about how to do things correctly, and as Windows has now 'settled down' and is more picky about permissions I'd like to move my files. Users have got used to where they are though, and what I'd really like to do is to implement something like Windows does with 'special folders' where there are several synonymous names, thus in my legacy folder I'd like to put something in (or change a folder to) an alias for the real location which will now be something descended from Program Data. This way, the files are in a good place with the correct permissions and if we run a utility expecting or modifying files in the 'old' place this gets changed transparently to the 'new' place (thus a simple shortcut wont work).
Is this possible? Is there are recognised technique for this? I'm using Delphi XE2.
What you are looking for is either a Symbolic Link or a Reparse Point.
I'm wondering where's the best place to save some simple insensitive data? Like a few URLs and some settings.
Please advise.
If this is a per-user file, you should save it in the current user's profile. For example, on my Windows 7 system, you should use
C:\Users\Andreas Rejbrand\AppData\Local\Your Company Name\Your Product Name\Version
such as
C:\Users\Andreas Rejbrand\AppData\Local\Rejbrand\AlgoSim\2.0
To get the C:\Users\Andreas Rejbrand\AppData\Local path, you use the SHGetSpecialFolderPath function.
Settings, and specifically user-specific settings, can be stored in the registry. Have a look at the Registry unit and the TRegistry object.
Here's some demo code to get you going:
var
r:TRegistry
begin
r:=TRegistry.Create;
try
r.OpenKey('\Software\MyApplication',true);
r.WriteInteger('Setting1',Setting1);
r.WriteString('Setting2',Setting2);
finally
r.Free;
end;
end;
INI file or JSON file or XML file depending on your needs for local usage.
DB is for net usage.
It all depends on the purpose of those settings! If you want XCopy deployment, I would suggest an XML file next to the exe. But if you also need to write to this, you should find a suitable location in the current user's profile or the "all users" profile. The registry (local machine or current user) would also be a good option for simple settings.
Another question is the type of settings that you need to store. If it's simple settings, I generally start with Altova's XMLSpy to generate an XML schema, defining the structure of the settings. Then I use Delphi's XML import wizard to generate code from this schema and just use that generated code. It allows me to modify the structure in an easy way and also makes sure there's at least some documentation (the schema) telling others about the structure. It might sound complex at first, but once you're used to this, it's perfect! No more manual editing of registry settings or forgetting about the structure of your INI files. And no more thinking about writing code to read and write those settings, since Delphi will do that for you!The Registry would also be a good location for settings but not every user will have proper access rights to read from, or write to, the registry which could crash your application. Besides, the registry has some other limitations which makes it unsuitable if you need to store a lot of settings! It would be okay to store a connection string and maybe username and encrypted password for some user account, but if you need to store 40 settings or more, then the Registry becomes unsuitable.The same is true about INI files, which tend to be limited to a maximum size of 64 kilobytes. Of course, you could also store those settings in a regular text file or just some binary file. In the past, I even stored settings inside a ZIP file, because I needed to store dozens of grid-related settings. So each grid would read and write it's settings to some binary stream which would then be stored in an encrypted ZIP file.
There are many options like XML (structured data storage), ini files (simple data), databases or flat files.
I will go for XML's saved with ClientDatasets. They allow lot of options like searching, sorting, usage of the database controls and many more.
I have .Net desktop app which users can download from my website. I want to customize this app to per user basis.
Is there way to modify exe before downloading, just to change few strings with appropriate for the users downloading ?
Or it is possible to pass command line parameters to this exe via URL ?
The .exe file needs to be customized for it to behave differently for certain downloads.
Skip below to find the solution I found tolerable.
Add section to the .EXE file – Not ideal.
The .exe file has sections one after the other. You could add a section with your data in it, which the executable would then read. This requires you to modify (have access to) the source code of the executable for it to do anything meaningful with the data. Also getting familiar with the .exe file format and modifying it on the web server side as well al playing with it in the program's source code is somewhat tedious.
Change resources section of the .EXE file – Not ideal.
A dedicated "resources" section exists in the executable. You could add custom strings or blob of data to it. Same cons as the first one.
Overwrite data in the .EXE at a fixed position – Passable.
Have the executable read data from itself from a fixed position in the file, which is overwritten with the customization data when serving the .exe file. Requires modifying the executable's source code.
Append data to the .EXE – Passable.
Append data to the executable. Again, reading it and doing anything special with it requires the executable itself doing so.
☑ Wrap the .EXE in another .EXE and append your data to it – Tolerable.
Create a program to which the original executable and the custom data will be appended to. When this custom program is then executed, it will extract the embedded executable and launch it with the custom data as it arguments.
This kind of a bundle-executable is also easy to produce on most server-side (scripting) languages. When the download is requested, the server sends the wrapper-exe, the original exe, the customized data and of course some statically-sized data fields denoting the sizes of both of those data blocks so it can extract them.
Cons: Requires such a wrapper program to be created, unless someone already has.
Related links:
1. Best practices to let my web users download custom .exe from my site using PHP
2. Modifying executable upon download (Like Ninite)
If the application is ClickOnce deployed, passing URL parameters is an option in the ClickOnce options dialog. However, I have not yet used this feature.
EDIT
You might want to change some user settings in your configuration depending on the user that actually runs the application. You could also make sure this is done only once per user by adding an appropriate SettingsNeedUpdate setting you set to true after the initial initialization.
Example:
Add new setting "Option1", "Option2" and "SettingsNeedUpdate" which are user settings. In Main you could add something like:
...
try
{
if (Properties.Settings.Default.SettingsNeedUpdate)
{
Properties.Settings.Default.Option1 = ...;
Properties.Settings.Default.Option2 = ...;
Properties.Settings.Default.SettingsNeedUpdate = false;
Properties.Settings.Default.Save();
}
}
catch (Exception exp)
{
...
}
...
You could write a library which can modify an assembly resources (here string table).
This library could benefit from reflection.
When a user asks for your file, asp.net page could customize the exe (using your library) and send it to client.
Not like that, No.
You could however automatically zip (on your server) your exe with a custom app.config file for each user.
Update
Point your download location to a custom HttpHandler that zips together your exe (using http://www.sharpdevelop.net/OpenSource/SharpZipLib/) with a generated (for the current user) application configuration file ( http://generally.wordpress.com/2007/09/27/using-appconfig-for-user-defined-runtime-parameters/).
The user then unzips the two files (MyApp.exe & MyApp.exe.config) to any location and run MyApp.exe.
This method does not work if you have an installer.
How do i get the location of the file that i used to open my programs with?
Example: if i create a new extention ".xyz" say and i tell windows that i want to open the file type .xyz with myapplication, then it starts my aplication. Great, but how does my application get a handle on the file path of the file that was used to start it?
Also, is there a way to keep just one version of my app running and new files that are opened to just call a method in my application? For example if your using a torrent and you open 5 .torrent files they all just get passed to one application.
Side question: are all file extensions 3 letters long and is there a list of ones that are publicly used? If im creating a file extension I don't want to use one that is already used.
When you created your file association, you specified the command line that Explorer should run to activate your program. The shell puts the name of the document file on the command line, too, so in your program, check the command-line arguments. How you do that depends on your language and development environment. In Delphi, use the ParamCount and ParamStr functions.
When you create the file association, you can specify exactly where on the command line the document file name should go. Use %1 somewhere on the command line, and the shell will replace it with the file name. Since Windows file names frequently contains spaces, you should put quotation marks around the file name, so the command line in the file association would look like this:
ArthurApp.exe "%1"
With that association, double-clicking another document file will start another instance of your program. If you'd prefer to have the document opened in another window of the already-running instance, then you can write code to make your program look for already-running instances when it starts up. If it finds one, then it can communicate with that instance to tell it what file to open. You can effect that communication any number of ways, including mailslots, sockets, named pipes, memory-mapped files, and DDE.
The shell's file-association mechanism already has a way of communicating via DDE, so a second instance of your program wouldn't be started at all. Instead, the shell would start a DDE conversation with the already-running instance and tell it the new file name that way. However, DDE seems to be falling out of favor nowadays, so check out some of the other options first.
For your side question, no, extensions are not always three characters long. Look around, and that should be obvious: C code goes in .c files, Adobe Illustrator graphics go in .ai files, and new Microsoft Word documents go in .docx files.
But beware. If you ask for **.doc*, the results will include .docx files as well. That's because FindFirstFile matches both short and long file names, and long file names with long file extensions have three-character extensions in their short-file-name versions.
Rob covered the answer to your question(s) beautifully.
As to the last part, whether there is a public list of file extensions - not as such, but there is shell.windows.com, the web service Explorer uses to locate handlers for unknown file extensions. You can make up an extension then query shell.windows.com to see whether it's been registered. For example, to check whether the extension .blah has been registered by anyone on shell.windows.com, just open this URL in any browser:
http://shell.windows.com/fileassoc/0409/xml/redir.asp?ext=blah
Of course, replace the trailing blah with your extension.
You can find more details about this in KB929149 and in Raymond Chen's post Where does shell.windows.com get information about file extensions, and how do I get in on that action?.