Change hardcoded value in executable - c#

A new game released has been provided with server files that do not currently have the option of configuring an IP Address/Port for binding. Unfortunately this limits the ability to run more than one instance of the application per machine as it is hard-coded to port "12345".
Many years ago I was using c++ and hex editors to change hard coded values like this and while that knowledge has long since been forgotten, would it be possible to improve this by writing a secondary application to change that value at runtime?

You still can use hex editor in order to change the hard coded constant.
Another way is to use debug api, provided by any decent OS. In Windows it is WriteProcessMemory function.
It looks following way - the launch application runs the modified application in debug mode. Changes needed constant and then runs it.
Of course, the modified application may use anti debugging techniques - in this case the solution is not trivial.
In both cases, you have to know where this value resides in the memory (executable file). This way some reverse engineering have to be provided.
Note, after the last question edits: All this answer is for native executable files. For managed code it probably is more complex.

Related

Is there absolutely no protection for Windows applications on dotnet?

I am in the middle of developing an application in Winforms and there just doesn't seem to be any protection from decompilation of the executables and other generated assemblies... there are tools that decompile literally within seconds. There are obfuscators available; however, I am specifically looking for a free one.
I store some pretty sensitive strings within the application, and though I try my best to keep them encrypted or in the local sqlite database, there is always that one, single point of failure that leaves the entire application vulnerable. I checked out a couple of obfuscators, both open source and commercial offerings. The open source one seems to be broken, and the commercial ones are priced quite steeply, which is unaffordable for an indie developer like me.
I am aware that an executable has to run in memory, and this in itself makes it vulnerable. And a determined attacker can eventually decompile an application. However, I want to make this process as expensive as possible. At the very least I would want to protect the strings within my application.
My question is, is there just no way to protect an application assembly from getting reverse engineered if I decide not to use any of the expensive options available?
There's lots of protection in Windows. But it's all there to protect the your users from you, not the other way around.
The simple fact of decompliation is: "As long as a computer can still execute it, it can also still decompile it."
Execution is a process that translates binary into actions.
Decompliation is a process that translates binary into code.
If one is blocked, the other is blocked as well.
Obfuscation can make it harder to read the decompiled code. But that is about all it can do.
I store some pretty sensitive strings within the application, and though I try my best to keep them encrypted or in the local sqlite database, there is always that one, single point of failure that leaves the entire application vulnerable
Every string, is only as save as the place you keep it at. The same applies for encryption keys. There are 2 limited workarounds:
if it is around comparing the input to something in the backend - like you do with passwords - password security can work. Modern PW security means not even the Adminsitrator can figure out the passwored, yet you can still compare user input to it.
You could move the strings into a seperate application. Instead of giving applications the SQL Server Connection string, you give it access to a WebService that you control. Only the WebService actually knows how to contact the Database.
It depends on your practical scenario what you can do. But in the end, if a string or other peice of information is to be useable, it is vulnerable in memory.

Is releasing app from Visual Studio safe? [duplicate]

This question already has answers here:
How can I obfuscate my c# code, so it can't be deobfuscated so easily? [closed]
(4 answers)
Closed 5 years ago.
I have provided a WPF app and changed solution configurations to "Release"
I got an .exe file from releasing. Is this secure to share? Can someone access the code of this exe file? I mean isn't there any app to convert an .exe file into code?
Please let me to know how could I protect it before sharing it.
You can decompile any assembly or executable which was compiled using a .NET-language (the same applies to Java). This is because .NET-languages are compiled into the so-called common intermediate language, which isn´t actual machine code. Thus you can easily de-compile that file into code. Depending on the tool to be used for decompilation you have a good chance to decompile the code as if it was before compilation, which means you easily understand what the developer of the programmer wrote in the code.
But in many cases you won´t really care for this so much. First there aren´t many people around that actually would read that code, or have you ever read the javascript-code of a famous website, which is even directly human-readable? Even if there are some around that are interested in reading your code, most will have some hard work to understand it anyway on the fly. This assumes some long and hard work, which most developers won´t do. You can only make it harder to read that decompiled code using an obfuscator, that kind of encrpyts your code before the compilation-process making it hard to understand the code when the exe was built.
Consider this code:
var myVariable = "Some Text";
var anotherVariable = myVariable;
DoSomething(anotherVariable);
Quite self-explanatory code, isn´t it? Now consider the following which may be produced using DotFuscator e.g.:
var a="Some Text";var b=a;hksdshd(b);
Much harder to understand what this code does, isn´t it? Basically an obfuscator just replaces all identifiers in your code by some random characters making it quite hard to guess what their intended use or meaning is. Afterwards that encrypted code is compiled as any other code into an assembly or an executable. When then someone really decompiles your program all they get are those hard to read names and fragments.
Having said this it´s quite hard to really protect your app from being read by anyone, and in most cases this isn´t what you should care for too much. Usually what you want to protect is your data, e.g. the information being stored in a database.
You may also have a look at this question, which has some closer look on obfuscation-tools.
It doesn't matter if you created your .exe file in Debug or Release mode - all executable files (.EXE) can be decompiled into code.
A decompiler is a computer program that takes an executable file as input, and attempts to create a high level, compilable source file that does the same thing.
It is therefore the opposite of a compiler, which takes a source file and makes an executable. Decompilers are considered as important tool in the process of reverse engineering.
Once such popular tool is hiew which offers to break down any exe created in any language into its high-level code.
For binaries and EXE files created using the .NET framework, there are several tools, including this one, which makes decompilation very easy and accessable.
You can prevent decompilation using Obfuscation. several tools are available, such as secureteam.net and Dotfuscator.

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.

Make an executable at runtime

Ok, so I was wondering how one would go about creating a program, that creates a second program(Like how most compression programs can create self extracting self excutables, but that's not what I need).
Say I have 2 programs. Each one containing a class. The one program I would use to modify and fill the class with data. The second file would be a program that also had the class, but empty, and it's only purpose is to access this data in a specific way. I don't know, I'm thinking if the specific class were serialized and then "injected" into the second file. But how would one be able to do that? I've found modifying files that were already compiled fascinating, though I've never been able to make changes that didn't cause errors.
That's just a thought. I don't know what the solution would be, that's just something that crossed my mind.
I'd prefer some information in say c or c++ that's cross-platform. The only other language I'd accept is c#.
also
I'm not looking for 3-rd party library's, or things such as Boost. If anything a shove in the right direction could be all I need.
++also
I don't want to be using a compiler.
Jalf actually read what I wrote
That's exactly what I would like to know how to do. I think that's fairly obvious by what I asked above. I said nothing about compiling the files, or scripting.
QUOTE "I've found modifying files that were already compiled fascinating"
Please read and understand the question first before posting.
thanks.
Building an executable from scratch is hard. First, you'd need to generate machine code for what the program would do, and then you need to encapsulate such code in an executable file. That's overkill unless you want to write a compiler for a language.
These utilities that generate a self-extracting executable don't really make the executable from scratch. They have the executable pre-generated, and the data file is just appended to the end of it. Since the Windows executable format allows you to put data at the end of the file, caring only for the "real executable" part (the exe header tells how big it is - the rest is ignored).
For instance, try to generate two self-extracting zip, and do a binary diff on them. You'll see their first X KBytes are exactly the same, what changes is the rest, which is not an executable at all, it's just data. When the file is executed, it looks what is found at the end of the file (the data) and unzips it.
Take a look at the wikipedia entry, go to the external links section to dig deeper:
http://en.wikipedia.org/wiki/Portable_Executable
I only mentioned Windows here but the same principles apply to Linux. But don't expect to have cross-platform results, you'll have to re-implement it to each platform. I couldn't imagine something that's more platform-dependent than the executable file. Even if you use C# you'll have to generate the native stub, which is different if you're running on Windows (under .net) or Linux (under Mono).
Invoke a compiler with data generated by your program (write temp files to disk if necessary) and or stored on disk?
Or is the question about the details of writing the local executable format?
Unfortunately with compiled languages such as C, C++, Java, or C#, you won't be able to just ``run'' new code at runtime, like you can do in interpreted languages like PHP, Perl, and ECMAscript. The code has to be compiled first, and for that you will need a compiler. There's no getting around this.
If you need to duplicate the save/restore functionality between two separate EXEs, then your best bet is to create a static library shared between the two programs, or a DLL shared between the two programs. That way, you write that code once and it's able to be used by as many programs as you want.
On the other hand, if you're really running into a scenario like this, my main question is, What are you trying to accomplish with this? Even in languages that support things like eval(), self modifying code is usually some of the nastiest and bug-riddled stuff you're going to find. It's worse even than a program written completely with GOTOs. There are uses for self modifying code like this, but 99% of the time it's the wrong approach to take.
Hope that helps :)
I had the same problem and I think that this solves all problems.
You can put there whatever code and if correct it will produce at runtime second executable.
--ADD--
So in short you have some code which you can hard-code and store in the code of your 1st exe file or let outside it. Then you run it and you compile the aforementioned code. If eveything is ok you will get a second executable runtime- compiled. All this without any external lib!!
Ok, so I was wondering how one would
go about creating a program, that
creates a second program
You can look at CodeDom. Here is a tutorial
Have you considered embedding a scripting language such as Lua or Python into your app? This will give you the ability to dynamically generate and execute code at runtime.
From wikipedia:
Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them.
Depending on what you call a program, Self-modifying code may do the trick.
Basically, you write code somewhere in memory as if it were plain data, and you call it.
Usually it's a bad idea, but it's quite fun.

Categories