Related
I bought two VeriShield file signing cards. Unfortunately neither of the cards work--they each give a "wrong pin" error.
PIN Entry Try is 3. Do we see any message if the cards are locked? Can we sign the file as default and download the app to terminal? Also will there be any ownership issues if I sign the files as default for development?
Let's start with why you are getting the wrong PIN. There could be a few different reasons:
VERIFY YOU HAVE THE RIGHT PIN
When you first got your cards, each one should have come with a welcome letter telling you what the PIN is for that card. Note that each card will have a unique PIN and that you can't mix the two up (that is--if you try to enter the PIN for card 1 on card 2, it won't work and visa-versa).
NOTE: VeriFone is not infallible--when I was in my VF training class, one student got a pair of cards that didn't work and the teacher decided he must have had the wrong PINs sent to him. The only remedy is to contact the VF rep from whom you purchased the cards.
CHECK FOR PROPER INSTALLATION
Are you using the latest version of the File Signing Tool (FST)? I believe the latest version is 04.01.04. If you have an older version, go to the DevNet page and get the latest.
I have a note saying that the FST installer needs to be run using administrator privileges, though if I remember correctly, it will elevate itself to administrator, so this shouldn't be off too much concern. My note also says that during the setup, you may get a message about not being able to change folder permissions, but not to worry about it.
Once you have the FST installed, set it to always run as administrator. This IS important and it won't work if you don't.
The first time you run FST, you'll need to set up 2 officers and give them temporary passwords (you will be required to change the passwords on the next log-in). Note that for some reason, VF decided to make the USER NAMES case sensitive (not just the passwords).
Once those users are set up, log in as those users and change the password to the "permanent" password ("permanent" as in you don't have to change it again if you don't want to). If I'm not mistaken, you can't use one of the last (3?) passwords, so you can't use the same as the temporary password you set them up with.
Now log in with BOTH users that you set up and choose Change PIN.
If you are still having trouble, contact your VF rep.
PIN Entry Try is 3. Do we see any message if the cards are locked?
I know that you do have a very limited number of retries before the card locks itself, but seeing as mine worked on my first try, I really couldn't tell you what happens as you approach and/or cross that limit.
Can we sign the file as default and download the app to terminal? Also will there be any ownership issues if i sign the files as default for development.
That depends on what type of terminal you are using. If it is a Verix or VerixV (so like 3740, 3750, 3730, 510, 570) then, yes you can use a default signature (that's what I regularly do on these terminals) and no, it won't cause any problems, assuming everything else that is running on that terminal is also default-signed. If you are using some things that ARE secure-signed, then I believe that all items must have the same sponsor to run on that terminal (I know that's true with the eVo platform, but I'm just assuming on the Verix/VerixV platforms).
HOWEVER, if you are running an eVo terminal (like 520) then you MUST use a secure signature--eVo will not accept a default certificate. What's more, once a secure-signed program is loaded into the terminal, then ALL future applications MUST be signed using a certificate with the same sponsor, or that program will not run. (One exception--if you run the certificate removal program, then AFTER it runs, you can load a new sponsor on. However, note that the removal tool will not run unless it has been singed by the same sponsor).
Trying to use a default certificate should not cause any ownership problems, it just won't run. I know that if I try and use the default certificate on my terminal that already has a sponsor, it will compare the file signatures after download and say they don't match. I haven't tried it on a blank (no sponsor cert yet) eVo, but I suspect you would get roughly the same result.
Those file signing cards have gotten expensive recently, so if yours aren't working, then I'd get with the VF rep quickly and try to get it fixed--the longer you wait, the less likely they'll help you.
I am not a programmer. I have some software at work that keeps crashing on me. I used the Visual Studio debugger last time it crashed and found out it was unhandled exceptions.
The first unhandled exception is at 0x0048ADF0 in Cyclone.exe and is an Access violation writing to location 0x00000003.
My research leads me to understand that this is the program trying to write to memory that the process doesn't have permission to.
When running the debug in Visual Studio, after the access violation exception there is a long list of Unhandled exceptions similar to this "...at 0x776C016E (ntdll.dll) in Cyclone.exe: 0x00000000: The operation completed successfully." with different addresses.
Is there any way I can fix this without being a programmer? Some sort of modification to the app files or settings, or a tutorial or something.
No, there is no way. It's not different from asking if you can drive a car without knowing anything about driving.
Sounds like you need to report the problem to the person or company who provided it. What you need to do, however, is give them enough information to understand the problem and fix it. This includes:
what version of their program are you running
which computer operating system (e.g. Windows) and which version (e.g. 7)
precisely what steps you have to take to make the error occur
whether you have changed anything recently, e.g. by installing Windows Updates or changing your anti-virus protection
precise details of any error messages you see, ideally by copy/paste or by providing a screenshot of the erro
anything else you think might help them to help you
Be prepared for them to ask you additional questions, or try some tests to help figure out the cause and a way to solve it.
Your research sounds about right but I don't think there is much anyone here can do to help (unless they happen to work on the application).
Your best bet would be to look for a "Help" or an "About" screen and contact the people who wrote it with this information
I am working on project in which I use Sipek Voip for connecting to Freeswitch. Here is the situation:
I have a Sangoma A400 hard. I compiled Freeswitch for Windows and now it works perfectly.
I have also created a Softphone using Sipek Voip SDK and it works well with Freeswitch.
The problem is that, when I have an incoming call, instead of showing the callers number, I get mod_sofia.
I looked at Sipek and all it gets from pjsip is a string containing <sip:mod_sofia#192.168.2.10:5060>.
So I went to pjsip and tried to pass the actual phone number to Sipek. I found out there is a function called pjsua_call_on_incoming which handles an incoming call.
It takes an argument of type pjsip_rx_data. It has a string field (rdata->msg_info.msg_buf) which contains the whole message. I tried to replace <sip:mod_sofia#192.168.2.10:5060> with the actual number, but it has no effect.
Does anyone have any idea how to fix this?
You can check this link for tracking the issue. Unfortunately there are hardly any people who can help you out with Open source projects "for free" even on a forum. I just speak from my personal experience. I am facing the same problem, and cannot figure it out till now, though I have solved many issues that I used to face with SIPEK, all on my own.
I've not understood the root of your problem is in FreeSWITCH or in sipek/pjsip.
This entry on FreeSWITCH wiki could help you debug the sip stack in FreeSWITCH:
http://wiki.freeswitch.org/wiki/Mod_sofia#Debugging_Sofia-SIP
in a way similar to a wireshark capture.
I'm sorry I don't know how to help you trace down the parsing/rendering of msg_info.msg_buf in pjsip.
Add sip_contact_user=xxxx in your dialstring.
i am developing a video player i silverlight
i wanna something to prevent recording or screen capturing
i thought about hacking the windows APIs and stop my program from running if there was any of those capturing software asking the user to close it first but i donno how to do this
is there another solution ??!!!!
It's simple not possible. If you try it, you're only going to annoy people.
Even 'hacking the windows API' would not work, since the OS itself could be run inside a VM.
I hate to be a downer, but task is impossible to fully accomplish.
If you were somehow able to hook the keyboard (from a silverlight app no-less) I would certainly hope that whatever AV the user is running would throw up some red flags.
Also what if the user doesn't use the standard (alt)+prtscr? A third-party tool might use a different key-combo. Also, I've written a screen-grabber with the GDI+ API, and there's no way to disable something that low-level.
What about attached capture-cards? What if your app is running in a VM or over remote-desktop?
If you are that deeply concerned about protection your HD content, watermark it, or make the user pay for it first.
All-in-all, as soon as your content's data enters your user's computer, they can duplicate it.
You could go about using a key hook system, stopping the user pressing the print screen key on the keyboard, that would be a start. There aren't many systems which stop users from print screening video specifically. You might want to try just watermarking your video instead? At least then people know that the video was originally sourced from you.
The solution is not to allow your application to run on a computer, but instead target a device such as a phone. Computers will always allow some kind of screen capture and video capture but this is much harder and less likely to be tackled if you restrict to only playing on certain devices.
How badly do you need this? There are many ways to defeat screen capture protection: for instance, aiming a video recorder at the computer screen (or looping output to a TV with a capture card, etc. etc. etc.)
Go for a commercial solution if you really really need this: don't have any experience with those myself, however.
There's a simple way to read the registry and get the UAC status from there. The only problem is that if you are not an administrator user or the UAC is ON then you can't read that particular key.
Is there a way (API, etc) to get the UAC status accurately without having to read the registry?
Sample code is always appreciated.
Thanks!
jess
EDIT:
I'm starting a bounty. PLEASE PLEASE if you are going to answer do not tell me how I shouldn't care about the UAC status and that the code should be independent of the UAC and how microsoft is so goody goody.
From the internets:
HANDLE tokenHandle;
OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &tokenHandle);
DWORD tokenInformationBufferLength = 0;
TOKEN_ELEVATION_TYPE tokenElevation;
GetTokenInformation(tokenHandle, TokenElevationType, &tokenElevation, sizeof(tokenElevation), &tokenInformationBufferLength);
Ok, building the answer on what ssg/comments already said:
http://www.softblog.com/2008-02/vista-tools/
This checks both elevation and UAC status.
First as
How can I detect if my process is running UAC-elevated or not?
already mentions, it will test the ElevationStatus. After that, it
tries to start a subprocess with elevated status which will fail
if standard user is logged in, determining the UAC status.
And no, it does not use the registry.
Not quite where you're looking, I suppose... but if the registry read returns an access failure on the key, that is actually the answer you're looking for -- UAC is enabled.
What I did to solve this problem, was if I had admin rights according to the API call I read the registry value (UAC provides false to admin rights check) and if I did not have admin rights I tried to make a new key in HKEY_LOCAL_MACHINE\Software. If that succeeded, UAC was on and I removed the key.
First off, you don't really want to seek out a way to "get around" the security features of the operating system. Even if you do find a solution that works right now, Microsoft can (and does) change these kinds of features with Windows Update and will break your app in the future. Fighting the security features is an uphill battle and it will be a continuous headache for you. While I would love to hear more of your questions on StackOverflow :) it is most likely not the path you want to go down.
That said, I think you are going about the issue wrong. If your manager doesn't want you to fix the problem, then your manager has accepted the problem. Just mark the whole application as "must run in administrator mode" and be done with it. The users will get a single warning at application start and then the app will run for them. Here's a link to show you how to set this option.
Of course, if you're users don't have admin rights to their own machine you are basically out of luck.