My VB.NET application has a very important boolean variable. I need to be able to save it "somewhere" and read it back in the future (even if the application is closed).
Currently, I store the variable as a .bin file somewhere. But I fear that the user can simply grab the file and do some magic to edit the value.
I need to make this value completely unavailable from the user's eyes. Or at least, make it impossible to edit. What is the best way to hide such value?
I managed to store the variable in my online MySQL database. But honestly, that doesn't work very well for my purposes. I need to store it locally...
Any ideas?
Theoretically, you can never hide this variable at all. However, you can make it harder to find or read. To know how to hide the variable, you must first know some common ways of retrieving it.
Typical problems and solutions
How others could theoretically retrieve your variable value
Decompiling your program with a single click using .NET Reflector or any other .NET Decompilation program.
Analyze the memory of the PC while the program is running, and retrieve the value from there.
If your value was saved in a file, the user could easily find it by analyzing harddrive IO activity through a hook or a dump comparison.
If your value was saved in the registry, a simple registry hook or registry dump comparison tool could figure out where the value is stored.
If your value is encrypted, method #1 (decompiling the program) could be used to figuring out how a decryption could be done.
Solving the possible issues above
A general obfuscation program can be used to make it harder to decompile applications. For this, I suggest SmartAssembly. Other than that, there's a tool called Spoon Studio (previously called PostBuild) which will recompile your application into assembly code (and also make it run without the .NET Framework installed).
The SecureString class could be used to make it harder to find and decrypt the value while it's in the memory. This class also cleans itself up after usage, but is generally slightly slower to use than a normal string.
Storing things in a file is not nescessarily a bad idea (even if people can sniff file activity), since you can always store the variable in a non-pretty way. For instance, you could have a file called IsFullScreen.bin, that contained the value of your boolean variable (1 or 0, or true or false), even though it has nothing to do with full-screen rendering. This would make it a bit confusing, but also not very pretty programming-wise.
For the registry, everything in solution #3 still applies.
Encryption is not a bad idea either, and it is hard to decrypt some encryption types (for instance public/private key encryption if you have a server), or hashing (such as MD5 or SHA1).
In your scenario, could you store the value on a server instead?
So to summarize ...
You can't protect your application entirely. But you can use some of the solutions above (or combine them) for a better protection making it harder.
Of course, premature security is bad. If that boolean isn't VERY important, then some simple encryption would be fine too in my opinion.
There's more ...
Edit 1
I just noticed that you've commented on your own answer saying that the file should not be "valid" after copying it to another computer and reading it from there.
If that's the case, you could use some key-based encryption such as XOR encryption, and then use the MAC-address of the PC or the motherboard serial number as key for that encryption.
Being on the computer that the file was created on would then be needed to read the file as well. If you're interested in this, add a comment and I'll give you a code example.
I would store it in the registry in a non-obvious way. For example, make the name of the registry entry appear to be important and store a random numeric value then ensure it ends in 0 or 1 or contains a 0 or 1 embedded at a fixed position in the number.
You can then read the value from the registry and extract the 0 or 1 from the appropriate location.
Encrypt the value before storing it. Use .NET Cryptography Model. For more on how to implement something using that model see
Related
I am using a Keygen application (.exe). There are two input fields in it's GUI:
p1 - at least 1 digit, 10 digits max - ^[0-9]{1,10}$
p2 - 12 chars max - uppercase letters/digits/underscores - ^[A-Z0-9_]{0,12}$
Pressing generate button produce a key x.
x - 20 digits exactly - ^[0-9]{20}$
For each pair (p1,p2), there is only one x (in other words: f(p1,p2) = x is a function)
I am interested in it's encryption algorithm.
Is there any way of reverse engineering the algorithm?
I thought of two ways:
decompiling. I used snowman, but the output is too polluted. The decompiled code probably contains non-relevant parts, such as the GUI.
analyzing of input and output. I wonder if there any option to determine the used encryption algorithm by analyzing a set of f(p1,p2) = x results.
As you mentioned, using snowman or some other decompiling tools is probably the way to go.
I doubt you would be able to determine the algorithm just by looking at the input output combinations, since it is possible to write any kind of arbitrary algorithm, that can behave in any way.
Perhaps you could just ask the author what algorithm they're using ?
Unless it's something really simple, I'd rule out your option 2 of trying to figure it out by looking at input and output pairs.
For decompiling / reverse engineering a static binary, you should first determine whether it's a .NET application or something else. If it's written in .NET you can try this for decompilation:
https://www.jetbrains.com/decompiler/
It's really easy to use, unless the binary has been obfuscated.
If the application is not a .NET application, you can try Ghidra and/or Cutter which both has pretty impressive decompilers built in:
https://ghidra-sre.org/
https://cutter.re/
If static code analysis is not enough, you can add a debugger to it. Ghidra and x64dbg work really well together, and can be synced via a plugin installed in both.
If you're new to this, I can recommend both that you look into basic assembler for the x86 platform so you have a general idea of how the CPU works. Another way to get started is "crackme" style challenges from CTF competitions. Often there great write-ups with the solution, so you have both the question and answer available.
Good luck!
Type in p1 and p2. Scan the process for that byte string. Then put a hardware breakpoint for memory access on it. Generate the key, it will hit that hardware breakpoint. Then you have the address which accesses it and start reversing from there in Ghidra(Don't forget to use BASE + OFFSET) since ghidra's output won't have the same base as the running application. The relevant code HAS to access the inputs. So you know where the algorithm is. Since it either directly accesses it, or somewhere within that call chain is accessed relatively fast. Nobody can know without actually seeing the executable.
This is my first attempt to use the registry in any depth, so bear with me...
I write small VB.net programs that interact with Excel and other programs to produce complex reports. As part of this we sometimes have to interact with a 3rd party DLL. Since this DLL is generally very rare, we took an "always install" policy, and run their installer on first-start.
Well now we have a customer who already has the 3rd party app, so the install fails (as it should). But this leaves me trying to find where the DLL/app has been installed so I can call it properly. Poking about in regedit (causing it to repeatedly crash) I have found it seems to be like this...
Installing the DLL produces an entry called APLW.WSEngine in HKEY_CLASSES_ROOT, as well as an apparently identical copy in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\. Those entries both contain a CLSID which can be found in HKEY_CLASSES_ROOT\Interface\[the key]\TypeLib as well as entries for a variety of sub-parts of the install. I also find it at HKEY_CLASSES_ROOT\TypeLib\[the key], and here it has a key called \3.0\HELPDIR\ that contains the directory I'm looking for.
So...
What is the minimum number of calls I need to make to find the value in that HELPDIR key, or get Nothing or "" if any of the keys doesn't exist. In the end I either need that path, or nothing if the software has not been installed. Currently I'm making repeated calls into the reg to look up each entry and key in turn, but I suspect there is a way to chain them?
To make things slightly more complex, that \3.0\ in the path may change, the actual value is in the Version key in the original CLSID entry. If there is an easy way to add this I'll use it, but since we only work with 3.0 (AFAIK) it can be ignored.
Maybe 1. Maybe more. Don't know, this was not a very typically laid out question (which is probably why you got down voted), but I'm going to assume that you are more of a numbers / reporting person than a software engineer. So proceeding with that assumption, I will try and be helpful instead of pointing out any breaches of etiquette and provide you a couple resources that may help.
For starters, how to read a registry value:
https://msdn.microsoft.com/en-us/library/xz88758e.aspx
Secondly, the full tech spec on the Registry class in vb.net:
https://msdn.microsoft.com/en-us/library/microsoft.win32.registry(v=vs.110).aspx
Both give plenty of samples that should aid you along your way. But keep in mind that in certain situations and certain computer setups, these sorts of registry calls might require you to elevate your UAC permissions, if you run into such a case, you can try this resource, which covers in some detail how to make your applications UAC aware:
http://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware
I hope this helps, and good luck!
I teach at a university and one assignment i have developed tests some quite specific modelling skill sets in Excel. Because of this, and because all assignments need to be fairly weighted, they end up having largely the same content (in terms of the final code) with different variables so that they are not exact copies - so it is fairly easy for students to take another persons completed file and input their own variables, change a few cosmetic items (drag data locations, colours, borders etc) and hand the work in as their own. i am confident that this is occurring and most of the time i can identify the suspects easily but proving the collusion (not so much detecting it), this is difficult.
I am trying to work out how i can include somewhere on the worksheet (which i will provide as a template) a function that logs the user ID and time each incidence that the save button is pressed (or at a set interval)? This way i can have this info logged in the background (hopefully where nobody can find or goes looking for it) and it will be quite easy for me to see if at any point along the way the student working on the sheet changed - indicating collusion. Of course there are other ways around this, and i am not looking for a fail safe system, just an easy way to catch lazy cheats.
I can find functions that save the last user to a cell, but none that can provide an ongoing log. Ideally, i would like it to be as covert as possible, i.e., avoiding obvious macros would be handy but i can understand this might be a problem. Does anyone have any tricks up their sleeve to help me in my quest to wipe out student copying?
Type sign in Excel's help. Look at digital signatures. There may be some way of using them?
From Help
After you have installed your digital certificate, you can sign files and macro projects.
When you digitally sign a file, you certify that the information in the file is valid and that it has not been modified since the file was signed. As long as a file is unchanged, reviewers can attach signatures to it. You might use a digital signature with important files. When you digitally sign a macro project, your digital signature says that you guarantee that the project is safe. Just as signed files remain signed until the file is modified, signed macro projects remain signed until the macro code is altered.
Or perhaps turn on track changes and make an initial change yourself.
I'm currently trying to write a program in VB.NET which fluidly changes the DWM window colorization colors in Windows 7.
I first tried to edit Registry values directly, but I had to restart the UXSMS service. This solution was unsatisfying, because of the toggle of the taskbar.
I'm now searching for a function in a DLL such as user32.dll or themecpl.dll which can reproduce the behaviour of control panel when setting the window color.
I'm now on IDA, searching for the adquate function (CColorCplPage::SetDwmColorizationColor seems good!). If anyone has one, please share it!
(If anyone need screens or code, please ask. Sorry for my poor English.)
Your first attempt failed because manually editing the Registry is never the correct way to change system settings. As you found out, lots of Windows components (and other applications!) read those configuration values once and cache them, preventing your changes from being propagated. Another problem (and you'd be surprised how often I see this) is applications that attempt to muck around in the Registry generally end up corrupting things.
Instead, you should call the documented API to change the settings. There's almost always a documented way of doing this, and if there isn't, well then you shouldn't be doing it.
This appears to be one of those cases. There's a documented DwmGetColorizationColor function, but there's no corresponding DwmSetColorizationColor function, as one might expect.
The reason is that the user is supposed to be the only one who can change their colorization settings, not other applications. You might promise not to abuse this, and to only make such changes at the user's explicit request, but not all applications can be trusted to do this. Lots of people would use it maliciously, so these functions have not been documented and exposed.
But as usual, if you press on, you can usually find an undocumented way of doing things. The problem with using undocumented functions is that there's no guarantee they'll work or continue to work. They've been intentionally left undocumented because they're liable to change on new versions of Windows. You should only use them at your own risk.
In this case, if you use a program like DumpBin to obtain a list of all the exported functions from the DWM DLL (dwmapi.dll), you'll see a number of undocumented exported functions.
The ones you're interested in are DwmGetColorizationParameters and DwmSetColorizationParameters. Both of these functions take a COLORIZATIONPARAMS structure as an argument that contains the values they need.
So, you need to reverse engineer these functions and obtain the appropriate definitions. Then, you can call the DwmGetColorizationParameters function, passing in a COLORIZATIONPARAMS structure to obtain the current configuration settings; modify the member of the structure that contains the current colorization color; and then pass that modified version of the structure to the DwmSetColorizationParameters function.
Did I mention that I don't recommend doing this?
I have a shell script stored in the resources folder of my Cocoa app. If used improperly it could be dangerous (even though I have taken precautions to reduce exploits, such as using the absolute path to commands) so is there any way to encrypt the script in binary format, then decrypt it when it needs to be used?
Thanks
It seems as if your concern is about people getting write access to the script and modifying it to run arbitrary code. You could keep a checksum for the script in the binary and compare that with the checksum of the script before you run it. Now, how do you stop people from editing the binary too? Code signing. In fact, if you keep the shell script in the app bundle then editing the script will break the signature of the bundle anyway.
This does not make a lot of sense. If an attacker has access to edit this script file, then they likely have access to edit any number of files, your application is less likely to be a security risk than any number of other things would be attacker could do.
No. If the user will decrypt it to use it, then she can see (and intercept) the clear text at some point. If you think you have "shell-like" things to do, do them in C/ObjC... This can be your friend.
What you're asking for is essentially DRM. A different purpose (“security” instead of thwarting copyright infringement), but the same approach, with the same problems.
In order for the user to be able to normally use the (music|video|script), they must be able to decrypt it. You would do this for them under only the right conditions in your (player|app), but that doesn't matter: no matter how well you hide it, you still have to provide the user with all the technology and keys necessary to decrypt the (music|video|script), so that your (player|app) can do that.
And then, since the user has all the technology and keys necessary to decrypt it, an attacker can and eventually will uncover them all and decrypt the (music|video|script) on their own.
I second Massa's suggestion of switching away from a shell script. This doesn't completely eliminate risk: If an attacker can gain access to write to your shell script, they can gain access to write to a Mach-O executable just as easily. But editing a Mach-O executable is not nearly as easy, so you are at least raising the bar that way.