|
In your situation you don't need to paste at all!
Examine the html source of the webpage that you have been trying to paste into. You need to replicate that functionality in your code and send the data (either post or get) directly to the web server programmatically from your application. All the information you need about the expected data to make this work is already in the html source.
|
|
|
|
|
I can detect the mouse clicks in/outside my application
I just want to send WM_PASTE using API to windows so it will execute the paste command.
----------------------------
I need to do that because the user needs to take some data from the customer then enter it to a webpage more than one time and this takes a long time so I want to the user able to store the data in my application then paste them into the webpage faster, this will save a lot of time and of course a lot of money.
I can handle it if the user used it with a control that don't allow pasting in on it.
Now all what I need is to send the paste command to windows successfully.
JusT LeT YouR MinD WorK
|
|
|
|
|
Not so easy. You need a global mouse hook to discover the mouse anywhere. When a click happens, you have to find out the type of the control clicked. In case of "common" textboxes, you can then send the keys for inserting from the clipboard.
It may fail with Java applications when they use "swing".
|
|
|
|
|
Don't post the same question in multiple places - it duplicates work and can annoy people.
You have already posted this in QA, so work with the version there.
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre.
Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
|
|
|
|
|
I didn't mean to duplicate my post in many places and if it done I'm sure it done by fault... sorry
JusT LeT YouR MinD WorK
|
|
|
|
|
Question -
There're many obfuscators in the market - what happen if you obfuscate an exe which is NOT signed with a strong name? Strong name - is if you want to install your dll's into GAC, or that you want runtime to check if the binary has been tampered with.
http://www.eziriz.com/help/source/main_panel.html[^]
Take .NET Reactor for instance, it can sign an exe WITHOUT a strong name, with anti tampering/anti disassembly options. In this case, what's the point of having a strong name?
MSDN says ...[^]
dev
modified 26-Aug-13 19:13pm.
|
|
|
|
|
You can always obfuscate a dll which is not signed.
You just can put it in the GAC.
An exe would normally not go into the GAC in any case.
|
|
|
|
|
Bullshit from "MSDN says"
"Strong names offer a powerful mechanism for giving .NET Framework assemblies unique identities. ... mentioned, the .NET Framework verifies the signature either when loading the assembly or when installing it in the GAC. Without access to the private key, a malicious user cannot modify your code and successfully re-sign it."
With all this complication, it has nothing against tampering (If you want anti tampering, buy obfuscation tool from vendor). Unique name? Why not I just read md5 signature? Why bother strong name?
M$ recent years has just been too busy inventing useless sh*t.
For those of you who want to read this bullshit[^]
dev
|
|
|
|
|
devvvy wrote: Why bother strong name?
I load my stuff using the strong name; the fact that it's unique makes it a bit harder to register a new dll on the machine with the same name.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
devvvy wrote: Why not I just read md5 signature?
Who told you a MD5 hash was unique to only one assembly? That's simply not true. It's rare that two different streams of bytes can come up with the same MD5 hash value, but it is possible.
MD5 is not considered secure anymore. It's too easily broken.
But, it's still just barely useful enough to be a factor in a multiple-factor identification scheme.
|
|
|
|
|
is there any signature based algorithms? I think strong name too much work
dev
|
|
|
|
|
Sign the .EXE with a certificate specifically created for code signing.
|
|
|
|
|
Obfuscation and strong naming serve different purposes.
|
|
|
|
|
for antitampering, use obfuscation tools
for unqiue names/id, seems like i'd prefer simple md5 signature over strong names as strong names takes too much time (sign all 3rd party dll's requires a lot of time) but some argue md5 not unqiue
wonder if all this complexity/additional work from strong name necessary - that really there's no alternative to md5, that we can just run a simple command and generate a unqiue id string like md5 for a binary
dev
|
|
|
|
|
Strongname signing - is for authentication.
Obfuscation - is for encryption.
You, yourself, can authenticate an assembly you are about to load. You need the public key of the assembly supplier, the assembly public key and hash (both stored in the assembly). Now calculate the hash of the assembly using its bytes. If the public key of the assembly matches the public key you know belongs to the supplier, and the hash of the assembly matches the hash you calculated with the public key of the assembly, the assembly can be assumed to be original.
Microsoft .Net performs strong name checking when loading, but it doesn't know whether the assembly's embedded public key is the right public key. That is for you to check.
The same goes for signed executables (VeriSign, etc.) - these all rely on the user being able to tell whether the public key in the executable is the right public key.
Btw. The authentication check only makes sense if all the assemblies to load are checked. Otherwise, a dependent assembly could be tampered with. That is why an assembly should not be strong name signed, if it is dependent on unsigned assemblies.
Hope it makes sense.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Thanks - do you think md5 is sufficient (and much simpler with much lower admin cost) than strong name?
Are you aware of alternatives than strong name and md5?
dev
|
|
|
|
|
Custom MD5 doesn't authenticate that the DLL is the right one so MD5 isn't even an option;
If you have Application A that depends on DLL B
Application A contains in the binary an MD5 sum value of say "12345"
DLL B in the binary has an MD5 sum value of say "12345"
there's nothing stopping an attacker from creating a new version of DLL B with MD5 sum of say "23456" And then just using a hex editor to modify application A to accept MD5 hash of "23456" so nothing is achieved
If; however; you attempt to do the same thing with strong named Application A and dll B, you won't be able to do it, as Application A will refuse to run when it's modified
Strong naming has nothing remotely to do with the MD5 hash of the file nor do they achieve the same thing.
|
|
|
|
|
Hi Matty,
In your example A is signed with information about B's signature, which builds a lovely hierarchy of signed assemblies. This is great tech.
However, if I decompile and compiles A, your users would not know - would they?
It doesn't matter whether the hacked A is signed or not. If the user never checks the signature of A against a public available source that is authentic to the user.
Don't be tricked into thinking that strong name signing is a solid automatic run-time authentication - neither are certificate signing. They both rely on the user initiating a signature verification using a "correct" public source - e.g. a public key or certificate.
Btw. I can recommend this post. he is much better with words than I am: http://blogs.msdn.com/b/ericlippert/archive/2009/09/03/what-s-the-difference-part-five-certificate-signing-vs-strong-naming.aspx[^]
Kind Regards,
Keld Ølykke
|
|
|
|
|
Totally agree;
The entire system hinges on validating the signature before you execute it.
My main point was more than a hand-rolled solution based only on an MD5 hash doesn't provide remotely the same features as strong signing does.
However; there are cases where run-time authentication using the strong signing is useful.
Consider following example;
You can easily grant .NET security permissions based on a particular publisher.
I grant only assemblies published by "MattyCo" access to read/write from MattyCo's super secret drive
If you decompile and recompile A with no or a different signature; the newly recompiled assembly they've sneakily placed on my machine isn't signed by MattyCo, can't access the drive, and no harm is done.
So I got a fair amount of benefit there using the inbuilt run-time authentication that .NET/Windows provides
(Also you obviously get none of these benefits just by using an MD5 sum..)
|
|
|
|
|
Yes, indeed I think your example is the way to use strong name authentication of assemblies as a windows user. Whether it is easier than MD5 checks of downloaded files is another discussion.
Btw. I wonder if this possibility is used by IT staff when managing shared workstations, or what other cases could be. I know there is some identity management when running Azure apps - don't know if it is linked to strong name signing. Would make sense though.
Kind Regards,
Keld Ølykke
|
|
|
|
|
If understand you right, you are asking whether I think MD5 hashes are great to verify that a downloaded file is authentic - e.g. like described here http://www.openoffice.org/dev_docs/using_md5sums.html[^]. I like this tech.
However, I don't think most users are able or care to do these checks. The problem here is that the user needs to authenticate the file herself, that is, to match the public available hash code of the file with a calculation she has to initiate.
If you ask me whether you should use strong name signing, my answer is yes. Not because it is a very strong security, but because it is a mechanism that runs by default for most users.
Again most users will not check the public available hash'es of the assemblies that they load, so whether they have been decompiled and compiled again by an evil person is not a question that can be answered by your users.
> Are you aware of alternatives than strong name and md5?
Not really for files. Sorry. I guess it is hard to enforce.
Between servers it is pretty common to know each others certificates / public keys. Messages are signed when sent and authenticated when received.
If you have code running at both server and client, you could add server authentication on the client side e.g. if your code is downloading files the files your code can authenticate the files against server certificates.
I think there is a gap here in the user experience that needs to be filled by a good standard and a handful of products.
Kind Regards,
Keld Ølykke
modified 30-Aug-13 6:41am.
|
|
|
|
|
Thanks for your thoughts first of all, I was hoping to see the most/more stringent argument for/against using Strong Name as supposed to md5 for "authentication" of binary.
"However, I don't think most users are able or care to do these checks. The problem here is that the user needs to authenticate the file herself, that is, to match the public available hash code of the file with a calculation she has to initiate."
I think as long as I publish the md5, that's end of my responsibility at least for the line of work that we're doing - I wouldn't go about signing all 3rd party library.
I do appreciate your argument however. It's informative.
dev
|
|
|
|
|
I need to my work (C#) projects with good unit tests. This code should have relative good coverage. I wrote relative, because good is depend on point of view  . I can wrote simple project on my self, but I need real world apps.
Thanks
|
|
|
|
|
I don't know what you are talking about, but if you need Unit Testing, get a free book by Marc Clifton. Unit Testing Succinctly[^]. What's your question?
I remain joe!
|
|
|
|
|
Links, names projects with unit tests where code is relative good covered.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
