Our device relies on a built-in windows driver (usbser.sys). Do we still need to go through WHQL testing or can we install in such a way that the user won't see a warning about not passing Logo testing? I found http://support.microsoft.com/kb/837637 but it's not clear to me if this will do what I want. Does it matter whether I use DPInst program or have my own program that calls DriverPackagePreinstall?
[Edit: changed "Our code" to "Our device" based on comment]
You don't need to sign usbser.sys (KMCS) but you still need to sign your .inf, because the matching of usbser.sys to your Hardware ID or Compatible ID is not trivial and it's your responsibility, so you should be signed on it.
You don't have to go through WHQL certificate on Windows Vista and higher. A code signing certificate from a known CA will suffice. This will raise a question of "Do you want to trust this publisher?". You can work around this by first adding yourself to the TrustedPublishers (see this question). (WHQL still has its benefits, e.g. you wouldn't have the above warning prompt.)
Still not a 100% sure but some general pointers:
follow http://msdn.microsoft.com/en-us/library/ff542476%28v=VS.85%29.aspx to create/test etc. an INF file and esp. http://msdn.microsoft.com/en-us/library/ff542605%28v=vs.85%29.aspx
WHQL is not only for drivers but for the devices themselves (see http://msdn.microsoft.com/en-us/windows/hardware/gg463175 and http://msdn.microsoft.com/en-us/windows/hardware/gg463175 ) so strongly recommended to avoid that warning AFAIK
Related
I'm a software developer who works as a freelancer, and my question has two parts.
First part:
I was working on a project then out of nowhere while testing on windows 10 VM windows security start blocking my app, I have a legit Bitdeferter and Malwarebytes on my main machine, and when I scanned my app (the EXE file from C# project) everything is clean, yet when I uploaded the file to virustotal.com it shows 5 detections
I start doubting my code and NuGet packages (I use Microsoft.AspNet.WebApi.Client and Newtonsoft.Json) so I removed them and to my surprise, I only got 2 detections out of 5.
I even create an empty Console app and still get those 2 detections, and my main machine still shows nothing as a virus.
So does that mean that my app is good but needs to be signed?
Second part:
If my issue is just a signing certificate, do I need as a developer to obtain that or my client, and then I only sign his/her app under his/her certificate?
Thank you.
Many engines treat VirusTotal samples very harshly, and any new executable has very low reputation (never having been seen before).
Therefore you will get lots of false-positives from VirusTotal when looking at your own new binary.
Signing is likely to help somewhat - at least there's a chance that you can build reputation in your certificate rather than each binary separately.
As far as I know, you get the signing certificate for you as a developer, although that might be different if you are providing source code and the client is building the end executable.
We used to have a binary running in user space built with VC++ /integritycheck flag which sets IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY flag on executable (see more here and here). We signed it with our old certificate and it run smoothly. Now we were given new certificate and binary is blocked by security check (defender prompt + log in event log).
Yes, we added certificate to our trusted store.
Yes, we used page hash (/ph) switch while signing.
New cert running fine if we enable test sign on a platform (through bcdedit)
The major difference seems to be that new certificate is not cross signed by Microsoft. Cross signing is no longer supported so maybe anyone knows if there's alternative or how to workaround it? Maybe /integritycheck flag for user space code is no longer valid?
Same issue we found at MSFT forum https://learn.microsoft.com/en-us/answers/questions/348812/signed-file-fails-to-start-because-of-bad-signatur.html. Still no precise answers how to solve it.
Ok
SO recently I've being having a lot of trouble with an application working in debug mode but not working in distribution mode.
Is it possible to use xcode debugging tools such as break points and variable tracing with an adhoc distribution build of an app?
If it's not how would one usually go about debugging such a thing?
Assuming that your crash logs aren't giving you any clues (you'll need to hook up to the device to get them) there are lots of things you can do.
But I'd start by looking at the crash logs ... the clues will be there and don't forget Apple make distribution crash logs available to you through iTunesConnect.
1) Copious logging is one thing. Lots of developers use a switch so that in debug, logs go to the console but for other builds they are dropped. Consider a different option where you log to a file instead. You could then push the log files to a remote server for debugging. It's a bit of a slog to set this all up, but once you've done it, you'll wonder how you ever lived without it.
2) Another option is to use Flurry and log events when you detect that things have gone wrong. This can cover more controlled problems when things aren't as expected rather than random crashes. This can be a useful feature for released apps provided your terms and conditions are clear about what data you are logging and why.
3) Make sure you do a clean build, I'm sure you've already done this, but sometimes it clears these issues.
4) Are you using external libraries / modules? I've come across issues with older versions of TT where the arm6/7 build settings were wrong and this was causing issues for distribution builds. Basically check through the build settings for each profile and make sure it is what you expect.
5) Suspect a race condition. In distribution mode (often because the logging is turned off) you will find that your application runs a little bit faster. That can reveal timing issue bugs in badly written code.
So yes ... there is a lot you can do ... you just can't attach the debugger ;-)
Not possible to debug an application in distribution mode.
The build configuration difference between Distribution, Debug, and Release is really whatever parameters you have set for that in XCode. If your Distribution config is giving you problems and the release isn't, the easiest way to fix it is to go back through Apple's steps on copying the Release config and making the changes to make it a Distribution config, like you did originally.
The alternative is to go through every line of the configurations for Release and Distribution and find what's different. The other way is a LOT faster. :)
When we click the check box "Install files for complex script and right to left languages (including Thai)" in Regional and Language settings what exactly happens?
Changes to registry keys?
I noticed that it installs some .fon files and keyboard dlls.
Is this totally necessary if one just wish to read complex script on Windows XP? My test inside VirtualBox as Windows 7 as the host OS seems to indicate that for reading Complex Script need not be enabled. Yet that's not what all the literature on the subject says. What's going on?
Update:
http://hi.wikipedia.org should not be readable if Complex Script is not enabled
http://hi.wikipedia.org/wiki/विकिपीडिया:Devanagari_Help
Problem is that it is readable.
Font files. Rendering libraries ('Uniscript'). Input methods. Certainment beaucoup de cle-registry. (Certainly lots-o-registry-keys.)
Note that IE will tend to get things right even when other things don't, since it builds in a good deal of fancy-pants rendering. Try, oh, Outlook, or some simple sample Win32 program.
Motivation — I had a new version of my Cocoa application ready that worked fine on all beta testers' machines. So I released it. Turns out that a crucial feature simply doesn't work on anybody else's computer. Yikes! Yes, read that again: I released software that didn't work.
Cause — Users who had used previous versions my app (read: all my loyal beta testers) already had a folder ~/Application Support/MyApp/ from an older version. Due to the critical bug in the new release, this folder was necessary for the software to work. And for everybody else, because the folder did not exist, it didn't work.
As you can imagine, this is extremely embarrassing, and I want this to never, ever, happen again.
Remedies? — The straight-forward way to ensure this, of course, is to actually download and install it on a "clean" machine just before you publish a new release. But this seems impractical, because in time I will run out of friends with a Mac who have never tried my app yet (eventually all will have ;-)), and because I'm not eager to "format c:" my Mac before every single release…
This is where I need your help:
How can I ensure that a user who has never used my software before will get the same results as someone who has?
Virtual machines (VMWare Workstation, etc.) can be useful for testing clean installs of applications. You can start up a new virtual OS, install your stuff, test it, then delete the VM when you're done. There are ways to automate the spinning-up of a VM as well, which can make your life even easier.
Another thing to do is to determine all the prerequisites your app requires, and add checks for these things at startup. If something is not setup right, you can either attempt to set it up within your code, or inform the user to do it.
A more lightweight approach might be using tools like AppZapper to get rid of everything — temporary files, preferences, cache, history, etc – related to the app to test.