We Keep Coding

File.Delete or File.Encrypt to wipe files?

is it possible to use either File.Delete or File.Encrypt to shred files? Or do both functions not overwrite the actual content on disk?
And if they do, does this also work with wear leveling of ssds and similar techniques of other storages? Or is there another function that I should use instead?
I'm trying to improve an open source project which currently stores credentials in plaintext within a file. Because of reasons they are always written to that file (I don't know why Ansible does this, but for now I don't want to touch that part of the code, there may be some valid reason, why that is that way, at least for now) and I can just delete that file afterwards. So is using File.Delete or File.Encrypt the right approach to purge that information off the disk?
Edit: If it is only possible using native API and pinvoke, I'm also fine with that. I'm not limited to only .net, but to C#.
Edit2: To provide some context: The plaintext credentials are saved by the ansible internals as they are passed as a variable for the modules that get executed on the target windows host. This file is responsible for retrieving the variables again: https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1#L287
https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/csharp/Ansible.Basic.cs#L373

There's a possibility that File.Encrypt would do more to help shred data than File.Delete (which definitely does nothing in that regard), but it won't be a reliable approach.
There's a lot going on at both the Operating System and Hardware level that's a couple of abstraction layers separated from the .NET code. For example, your file system may randomly decide to move the location where it's storing your file physically on the disk, so overwriting the place where you currently think the file is might not actually remove traces from where the file was stored previously. Even if you succeed in overwriting the right parts of the file, there's often residual signal on the disk itself that could be picked up by someone with the right equipment. Some file systems don't truly overwrite anything: they just add information every time a change happens, so you can always find out what the disk's contents were at any given point in time.
So if you legitimately cannot prevent a file getting saved, any attempt to truly erase it is going to be imperfect. If you're willing to accept imperfection and only want to mitigate the potential for problems somewhat, you can use a strategy like the ones you've found to try to overwrite the file with garbage data several times and hope for the best.
But I wouldn't be too quick to give up on solving the problem at its source. For example, Ansible's docs mention:
A great alternative to the password lookup plugin, if you don’t need to generate random passwords on a per-host basis, would be to use Vault in playbooks. Read the documentation there and consider using it first, it will be more desirable for most applications.

Trying to access hash table from finished software

At my company, we bought a huge software package (written in C#) which is currently being rolled out in my department. Because of trade secret reasons my company opted to not get the service contract with the developer so now I’m in the position of learning the software/hardware on my own along with all the troubleshooting. While doing this I made a change at some point which caused the below error which I haven’t been able to undo. When trying to generate a report I get the following error message.
I’m trying to view the contents of the hash table so that I can delete what is reserving the key “1” or so that I can return whatever was changed so that when I generate a report it would try to enter a different key. Do you have any advice on where the hash table is located or how I can read it? I’ve seen other posts on how to read hash tables. I’m just having trouble finding it.
I have access to most if not all the .h and .dll files and so I’ve been exploring those. I took a few C++ courses a few years ago and so I have a general idea on how to read the code.
Is the hash table in the executable? Where would it be located? I couldn’t find it as a .txt or .mdb file. Once I find it, how would I access it? I could post some of the code if that would help, but I’m not sure what parts of the code would be useful to you at this point. Any help would be greatly appreciated. Thanks in advance.

You are seriously out of luck, if you don't have the source code for that DTL3DTDTP thing - you'll have to reverse-engineer it to understand what happens. If you can connect to the running app from Visual Studio and intercept the exception (with "Just my code" disabled) and you have Reflector add-in installed you will be (probably) able to look at the reassembled source and call stack, maybe even variables. That HashTable is either a field of DTL3DTDTP or a local variable or something else... what and when adds the second (and the first) duplicate key to it is anyone guess... in the worst case you can reassemble the whole product and spend a month reading the code.
Of course all that will be blatantly illegal if the package is commercial - IP owners don't like reverse-engineers.
If you do have the source, just debug it.

How do I open OLEDB Prompt for 32-bit from x64

Good day everyone,
I am writing a C# application that will allow users to dynamically set the database they want to connect to (I'll work a bit with the database data and such, but that's not important). The important part is that I'm allowing my users to connect to data-stores from OLEDB using the code below.
ADODB.Connection connection;
MSDASC.DataLinks instance = new MSDASC.DataLinksClass();
if( (connection = instance.PromptNew() as ADODB.Connection) == null ) return;
This will open the very same Dialog that windows opens for *.udl files, and that's exactly what I want.
However, I hit a interesting problem to which your brightness could come in handy: some customer WILL have to browse for x86 drivers, and the vast majority will certainly use x64.
I know you can open x86 UDL files with the following command-line:
"C:\Windows\syswow64\rundll32.exe" "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile "C:\myConnectionFile.udl"
When the default (64 bit) command is:
"C:\Program Files\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile "C:\myConnectionFile.udl"
In other words: windows' allowing users to create entries in both fashion. I would like to do the same in my app, using the API.
I have considered the option of creating a temp UDL file and opening from the command-line above, which made my conversation with my technical lead rather unpleasant, so that's not an option.
All suggestions are welcome. I will not dismiss unsafe coding nor the thought of building wrapper in C++ if we get to that (although my C++ is inconveniently rusty nowadays).
Thank you all in advance and happy coding...

Good day fellow developers,
After a tedious and lengthy research process I have around the answer I was looking for.
In order to use OLEDB providers for both 32 and 64 bit platform from one single C# 64bit app I'll need to create an Out-of-Process Wrapper to the 32bit call, and make the call over IPC (Internal Process Calls). Because the amount of functionalities I'm exposing is moderate, the hindrance was just re-creating some method calls on the wrapper.
This blog helped me put the parts together, and now I'm able to determine what type of OLEDB connection I'll allow my user create, and I'm also able to perform all operations I need regardless of the Provider Architecture.
I hope this will benefit other people who might be having the issue.
If time (and NDA) allows, I'll get the code here for people to copy and try it later.
These links were also very useful on my research
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
Registering the DLL Server for Surrogate Activation
https: // msdn.microsoft.com/en-us/library/windows/desktop/ms686606(v=vs.85).aspx)
Writing Serviced Component
https: // msdn.microsoft.com/en-us/library/3x7357ez(VS.80).aspx)
How to: Create Serviced Component
https: // msdn.microsoft.com/en-us/library/ty17dz7h(VS.80).aspx)
Create Out-Of-Process COM in C#/.Net?http: // stackoverflow.com/questions/446417/create-out-of-process-com-in-c-net
Thanks everyone
D

Deploying a C# application - user form (novice)

I'm virtually a complete novice, I've tried Googling for answers and become totally confused.
Using Visual Studio 2010, I have a C# application which is an email notifier for a friend. The external (Arduino) hardware works, the main code (from a website) works but I'm sending it to her on the other side of the world to use and she is very 'non-technical' - hence the need for a 'setup form'.
I have created a form where she can enter comm port (selected from a list), username and password (all to be used by the main code), but that form should run only when the application is first installed on the PC.
At the moment it runs in VS-2010 (though I need to iron out a couple of snags), validates and hides - but I don't know how to a) store the data and make it available to the main code, b) ensure that the form only runs at setup, or c) exactly what I need to do or include to create an installable application.
Could somebody either help or direct me to some tutorials that don't assume I understand all the terminology?
I just want to create something that she can instal from a memory stick. I know it can be done and it's proababy quite simple for those who understand - I'm trying to learn but I'm no longer young and it's a struggle.
Thanks

a) store the data and make it available to the main code,
write the data on a file!
you have millions of possibilities, for isntance reading and writing a plain text file can be done with few lines of code, but if you want to encrypt your file (it may be the case if you want to store the password) you can use System.Security.Cryptography as shown in this guide
b) ensure that the form only runs at setup,
once you have written the file, then it means that the program has run already at least once, so you don't need to ask the user again (just read the data from the file)
c) exactly what I need to do or include to create an installable application.
Visual Studio already comes with the Setup project for this task. See this good guide.

From your comment and link to the code project for the Arduino, I gather that this is your first venture into writing code in C#, or very close to it. And ideally you'd like to make this as easy for your friend as possible. The best advice I can give you is not to try to run before you learn to walk. If you try to create a custom setup project and use a configuration file, which is what you are talking about doing, you may hit so many barriers that you never get to a successful end of the project. That kind of experience is discouraging and I'd hate for you to lose the drive to ever want to try another software project.
Make this initial project easy on yourself. This is not good programming practice for most situations, but if you only have one user, hard-code her configruation information for this first version. In other words, put her username, password, com port, etc directly into the main program. This eliminates the need for both the configuration, and any custom setup form. If you still want to make the whole thing configurable and versatile, do that in your next version. Custom setup is not a beginner task. It will be a lot easier to take on with the encouragement of your friend's excitement and compliments over a first version that works.

Is there any way for converting reference dll to non-reference dll in visual studio

I have a DLL file (cf.dll) in my project.
It has some methods for encrypting and decrypting a string To/From a file.
My "cf.dll" have some methods for:
write "mystring" ---to-->> new encrypted dll
and
read encrypted dll ---to--->> "mystring"
Now i want publish my project, but if end user use my dll in his/her visual studio (by reference to dll), he/she can decrypt my encrypted files.
Another hand i need this dll in my published project because my project use theirs methods some times.
Now my question is:
How can i change this published dll (cf.dll) to a none-reference dll, for prevent any hack by it.
Edit (more details):
What i want to do:
I want encrypt some connection strings (as a DataTable) to a file and read this file agin.
I have a dll file for doing this work. it is cf.dll. it has some methods for encrypting and decrypting.
Encryption workflow>
DatatTable ------to------>> Xml as String ------by cf.dll methods to------>> enc.dll
Decryption workflow
enc.dll ------by cf.dll methods to------>> Xml as String ------to------>> DataTable
Everything is working properly and encrypted file (enc.dll) is created.
But if the end user use my magic DLL (cf.dll) in a new project in the visual studio (by reference to it), he/she can decrypt my encrypted file (enc.dll) and hack my program.
So, i want to prevent this hack by changing my DLL (cf.dll) to a none-reference DLL OR use another safe solution.
Edit:
My Table Columns for keeping connection string data:
Server DbName DbUser DbPass FileName
But may i ask save another DataTable by this encryption mechanism. so please help me by a solution for saving any string, not only a ConnectionString.
I want a very secure encrypted file from any data. in my solution i conver each object to a string then use my dll methods for save it as a encrypted file (i can do it nice, my problem described above).

You cannot make your dll "non-reference dll", but you can hide all your classes/methods with "internal" keyword (instead of public). This means that this classes/methods can be used only inside of current dll or in DLL/EXE which were specified with InternalVisibleTo attribute. So nobody can use them directly, but you should know that this is managed code, so anybody can take a look inside of your DLL and extract your keys for decryption and write the same code as you have in your dll.

Surprisingly you can not archieve your goal by using a .NET Assembly.
You could even obfuscate your code and it would still be decompilable and reusable.
There's nothing which can prevent that. You can rise the bar, but someone - if she want's - will be able to get the information you are trying to hide.
(Have you seen copy-protection mechanisms that really work besides doing something crucial online?)
Always think of the following:
If you want to hide information from a user DO NOT DELIVER that information. Everything else is just protection through obfuscation, wich can be cracked with more or less effort.

That's a really nice question RAM.
Some solutions to your problem:
1) Don't make a separate assembly (DLL), but put the code of your DLL in your EXE and make the encryption/decryption function of your DLL "internal" (so that no-one can use it from outside the EXE). Then use a free tool like Eazfuscator to obfuscate your EXE (because, if you don't, your code will be easy to decompile and read).
2) You could put the DLL in your EXE's resources (perhaps encrypted too). Then perhaps you can find a way to get it from there and load it into memory for your app to use. But this is quite complex thing to do if you are a beginner and I'm not 100% sure if it's doable in .NET (I haven't done it myself). However, I think it's doable.
3) The fact is that, if your code executes on the client's machine, there's not much you can do to prevent people from analysing it. The best you can do is to make it a little (or much) difficult for them to do it. E.g. you can add a lock mechanism in your DLL that requires the caller to respond to a random question. If he responds correctly, you execute the decryption. If not, throw an exception, return null or, even better, return a wrong output. The random question could be an integer that your DLL will generate on initialization and the EXE should process this integer to generate a new integer based on some "secret" algorithm. Then the EXE will "feed" this into the DLL somehow and it's functionality would be "unlocked".
4) Perhaps you could use reflection to analyse the caller assembly in order to find characteristics or even the author signature (if you put one in your EXE). That way, you could execute the decryption if the EXE is signed by your private key and the signature is valid. But that's a bit complex too.
5) I think there are tools called "EXE packers" that pack your EXE and DLLs into one EXE file and protect them at some degree. I haven't used one of those yet.
6) You can move the encryption/decryption process on a web site that will ask for authentication in a complex manner, similar to the one described in (3) for the DLL. This may keep your encryption algorithm safe, but the authentication process could still be analysed and hacked.
I would suggest the 3rd solution since it's the most easy to implement. The 4th (using signed code) is the most secure one but it takes a lot of knowledge to implement it (knowledge that even I don't have right now).
Have a nice coding! :)