Finding user passwords from RSView ME application

Hiya. I've been a lurker here for years, but now I have a question for which I have no answer.

I have an RSView ME application that is installed on 9 operator panels in my plant. I have both the .apa and .mer files for this application (restored the .apa with all options as well), but I ran into an issue a few weeks ago: the engineer (several generations back) who set up the HMI included security to keep operators from changing maintenance settings, and another level of security to keep operators and maintenance personnel from changing engineering settings. Sounds great, but I have neither password.

I tried guessing the passwords, but with no success. I asked the previous engineer for my area, but he apparently changed engineering settings via the PLC. I would like to figure out the passwords to avoid going around the back way, but haven't found a way to do it. I realize I could just set new account passwords in studio and copy the .mer files to all 9 panels (or just change settings via the PLC), but that would be like cheating on a test.

Has anyone else run into this issue, and did they solve the puzzle?

tsmith35 said:

Hiya. I've been a lurker here for years, but now I have a question for which I have no answer.

I have an RSView ME application that is installed on 9 operator panels in my plant. I have both the .apa and .mer files for this application (restored the .apa with all options as well), but I ran into an issue a few weeks ago: the engineer (several generations back) who set up the HMI included security to keep operators from changing maintenance settings, and another level of security to keep operators and maintenance personnel from changing engineering settings. Sounds great, but I have neither password.

I tried guessing the passwords, but with no success. I asked the previous engineer for my area, but he apparently changed engineering settings via the PLC. I would like to figure out the passwords to avoid going around the back way, but haven't found a way to do it. I realize I could just set new account passwords in studio and copy the .mer files to all 9 panels (or just change settings via the PLC), but that would be like cheating on a test.

Has anyone else run into this issue, and did they solve the puzzle?

Click to expand...

Hi tsmith35, welcome to (EDIT: posting on) the forum!

Yes this is one of the more annoying FactoryTalk/RSView issues, in my opinion. (Picking the most annoying FactoryTalk bug is kinda like picking the best Beatles song, there's just too many to choose).

I stumbled on a work-around to this issue recently when we had to replace the dept's programming laptop. If the .mer file that you have was created with ver >= 5.0 then you can restore the .mer back to a development file. When you do this in the Application Manager, the initial dialog box gives you the option to "restore run-time application's FactoryTalk Local Directory to the development computer". From the FTView v6.0 user manual, page 14-6:

If desired, you can also restore the run-time application’s FactoryTalk Local Directory to
the development computer. The development computer’s FactoryTalk Local Directory
will be backed up, and the run-time version will replace it. If you choose this option, make
sure you have access to the run-time FactoryTalk Local Directory. For more information
about the FactoryTalk Local Directory, see Chapter 11.

Click to expand...

Now when I did this, I had a new laptop with a fresh, new copy of FTStudio and no Local Directory to worry about overwriting, only a bunch of .mer files retrieved off the department terminals. This method populated the user groups and ID's folder of the project tree in FT Studio.

Although come to think of it, this still doesn't give you the passwords in any way that you can view them. I already knew them, just didn't want to have to enter them all manually.

I would say your best bet is to just change the passwords and give out the new info to all those who need to know. Since nobody at the plant knows the old password anyway, what's the harm in changing it?

Cheers,
Dustin

lol Dustin! I couldn't agree more! (bugs)

When you restore with the local directory, you will be prompted to enter the username/password that is in the application. Without this, you won't be able to restore it.

If you restore without the local directory, it will scramble the user accounts (they will be unusable). However you don't need the password to restore it. Once it is restored, you can deleted the scrambled accounts and create new ones. I think you will have to pay attention to which security codes were given to the scrambled usernames so that you can apply the same ones to your new accounts.

At least this is the way it seems to work in my experience...

Cheers,
Other Dustin

Thanks for taking the time to reply, guys! Although the .apa file just used the default login & (blank)pw, allowing me to restore everything, I think I'll do as recommended and just set up new passwords. I'll save the detective work (finding the original passwords) for when I have spare time...

I concur with all of the above. Without the original machine on which the .mer was created AND the factory talk directory username and password, you are pretty much hosed. Since yours took a blank password, it should have allowed you to see them, but the easy thing to do is just create new ones as suggested.

Most of my FTView Studio memories have been suppressed to a deep dark spot in my psyche where only a good hypnotist could retrieve them. I dread the fact that I will have to learn how to install it on my new win7 64 bit PC (in a HyperV virtual machine) in the next week or two...

Passwords - ugh - New Idea

Recently, a new customer expressed desire to avoid passwords which can be verbally transmitted to every Tom, Dick, and Harry within earshot, or even written in "magic-marker" right next to the HMI.

We abandon Panelview Plus passwords. We installed a card-swipe reader next to the HMI. Each employee carries a personal badge for plant entrance, and time-clock purposes. The HMI screens default to a look-only format. If a change needs to be made, an employee badge card-swipe is required. The card swipe brings in the employee ID and if authorized the PLC creates associated visibility based on employee authorization level, and makes appropiate items visible and active.

We have card-swipe history data logged in the plc, and supervisory PC data collection. The swipe history is also prominently displayed on the HMI, giving employees fair notice that thier actions are being recorded.

The card-swipe reader is quite affordable. (ID Tech)

It can be magnetic only, It can be visible bar code only, the one we have can also read "infra-red" protected barcodes, to foil photo-copy forgery.

The card-swipe is also FASTER than numeric entry. Just swipe and go.

Thanks for that alternate approach, Plastic.

For better or for worse, RSI uses the same encryption method that Windows uses to encrypt passwords. That's why when you delete a User, the "garbled" username shows up in the FactoryTalk User Permissions window. That's the encrypted Username.

But RSI doesn't store the FactoryTalk passwords in the same place that Windows does, so the usual password dump and rainbow tables methods that I can use to crack a simple Windows XP password aren't easy to employ on FactoryTalk.

If your users are Windows-linked Users, then you're going to be able to find them in the usual Windows locations, but it sounds like they are not (because they were able to be backed up in an APA file).

I recently had a bunch of FactoryTalk Users that could not log into a new application (migrated from 5.10 to 6.10 ); we were absolutely certain that we were entering the correct passwords, and we could log into the PC runtime successfully.

The fix turned out to be going into FTView Studio, removing all the Users from their Groups, then adding them back in. Ta-daa. There was a Knowledgebase article that hinted at this, but I would not have arrived at it myself.

I'd like to see RA implement smartcard log-ins for Windows-based users, but that would probably involve a lot more Windows CE work than I think the developers and testers are up for.

I like the card swipe idea (would have been great back at my last job!). Everyone has their RFID card on them while at work, but 99.9% of operator interaction with screens in my area don't require elevated privileges (I'm the 0.1%). The screens (PV Plus 1000) are individually connected only to the SLC 5/04 that each controls.

Still, it would be nice to track the "who & when" whenever any changes are made. Plastic, how did you read & use the card ID? Just curious more than anything.

ID Tech

ID Tech makes all kinds of POS Card Readers. Pleas note POS is an acronym for "Point-Of-Sale". (Not Piece-Of-_hit)

We get them with RS-232, default 9600,N81. An employee badge either will have a mag stripe, or a barcode stripe, either of these will swipe rapidly. We have not used any RFID employee badges to-date.

We have a supervisory screen on the HMI that allows the plant managment to enter allowed employee ID numbers, and set thier associated user level from 1-9. Then we use visibility on the panelview plus to make pushbuttons and numeric entries visible based on the level of the most recent badge swiped. The swipe times out after about 5 minutes.

I have my own badge, and actually prefer to swipe, and go, vs entering a password.