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.
Related
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.
I'm developing a program in C#.
It connects to the internet to see if this copy is valid.
Currently I'm just sending the licence key and getting a response (0 or 1) if the key is valid.
The problem is that some users just fake the data with some packet capturing tool and replay it.
So the application is very easy to crack. How can I prevent this?
Here is what I essentially want to prevent:
Network replay attacks
Authentication "emulators"
It should be impossible to find out what data is sent.
Maybe I should add the current time and then encrypt the packet ?
So it's always different ?
Attention: Please don't warn me that it's easy to crack the application itself by modifying it. I know that. This question is only about the network part.
If you use SSL or HTTPS then you don't have to worry about users cracking the data packets. This is easy because the libraries already exist and are easy to implement. With C# and IIs for example it is just a matter of installing the certs and changing a few configuration items. (Maybe a recompile with some slight code changes).
Assuming you actually want to prevent license abuse there are far better ways to do this. The "phone home" approach is easy to roll yourself, but as you've noticed it's full of holes.
Disclaimer: I work for a company that makes commercial tools to solve these license management and copy-protection issues. There are other similar products available from a variety of vendors.
This isn't that different from thinking about how to do setup for your application. Choices are roll your own or buy an existing 3rd party toolset. Rolling your own at first blush make seem cheaper, but that's perhaps only because you haven't really discovered all the true requirements to create something robust and reliable. The 3rd party tool vendor needs to charge for their products, but they've spent years discovering all the issues with particular problem set and have solved the problems. So that eliminates work for you and leaves you free to focus on where your application can add value.
The difference is if you get setup wrong your users will be irritated; if you get copy protection wrong your product will be pirated.
In any event, reducing license validation checking to a binary "either/or" condition is extremely easy to crack--doing that check over the net makes it 10 times easier (record playback attack). Modern approaches encrypt the executable and the license is contained in the key to decrypt it (this is an oversimplification since the actual methodology includes a lot more complexity to make it virtually impossible to get around). Only by having a valid license can the executable be decrypted on program load and run.
If you want to do it the way you've described, consider this:
Have the app use a predictable, changing value (such as a lookup from a table of random numbers coupled with some external value like time) to create some kind of hash. Have the server implement the same code. The server sends the hash to the app, which compares it to its own hash. If they match, the app is allowed to run. If they don't, it errors out. Since the hash is different on ever startup attempt, recording it over the network won't allow the user to get it to run the next time it tries to start.
I love c# for programming applications (I consider myself intermediate with c#, and a bit less with C/C++, but am only learning, nothing real yet in the arena), and I used to like it until i discovered "anyone" who understand MSIL (not an easy task to learn neither) could decompile my code. I don’t really care about someone decompiling my code, but my utter concern is the security for my eventual program users. I know obfuscators exist, and I even know of one or two that are really good, I hear (even if they only delay a decompiling).
For example, if I want to decrypt something using c#, some where in the code the key should be, making it a danger for anyone who use my program (someone who know someone who encrypted the file using my program could decrypt it by researching on my MSIL code, finding my key). Then, the developing of massive applications that encrypt/decrypt stuff (or OpenSSL) is insane with c#, I think, for this reason.
I mean, most users won’t know what language was used to make that exe, but a bunch of people are able to program n c#, and an elite of this people can read MSIL, and a minority of this elite would like to hack what ever is possible to hack. Of those people who like to hack, some of them can do it with perverse intentions (in a value-less world where we live that shouldn’t surprise anyone).
So, if I want to make a program that download a file from the internet, someone could interfere the transmission and do some evil, even if I use OpenSSL with c#, because somewhere in the c# file is the key. I know avoiding hacking is probably impossible, but it looks like c# is a very unsecure way.
Does it happen with Java? (Java has the same “interpreting” and “decompile” structure as C#); I mean, the fact that the key is visible in Java (with some educated eye) some where in the building file? Or does Java use some C/C++ based API that makes it harder (way harder) to decompile the file where the key is and so making it hard to get the key?
Is my only option to write my program with c/c++? Because if so, my only option is C++Builder, since its a hell to even try to watch (and less to learn) MFC/OWL code; I mean: I cant hardly think of someone who could like MFC/OWL programming. In fact, I suppose Assembly could be of more interest in the today programming world.
So, here I am, wanting to find someone who could explain me better a way to store securely crypto keys for encrypting/decrypting or to use OpenSSL with c#. Or even with Java. I would like to confirm that C/C++ is the only way of really using these features with some security for decompiling reasons (as other compiled programming languages, i.e. Delphi).
If anyone knows a site where I can find precise information about the subtle reasoning I suppose I have done (specially one that shows am wrong in my analysis), please tell me. If any one can confirm my analysis, please confirm. If anyone find any hole in my analysis, again, please tell me, and where to find more information that rule me to get a better understanding of all this.
Am sorry for making this philosophical computer programming question that long.
Thank you,
McNaddy
Could I hide the encryption key of a c# exe securely (in a way that can't be decompiled in any known way), as in C/C++?
No. You can't do that in any language.
The .NET security system is designed to protect benign users from hostile code. You are trying to protect benign code from hostile users. You simply cannot do that, so don't even try. If you have a secret, do not share it with anyone.
The purpose of crypto is to leverage the secrecy of some private key into the secrecy of a text. If that is not the security problem you face, crypto is the wrong tool. Explain the security problem you actually have and someone here can help you solve it.
So, if I want to make a program that download a file from the internet, someone could interfere the transmission and do some evil, even if I use OpenSSL with c#, because somewhere in the c# file is the key.
You don't need to store a secret key in the program just to download a file safely.
If you want to ensure that the file you downloaded is authentic and hasn't been modified in transit, you use a digital signature. The private key used to make the signature doesn't have to be (and shouldn't be) distributed with the program; all the program needs is the corresponding public key, which you don't have to hide.
If you want to prevent eavesdroppers from reading the file as it's downloaded, then you need to encrypt it, but that can be done with a temporary session key generated randomly for each download; it doesn't have to be stored anywhere. If you use HTTPS for your download, it'll do this for you.
The choice you've mentioned (embed key into executable) is bad irrespective of language you choose - it is not too hard to extract data from C/C++ and slightly easier for C#/Java.
As Jordão said - you need to figure out your story of distributing key outside the binaries. You also need to figure out what you actually trying to protect and understand possible exploits. Just using encryption of some sort in an application does not make it more secure.
You should not store cryptographic keys inside assemblies; they should normally be provided from outside, e.g. from a key-store, or derived from a secret known to a user.
You can also generate a key from a password(this means the key is no more stronger than the password though). So each time the user runs the program, they are prompted for a password, and that password is then used to generate a key. Depending on your requirements you could employ this in a variety of ways.
When the user needs to access the encrypted data, the password can be provided again and this generates the key for use during that session. Once the program is closed the key is discarded(there are techniques/APIs in C# to help ensure that sensitive data is only present in memory as short a time as possible).
For example, this is essentially what many password storing programs like Keepass or Roboform do. The user can upload and download the encrypted data to and from servers. No keys are ever stores, and instead generated on demand as the user supplies their password for that session.
With a service like Dropbox, when you register with their site, they generate the private key on their server and keep a copy there. So the user's machine and client software never store the key, but the server has a copy stored. Dropbox does this so that they can decrypt user data for many purposes, such as compression, de-duplication, compliance with law enforcement, etc.
I have a number of files that were encrypted using EFS on my old Windows XP installation. I installed Windows 7 and now I can't access these files. You can read about the whole embarrassing situation here.
The good news is that I have keys that will allow the files to be decrypted. I know this because I used EFS data recovery and it was able to decrypt a file. It also identified that I had some usable key files of some sort (master key and private key).
The problem here is that Elcom want's $150 for their tool and what I have encrypted is not worth $150. Is there a way that I can do this myself, programmatically?
EDIT: This link is awesome...EFS recovery
I found the following resource:
http://www.beginningtoseethelight.org/efsrecovery/
It outlined how I could recover my files. I did have all the keys so I can decrypt the files if necessary. However, I gave up on this because I didn't want to trash my existing system in order to recover the old one. There's still a chance you can torch the new Windows installation and I didn't want to deal with all the backup stuff.
The only other answer I know of is to use a tool called RECCERTS.EXE that Microsoft Product Support has available to those who call. I can't even begin to imagine why after years of these kinds of problems people have had with EFS over and over, Microsoft still hasn't released this tool as a free download. It searches any available files it's pointed at to look for all the remnants of the keys and metadata necessary to decrypt and use the RSA private key that your previous OS install used to decrypt the EFS-encrypted files on your system. It works awfully well, but from what little documentation there is on the web (i.e. MSDN Social forum postings - latest in 2009), it appears this tool is still only available if you can find a way to convince MS Product Support to send you a copy. It appears that the cheapest official doorway here is the $99 email incident, but I wonder if they'd refund your money if you demonstrated that this fixed your problem (cf. how they used to refund - and may still do so - PSS incidents if you were able to demonstrate that there was a bug in their software for which you're calling). Not saying this is a bug, just the painful byproduct of a dubious design that doesn't warn users to take appropriate and explicit steps to avoid these recovery nightmares.
The only other possible solution is to search the web for RECCERTS.EXE and see if there are any locations where it's been made available for download. Many of such sites use legit filenames as "lures" to get you to download something that turns out to be malware, so be very careful if you take this approach. However, if your time is worth less than $99, then you just risk hosing a Windows install with nasty malware - and having to wipe & recover the system. [Just make sure there's an offline copy of the files you're trying to recover, in case the malware infects or corrupts an online, mounted copy of those files.]
As the founder's of stackoverflow talk so much about being able to deploy changes easy, I'm trying to come up with a solution to solve my issue. A quick background is that a client contacted me and needed something done on the database that is quite not so trivial, but isn't horribly difficult to do (took me about a day to get the procedure to work). Unfortunately, the client needs to be able to deploy this "fix" about 20 times, and without my input, as he isn't going to pay for it.
I have written a CLR trigger that does some work that would otherwise be very difficult using TSQL (xml document transformations.. I'm better at it using CLR vs. TSQL). Deployment is typically a few lines SQL and dumping the dll to a directory from what I can fish out (I've only ever deployed from VS.Net so far).
What I need to be able to do is to provide an MSI installer that will drop the file to a folder, and prompt the user for the database information that is required to connect the CLR procedure to the correct database/table.
Has anyone done this in the past, and if so, are you willing to school someone on how this is done, so I can get this project to bed?
Thanks
If you want to avoid the trickiness of placing the file, you can use the alternate form of the CREATE ASSEMBLY statement that specifies the assembly in byte form.
e.g.
CREATE ASSEMBY MyAssembly FROM 0xFFFF....;
Obviously, you would have the actual assembly bytes where I've put 0xFFFF.....