|
It looks like half completed code, or post-refactored code which has not been cleaned up.
In the former case, the completion of that method would perhaps put some validation in to check the inputs.
In the latter case, the method may have been left as there are many places around the application calling TimeDiff and changing them all to APTimeDiff may be too time consuming at the current time.
|
|
|
|
|
Thanks guys, that makes sense. It is source code that has been passed on for many versions and many years, so it may very well be a change that has been made without cleaning the older parts up properly.
|
|
|
|
|
Is there something that I'm not understanding properly here? I've written a DLL that our customers can use to connect to our server and exchange certain info. On the one hand it makes it easier for them, not having to code a bunch of comms stuff and on the other hand it hides our exact protocol from them (or so I hoped).
When I use the DLL in my own test application and I set breakpoints in my code I can step right into the functions in the DLL. Surely it should be possible to avoid this? Any help please?
|
|
|
|
|
You can step into the DLL in your test application because it is debug compiled. You will provide a release compiled DLL to your customer. If you want to "hide" your code even more you can run it through an obfuscator, for instance dotfuscator.
|
|
|
|
|
Thanks for the reply. I will have a look at Dotfuscator.
Just to be clear, my DLL was indeed compiled with RELEASE configuration, not DEBUG. Now I'm not even sure what the difference is anymore as I always thought this was one of the key differences between the two configurations.
|
|
|
|
|
You can never entirely avoid leaking the code though. You can not depend on your code being secret. The CPU can still run the code, and everything the CPU does to be able to read the code is something the user could do as well. There is no solution.
A protocol is even harder to hide since they could capture their own internet traffic and analyse it.
But you can make it harder for your customer to read your code by using an obfuscator as indicated by Calla
|
|
|
|
|
It makes sense, thanks. I can understand that you can never prevent someone from decompiling your code but I would like for it to be a bit harder than this! It looks like Dotfuscator might do the job, I'll look into it, thanks.
|
|
|
|
|
Dewald wrote: Surely it should be possible to avoid this?
If it was possible to avoid, then there coudn't be any cracs and Keygens. The fact that reverse enginering is possible, it can be obscured, not prevented. Was that dll compiled with debug info? Is the Dll project in your solution with app project? If both question is yes, then you can easly debug dll and see it's source
you could compress the dll with UPX or other packer.
also look at this article: Strong Names Explained[^]
|
|
|
|
|
Thanks for the response. No, the DLL was not compiled in DEBUG configuration and no, the DLL project is not part of my app sollution. I have two sollutions, one for the DLL and one for my test app. The DLL sollution is compiled in RELEASE configuration and I then manually copied the .dll file into my test app sollution folder and added it as a reference to the project.
When I set a breakpoint on the line where I call a function in the DLL and I step into the line, it steps right into my DLL exposing all of the code.
Thanks for the article, I'll have a look at it and also have a look at UPX.
|
|
|
|
|
Then maybe you copied the PDB file as well? If no, I don't know how you could debug it.. (maybe VS tried to help you along the way in a very MS behind the scences kind of way).
To be sure how your DLL could be (mis)used by the customer I suggest you copy only the DLL file in a RELEASE compiled version to for instance a virtual machine with VS installed and then try and see what happens. From what I've experienced it is not possible to debug the DLL if you don't have any additional files (such as PDB) and you should be safe when it comes to stepping into your code. Then again, totally hiding the source is hard because of reverse engineering tools. Good luck!
|
|
|
|
|
I think you may be right about VS trying to help in a very MS behind the scene kind of way  , because I definitely did not copy the PDB.
Not too worry, I think this obfuscator did the trick (mostly).
Thanks for the help.
|
|
|
|
|
Debug vs. Release is not as clear cut in the .NET world as it was in something like C++. You can still debug release stuff.
What I *think* is probably happening is that you've still got a PDB file despite building in release. This is the file that tells the debugger how to map instructions to lines of source code. If you don't distribute that, then they shouldn't be able to step in the debugger. Also, they'd have to have the source code anyway which they won't.
It's by virtue of the fact you have both source and PDB on your machine you can do it, so no, they won't be able to step through it.
As other's have mentioned, it's very straight forward to reverse engineer .NET with something like Reflector. You can obfuscate it, but that's not that effective. Really, if you need to protect some Intellectual Property you'd need to use something other than .NET, or maybe managed/unmanaged C++. But, ultimately, anything can be reverse engineered.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: Debug vs. Release is not as clear cut in the .NET world as it was in something like C++.
I'm giving a 5 for that.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
This is all very interesting, thanks. I am perplexed though because I know for a fact that my test app and my dll are in separate solutions in separate folders. I definitely did compile the dll in release config and, while the compiler did create a .pdb file (in the release directory) I only copied the .dll file into my test app's folder.
At any rate, I fiddled around with Dotfuscator a bit and I seem to have gotten to a point where the .dll is ugly enough to at least dissuade the average programmer from decompiling it and at least I can't step into the code in debug mode anymore.
|
|
|
|
|
I find that when I reference a DLL that's been built in release mode while debugging, Visual Studio pops up a message saying it can't be debugged and asks if I want to continue. So I haven't seen the situation you describe.
But I also delete the PDB files, so maybe that helps.
|
|
|
|
|
PLAYER WHICH PLAYS ALL audio and video FILES LIKE
FLASH MOVIE,MP3,MP4,AVI,JPG,WMA
i have created one but doesnt support flash files using c#.net 2.0
actually i need to create "Youtube" like windows based application.
Thanking you
|
|
|
|
|
|
Hello,
I want to send some text or keys to other applications say "notepad,calc,etc.". I have tried but i failed. New window is opened but key is not displayed on the window.
Here is my code:
[DllImport("User32.DLL")]
public static extern bool SetForegroundWindow(IntPtr hwnd);
[DllImport("User32.DLL")]
public static extern int SetActiveWindow(IntPtr hwnd);
newprocess.StartInfo.FileName = "calc.exe";
newprocess.StartInfo.UseShellExecute = false;
newprocess.StartInfo.RedirectStandardOutput = true;
newprocess.StartInfo.RedirectStandardInput = true;
newprocess.Start();
SetActiveWindow(newprocess.MainWindowHandle);
keybd_event(0x61, 0x45, KEYEVENTF_EXTENDEDKEY, 0);
keybd_event(0x61, 0x45, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0);
keybd_event(0x6B, 0x45, KEYEVENTF_EXTENDEDKEY, 0);
keybd_event(0x6B, 0x45, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0);
keybd_event(0x61, 0x45, KEYEVENTF_EXTENDEDKEY, 0);
keybd_event(0x61, 0x45, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0);
I have tried with many functions like SetForegroundWindow(), but there is no change. I have tried with notepad and used Sendkeys.Sendwait(), and its working fine. But help me for keybd_event().
Please help me its urgent.
Thank you in advance.
modified on Thursday, December 3, 2009 4:34 AM
|
|
|
|
|
What's keybd_event?
Not entirely sure how easy this is to do these days, as a protected operating system should to some extent stop processes interfering with each other.
What you probably want to do is call SendMessage on the window passing in keyboard messages. Wouldn't like to say whether that will work or not.
Regards,
Rob Philpott.
|
|
|
|
|
Thank you for your reply,
Keybd_event() is working fine for opening start menu and search files. But when i open any new application with process class its not working. I think focus is not done in newly created process window and keyboard focus is also not there. But i have setfocus() for keyboard focus and still its not working.
Please help me.
Thank you in advance.
|
|
|
|
|
I don't know if anyone on here has used the DDay.iCal library to create iCal files, but I thought I'd throw this out anyway, and see what I get. I've posted the same question just now on their forum as well. Basically, I'm trying to create an iCal file that includes reminders; in other words, when I open the item in Outlook, the appointment has, say, 1 Day as the reminder setting. I just can't seem to get it to work, though. The appointment looks good, except for this one facet. Here's the relevant code:
Alarm alarm = new Alarm();
alarm.Action = AlarmAction.Display;
alarm.Description = "Reminder";
alarm.Trigger = new Trigger(TimeSpan.FromDays(-1));
evt.AddAlarm(alarm);
Any ideas? Thanks in advance. If the DDay forum gets back to me, I'll post their response here for anyone else to view.
|
|
|
|
|
Hello all,
I have one problem in my module. in my project we are using the charcaters ASCII 32 to 255. we are display the character based on value i.e., if we want display Ö char just convert the 153 to charcater (char x = (char)153). But one of my coustmer wants if he enter the character by pressing Alt + 153 that will also we have to display. Now we are facing the problem Alt + 153 charcter is giving 214 value.we are not the proper value for that charcter. like this from 128 to 255 character we are facing the problem. can any one suggest some solution? it is very helpfull to me.
thanks in advance
Bhaskar
|
|
|
|
|
That is realy odd. "Ö" that is the char when i press ALT + 153. "Í" that is the char with ALT+214. Have you tried using Encoding.ASCII?
Also windows have Character map app. Some characters show on it with alt combination.
|
|
|
|
|
Thanks For ur reply,
If u try to debug the code.
char ch1 = (char)153;
char ch2 = 'Ö'; // alt + 153;
in this case ch1 value will be 153 and ch2 value will be 214.
|
|
|
|
|
Alt Codes[^]
Acording to that page, those codes are not ASCII or unicode. But rather ANSI or old MS-Dos code page based. if the numbers doesn't have zero in front of "Alt+153" uses MS-Dos code pages.
System.Text.Encoding.GetEncoding(850).GetChars(new Byte[]{153})[0]
That code uses code page: 850. That is "Multilingual (Latin-1)" (Western European languages) (Copied from wiki, link below)
List of Code pages[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
