Wednesday, July 20, 2011

HID VertX V2000 - Heartbeats, Provisioning Access, and Local Cache

If you've been following my last couple posts, you know that the newest thing on my desk is the HID VertX V2000. I downloaded the trial version of WebBrix and set up my own little lab to play around with.

I wanted to figure out how the VertX handled allowing/disallowing access to specific cards. The first thing I did was set up Wireshark to check the traffic between WebBrix and the VertX. To my surprise, everything between the two is unencrypted, so no big hurdle there.

The first thing I noticed was that the VertX sends a heartbeat to WebBrix every 20 seconds (configurable option) to make sure its still connected. I sort of expected this since the heartbeat configuration was mentioned throughout the deployment documentation, so after letting communication happen naturally for a few minutes, it was easy to pick out which traffic was heartbeat related. I haven't deciphered all the fields but this is what is sent:

    Heartbeat From VertX to WebBrix: 1080;0087;V2000;IP_ADDR;MAC_ADDR;VertXController;05:53:17 IST 07/20/2011;
    Response From WebBrix to VertX:
    0080;0010;
I put an authorized card up to the reader and watched the communication in wireshark and this is what came across:

    Authorized Card Read from VertX to WebBrix 1065;0084;1060;000304;1;20;2;20;245;05:54:16 IST 07/20/2011;MAC_ADDR;0;0;5^
    WebBrix Response:
    0067;0010;
Fair enough, next was an unauthorized card read:

    Unauthorized Card Read from VertX to WebBrix: 1065;0118;1060;000306;2;20;1;22;245;06:17:45 IST 07/20/2011;MAC_ADDR;0;0;00263F9C000000000000000000000000;26^
    WebBrix Response:
    0067;0010;


So that was confusing to me. How could an authorized and unauthorized card both produce the same response?

It just so happened that last night we had our monthly office bar visit, and i was discussing the responses with Par, one of our IR rockstars. By performing a couple simple test, it was clear that the VertX cached card values locally:

  • Read successful card. Observe door unlock
  • Unplug network cable. Observe door unlock
  • Reboot VertX. Observe door unlock

So I must have missed something in the initial handshake. I took a unprovisioned card and enabled access for it this is what i saw (new card ID is 00263F8E):

    Provisioned new card (WebBrix to VertX)
    0023;0026;0;1;00263F8E;-1;
    VertX Response:
    1023;0016;-1016;
    WebBrix Response:
    0024;0104;0;1;00263F8E;0;1;7;2;0;0;0;0;0;0;0;0;0;0;0;0;2011/07/20-06:32:00;2030/12/31-23:59:59;0;0;0;0;1
    VertX Response:
    1024;0012;0;

So it looks like the backend system (WebBrix) sends access data when its provisioned, then the VertX caches it.

Local Storage of Card Values

A quick look on the VertX revealed that there are two files which store this data:

/mnt/data/config/AccessDB
/mnt/data/config/IdentDB

I haven't figured out exactly what the AccessDB does (presumably maps cards to doors?), but if you open the IdentDB in a hex editor you can see the valid CardIDs:


This means, if you have access to a VertX V2000, you can easily pull this file and have the entire cache of valid card IDs!

Next on the list: Seeing what happens when you manually add a card value into the IdentDB.

No comments:

Post a Comment