Managing the BlackBerry Device Firewall Remotely... Possible?

Over the past few weeks as I was playing with setting device options remotely, I made a few mental notes when encountering databases (i.e. configurations) backed up to the SQL db. One of these was 'Firewall Options'.

I particularly noted this one because I have been looking for a solution to the firewall popups that appear on our user's devices. Overall of course the firewall is a good thing, but I like to keep the experience of our users seamless whenever possible, and incomprehensible (to the user) firewall popups do not make for a seamless experience.

One example of this is the RSA SecurID software for our BlackBerry devices, which we deploy so our users do not need to carry around a hardware token. The first thing this software does when installed on the device is listen for a software token which is wirelessly pushed to the device via a separate app.

This listening process constitutes a 'server' on the device, so upon installation we see the following firewall popup:



Now if I am pushing this software from the server to a device out in the field, then based on this screen the end user will be confused as to what to do. 80% of the time they may choose correctly and scroll down to click allow, but that other 20% may result in a support call.

So is it possible to:

1) Set the 'Allow' rule in the device's 'Firewall Settings' database in SQL
2) Push the 'Firewall Settings' configuration down to the device
3) Push the application and have it immediately begin listening for a token without user input?

Let's find out!

First we will monitor the SYNC log again to see if anything gets backed up to the server when an option on this firewall prompt is selected.

The first thing I notice is that if I leave the "Don't ask this again for:" box unchecked, then nothing happens... I see no log entries on the server side. If I reset the app and enable the listener again, this time choosing to check the box, however:


... voila! I do see something coming through to the server:

[60000] (02/11 11:50:51.111):{0x1710} [ODBCRecord::DoSetValue] DATA = "DbVersion[0] Data[0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000] UserConfigID[17] DatabaseName[Firewall Options] UID[1] ".

This tells me that my hunch was correct, and that any saved settings are stored in the 'Firewall Options' configuration, and therefore backed up to the server. Good news!

So let's now reset everything and query the 'Firewall Options' configuration to see the default value as compared to the updated settings:

0x1100000005000004000003000002000001000000 (Default)
0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 (RSA Allowed)

It looks like the first numbers were changed from 11 to 27, then a bunch of numbers were inserted, extending the configuration string. I am guessing that this new set of numbers uniquely identifies the SecurID server application and the 'Allow' setting I chose.

If we reset the app, then choose 'Deny' here is what the string becomes:

0x270000010107536563757249440001046874747000060000000005000004000003000002000001000000

Everything is the same except for a single number, the '2' about 2/3 of the way through the string has changed to a '6'. So perhaps a '2' means allow, and a '6' means deny. Let's try clearing everything out, and then pushing the 'allow' string to the device before the software push:

use BESConfig
UPDATE SyncBackupRestore SET Data=0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 WHERE UserConfigID = 17 AND DatabaseName = 'Firewall Options'
UPDATE SyncConfig set SyncType=1 WHERE UserConfigId = 17 AND SyncDataSourceId=11109
go

Now we reload the application, and...


Bummer.

Guess I'll have to keep digging on this one...

[Update 2/13/08]
I have been gently reminded of the use of application control policies by a fellow blackberryforums.com member, ACJones. By setting a policy on the software configuration for the RSA SecurID software, and modifying the 'Internal Network Connections' option from 'Prompt' to 'Allow', you can avoid the initial firewall prompt completely upon OTA installation!



I have tested this and it works flawlessly. Thanks AC!

Managing BlackBerry Configuration Settings Remotely - Putting it all Together

Now that we know how to update the device settings, let's see how it works in a real world scenario. I have just nuked, reloaded, and reactivated my test 8700g with 4.2 OS - here is the before shot of the relevant configuration screens:


Now let's push down some common changes to our device settings:

1. [Messages Options / General Options] Hide Filed Messages = Yes (default = No)
2. [Messages Options / General Options] Hide Sent Messages = Yes (default = No)
3. [Messages Options / General Options] Keep Messages = Forever (default = 30 Days)
4. [Messages Options / Email Reconciliation] Delete On = Mailbox & Handheld (default = Handheld)
5. [Calendar Options] Initial View = Week (default = Day)
6. [Calendar Options] Keep Appointments = Forever (default = 60 Days)
7. [Address Book Options] Sort By = Last Name (default = First Name)
8. [Options / Date/Time] Time Zone = Central Time (-6) (default = Casablanca (GMT))
9. [Options / Screen/Keyboard] Backlight Timeout = 2 Min. (default = 30 Sec.)

These modifications will require the following sequence of SQL updates (you will need to replace the '15' UserConfigID with your target account's UserConfigID in your SQL DB) :

use BESConfig
UPDATE SyncBackupRestore SET Data = 0x550000010101000001010101000301010800014465736B746F70000A000
2543336323538313330000100030101000A00020005FFFF01000601020008
01000100090102000B000002000C000002000D000001000E00000000
WHERE UserConfigID = 15 AND DatabaseName = 'Message List Options'
UPDATE SyncBackupRestore SET Data = 0x270000000000001C02FC0300000000010000000F0000000101000500000
00100FFFF0000000F00000001 WHERE UserConfigID = 15 AND DatabaseName = 'Calendar Options'
UPDATE SyncBackupRestore SET Data = 0x0A000001010100000000000100 WHERE UserConfigID = 15 AND DatabaseName = 'Address Book Options'
UPDATE SyncBackupRestore SET Data = 0x040001000000000400021400000001000302 WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -447168820
UPDATE SyncBackupRestore SET Data = 0x1000019A71C67ACBC67AB400000002000000000E00018131D8CDC28BB8
B90000000700000D0001D30CB969B820BFDD0000000600100001C2C1986B
11CE32B000000002000000780D0001BDAAFA49FFAD48CC00000006011000
013E3CBC03163D39CF00000002000001C24F0001CB2088784AFC39CC0000
000000416A6176613A2F6E65742E72696D2E6465766963652E7468656D652
E626264696D656E73696F6E5F7A656E5F333230783234305F772E5468656D
65466163746F72790D0001416028234B233EA70000000600100001F5006E1
93847CE260000000200000001100001BD91E3D465E4816900000002000000
00100001EBB9DE74CE5F773800000002000000322600011F0091A81B93E1C
30000000000186E65745F72696D5F6170706C69636174696F6E5F6D656E75
08000138D4D5F7DC80C5472E0001DA36AA198C1233A40000000000206E65
745F72696D5F62625F70726F66696C65735F6170702E50726F66696C65734
F00019B05812B5A1A15DC0000000000416A6176613A2F6E65742E72696D2
E6465766963652E7468656D652E626264696D656E73696F6E5F7A656E5F33
3230783234305F772E5468656D65466163746F72790D0001F33AFBD074DB0
7F100000006001000016B506A6FCD9D596A00000002000000011000012ECB
C575BEF57F3E00000002000000C80D0001094AC736D16697C800000006001
000011762E2440C4D5D510000000200000064080001E8D6CB484814CA60
WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -1321243196
UPDATE SyncConfig set SyncType=1 WHERE UserConfigId=15 AND SyncDataSourceId=11109
go

This will kick off a one way sync from the server to the device, pushing all the configuration databases managed by the Backup component. It will take less than a minute for the SYNC process to pick up on this change, and about another 30 seconds or so to re-sync all the settings. [sleep 120] Now back to our handheld... it appears that all changes (in green boxes) have been picked up:


Now we must be sure to run the following command to restore the device to server synchronization:

UPDATE SyncConfig set SyncType=3 WHERE UserConfigId=15 AND SyncDataSourceId=11109

If we didn't do this, then any configuration updates from the handheld would not be backed up to the server. Actually, this might be an interesting option to employ for some firms who want total control over the handheld... one could schedule a daily push to refresh settings to the organizational standard settings to discourage end-user customization.

All of these commands could be easily scripted by putting them in a text file such as 'PushSettings.sql' and using the OSQL command's -i switch, i.e.:

osql -S sqlservername.company.com -U sqlaccountname -P sqlpassword -i PushSettings.sql

So that's it... We've gone down the rabbit hole into the depths of the BES SQL DB in order to discover some of it's secrets, and we came away with a method of pushing normally hidden device configuration settings over the air. Have fun, but remember to backup your SQL database regularly and TEST TEST TEST your scripts outside of production first!

Managing BlackBerry Configuration Settings Remotely - Part Five

Here are the options for the Calendar, first with default settings, then with the individual options enabled along with the resulting Data string:


[Default Settings Above]
0x270000FFFFFFFF1C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001

[Initial View: Week]
0x270000000000001C02FC030000000001000000
0F0000000101000500000001003C000000000F00000001

[Initial View: Month]
0x270000000000001C02FC030000000001000000
0F0000000201000500000001003C000000000F00000001

[Initial View: Agenda]
0x270000000000001C02FC030000000001000000
0F0000000301000500000001003C000000000F00000001

[Initial View: Last]
0x270000000000001C02FC030000000001000000
0F0000000401000500000001003C000000000F00000001

[Enable Quick Entry: No]
0x270000000000001C02FC030000000001000000
0F0000000000000500000001003C000000000F00000001

[Default Reminder: None]
0x270000000000001C02FC030000000001000000
FFFFFFFF0001000500000001003C000000000F00000001

[Default Reminder: 0 Min]
0x270000000000001C02FC030000000001000000
000000000001000500000001003C000000000F00000001

[Default Reminder: 1 Hour]
0x270000000000001C02FC030000000001000000
03C000000001000500000001003C000000000F00000001
(Minutes in hex: 3C = 60 decimal)

[Default Reminder: 1 Week]
0x270000000000001C02FC030000000001000000
060270000001000500000001003C000000000F00000001
(Minutes in transposed hex: 2760 = 10080 decimal ; 10080/ 60 = 168 hours / 24 = 7 days)

[Snooze: None]
0x270000000000001C02FC030000000001000000
0F000000000100FFFFFFFF01003C000000000F00000001

[Snooze: 1 Min]
0x270000000000001C02FC030000000001000000
0F0000000001000100000001003C000000000F00000001

[Snooze: 10 Min]
0x270000000000001C02FC030000000001000000
0F0000000001000A00000001003C000000000F00000001

[Snooze: 30 Min]
0x270000000000001C02FC030000000001000000
0F0000000001001E00000001003C000000000F00000001

[Start of Day: 8 AM]
0x27000000000000E001FC030000000001000000
0F0000000001000500000001003C000000000F00000001
(Minutes past midnight in transposed hex: 01E0 = 480 decimal ; 480/60 = 8 hours)

[End of Day: 6 PM]
0x270000000000001C0238040000000001000000
0F0000000001000500000001003C000000000F00000001
(Same as above, 0438 = 1080 decimal ; 1080/60 = 18 hours or 6 PM}

[First Day of Week: Mon]
0x270000010000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001

[First Day of Week: Tue]
0x270000020000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001

[Confirm Delete: No]
0x270000000000001C02FC030000000000000000
0F0000000001000500000001003C000000000F00000001

[Show Free Time in Agenda View: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000000010F00000001

[Show End Time in Agenda View: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000000

[Keep Appointments: 15 Days]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001000F000000000F00000001

[Keep Appointments: Forever]
0x270000000000001C02FC030000000001000000
0F000000000100050000000100FFFF0000000F00000001

[Wireless Synchronization: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000000003C000000000F00000001

[Show Tasks: Yes]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000100000F00000001


Now for the Address Book:


[Default Settings Above]
0x0A000001010000000000000100

[Sort By: Last Name]
0x0A000001010100000000000100

[Sort By: Company]
0x0A000001010200000000000100

[Confirm Delete: No]
0x0A000001000000000000000100

[Allow Duplicate Names: No]
0x0A000000010000000000000100

[Wireless Synchronization: No]
0x0A000001010000000000000000


And finally, Tasks:


[Default Settings Above]
0x0F000000000000000000000101FFFFFFFF01

[Sort By: Priority]
0x0F000001000000000000000101FFFFFFFF01

[Sort By: Due Date]
0x0F000002000000000000000101FFFFFFFF01

[Sort By: Status]
0x0F000003000000000000000101FFFFFFFF01

[Confirm Delete: No]
0x0F000000000000000000000001FFFFFFFF01

[Snooze: 1 Min]
0x0F0000000000000000000001010100000001

[Snooze: 10 Min]
0x0F0000000000000000000001010A00000001

[Snooze: 30 Min]
0x0F0000000000000000000001011E00000001

[Wireless Synchronization: No]
0x0F000000000000000000000101FFFFFFFF00

Managing BlackBerry Configuration Settings Remotely - Part Four

Now that we know how to update the settings on the device, here is a screenshot showing the default settings, and a list of Data strings with all the different Message List 'General Settings' options:


Default Message List / General Options settings:


[Data String for Defaults above]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Display Time: NO]
0x350000000101000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Display Name: NO]
0x350000010001000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Display Message Header On: 1 line]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B010002000C000002000D000001000E00000000

[Display Message Header On: 2 lines]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B020002000C000002000D000001000E00000000

[Display Message Count: None]
0x350000010101000001010001000301010200051E0001000600020008
00000100090102000B000002000C000002000D000001000E00000000

[Display New Message Indicator: No]
0x350000010101000001010001000301010200051E0001000600020008
01000100090002000B000002000C000002000D000001000E00000000

[Confirm Delete: No]
0x350000010101000001010000000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Hide Filed Messages: YES]
0x350000010101000001010101000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Hide Sent Messages: YES]
0x350000010101000001010001000301010200051E0001000601020008
01000100090102000B000002000C000002000D000001000E00000000

[Make PIN Messages Level 1: No]
0x350000010101000001010001000300010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Auto More: No]
0x350000010101000001010001000301000200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Keep Messages: 15 Days]
0x350000010101000001010001000301010200050F0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Keep Messages: 2 Months]
0x350000010101000001010001000301010200053C0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Keep Messages: 3 Months]
0x350000010101000001010001000301010200055A0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Keep Messages: 4 Months]
0x35000001010100000101000100030101020005780001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Keep Messages: 5 Months]
0x35000001010100000101000100030101020005960001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Keep Messages: 6 Months]
0x35000001010100000101000100030101020005B40001000600020008
01000100090102000B000002000C000002000D000001000E00000000

[Keep Messages: Forever]
0x35000001010100000101000100030101020005FFFF01000600020008
01000100090102000B000002000C000002000D000001000E00000000

[SMS and Email Inboxes: Combined]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C010002000D000001000E00000000

[SMS and Email Inboxes: Separate]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C020002000D000001000E00000000


The first line contains all the default settings from my test device which is an 8700g with the 4.2 OS software. The latter lines are the defaults with only the option shown enabled. The highlighted numbers in the rows show which number controls the setting in that row.

Keep in mind that this may be different from what you see depending upon your device type and OS version, however I suspect they would be similar if not the same for the same OS version.

Next: Calendar, Address Book, and Tasks options database settings.

Managing BlackBerry Configuration Settings Remotely - Part Three

To begin, of course, a Disclaimer: The BES SQL database is the heart of your BES environment. Making changes to it outside of the UI is not supported by RIM and can do irreparable harm to your entire BES environment. The following is for informational purposes only, and I am not responsible for the thousands of midnight telephone calls you will get from your BlackBerry users when an errant SQL command has rendered your BES servers mere hunks of plastic and metal, and transmogrified into a CLM [career limiting move]. I for one will not be implementing these findings in my production environment! Now, onto to the madness...

Since we have discovered where the configuration setting "Hide Sent Messages" lives in the SQL database, let's try to modify it and get it pushed out to the device. First, let's reset the option back to the default of "No" and restart the wireless to get it changed in the SQL database. Here is the device screenshot showing the default settings:


And here is the SQL data, showing that the '1' has been changed back to a '0':

0x350000010101000001010001000300010200051E0001000600020008
01000100090102000B000002000C020002000D000001000E00000000

Now, let's use a SQL command to update this string to change the '0' back to a '1':


Perhaps if we restart the wireless on the device the change will sync down?



Alas and alack, the change did not come down. Oh well, that would have been too easy. Let's take a deeper look into the SQL tables to see where we can go from here. I see a promising table named SyncConfig...and it appears to... wait for it... hold the Synchronization Configuration settings! Just what we need:

I see there are many lines associated with UserConfigId 9, which is my single test user. I also see a column titled SyncDataSourceId, I wonder what the numbers in this column refer to?

After doing some digging I discover the SyncDataSource table, which contains mappings between the numbers in the SyncDataSourceId column and the names of these sources.


What we are interested in would be the Backup data source, or number 11109, as this is what we are working with. This leads us to row 102 in the SyncConfig table.

Now the question becomes, what do the other columns in this table mean, and what can we do with them? SyncType and ConflictResolution appear especially intriguing given what we are trying to accomplish here.

By changing some settings on the device and watching the effect on this table for other unrelated rows, I discovered that the SyncType field has three options available:

1 = Server to Device
2 = Device to Server
3 = Bi-directional

In our case, the 11109 Backup row in this table indicates '3', or Bi-Directional sync. I would have expected to see this set to '2' for one way backups from device to server only. However '3' may make sense, as the backup is from device to server for the most part, but can be from server to device when changing devices for instance.

Similar to SyncType, the ConflictResolution column appears to have two options available:

0 = Server Wins
1 = Device Wins

Our row 102 shows a '0' in this column, which again is a little unexpected as I assumed that the server side was a backup to what is on the device, so the device should always win in a conflict. Perhaps there are good reasons for these non-obvious settings that I am not aware of.

In any case, we have still updated the data in the SyncBackupRestore table but it has not sync'ed to the device, even though the sync settings shown above indicate that a) sync is bidirectional and b) the server will win on a conflict. So really this should just work without any changes, however we need to figure out some way of 'kicking' off a sync.

We know that when you disable and then re-enable synchronization from the device or BES manager for other functions such as Address Book, it will kick off an initial sync. The issue here is that there is no way through the GUI of the device (or the BES Manager) to kick off a Backup sync, as this is an underlying process not available to the end user or administrator.

Why don't we try to just flip the ServerEnabled setting from 1 to 0, and then back to 1 to see if this does it:


Unfortunately, looking at the logs it doesn't appear that this trick did anything. I see the following lines in both the SYNC and CBCK logs:

[46077] (01/31 13:09:36.021):{0x1178} [SYNC-Gate] Finished user config change check. No change detected.
[40039] (01/31 13:20:21.856):{0x1EE0} CheckResponseRcvd - no changes detected for any users.

Let's move on and try to change another field, how about we try to change the SyncType from '3' (bi-directional) to '1' (server to device):


Wow! Within a minute or so of making this change there was a flurry of activity in the SYNC and CBCK logs. I notice this line as well:

[46078] (01/31 13:26:53.092):{0x1178} [SYNC-Gate] Finished user config change check. Change detected.

Turns out this triggered a full synchronization, such that everything on both sides was compared and the changes pushed down to the device. Going back into our Message List Options screen, we are presented with:





As Dora would say, "Lo Hicimos! We did it!"






So in summary, we were able to push this change to the device by doing the following:

1) Locating the option in the data string of the particular settings database within SyncBackupRestore
2) Updating the data string with the particular option set, via SQL commands
3) Modifying the SyncType from '3' to '1'

Now, like a good boy scout, we must remember to clean up after ourselves. To get this to work we had to break the default SyncType, so let's set it back to '3' so that any future changes on the device continue to be backed up:


Next Up: Decoding the Data string in the "Message List Options" database to map out all the different option settings.

Managing BlackBerry Configuration Settings Remotely - Part Two

OK so let's dive in and see what we can do with the SQL table SyncBackupRestore. First of all it looks like there are separate entries for different types of settings. Let's start with the entry for Message List Options for UserConfigId #9, which is the only user in this test environment:


It looks like the Data column is encoded in some sort of binary format, let's see if we can use OSQL to see what's in there:


So after a bunch of header information we finally see the data string, and it looks like this:

0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000

As it exists now, this string represents the state of the options for the Message List, i.e. the Messages screen on the BlackBerry. The best way to discover what pieces control which device settings is to change an option on the device, wait for it to get synced up to the server, then check this string again to see what is different.

We will first test by changing a single option on the BlackBerry, Hide Sent Messages from the default of No to Yes (a common enough request!). Now the issue is waiting for the device's backup agent to push the change to the BES server, however I discover to my pleasant surprise that turning off the antenna and turning it back on will trigger the handheld agent to push any device changes up to the server. (Restarting the BlackBerry has the same effect).

I have been using the Unix "tail" utility to follow the BES server's CBCK log file (Backup connector), which is set to the debug logging level of 7 through the registry (4 is the max via the UI). When the device connects to the network we see the following update come through:

[60000] (01/30 14:26:07.086):{0x151C} [ODBCRecord::DoSetValue] DATA = "DbVersion[1] Data(first 32 bytes)[0x350000010101000001010001000300010200051E000100060102000801000100] UserConfigID[9] DatabaseName[Message List Options] UID[1] ".

This log entry only shows the first 32 bytes of the updated field, so we have to go back to the OSQL utility to display the full field again, and it is now set to the following:

0x350000010101000001010001000301010200051E0001000601020008
01000100090102000B000002000C000002000D000001000E00000000

The only change in this string is the highlighted '1' near the end of the first line has now been changed from a '0' previously. This leads us to believe that this number controls the Hide Sent Messages option on the device, and that modifying it from '0' to '1' enables it.

In the next post we will try to update this field in the SQL database and (somehow!) get that update pushed to the handheld.

Managing BlackBerry Configuration Settings Remotely - Part One

Much of the configuration of BlackBerry devices can be controlled through IT Policy options, especially those having to do with security. However there are many more configuration options available on the device that don't have IT Policy correlates. In these cases it can be difficult to control the user experience or to enforce standard organizational settings.

There are a few options to automate the configuration of these device settings:

1) Configure a BlackBerry with your custom settings, then back it up to a .IPD file. For each new BlackBerry deployed, restore the .IPD file before activation.

2) Configure a BlackBerry with your custom settings, then assign it to the new user's account. Then activate a new BlackBerry against the same account, which will inherit the device configuration settings from the old device.

These options can set an initial standard, however they cannot be changed remotely or locked down and enforced over time. The BlackBerry device user will have the ability to modify these settings and break the standard.

The fact that option #2 above exists tells us that the device configuration settings are stored within the BES environment, as that is how swapping in brand new device for a user can inherit all the old device's settings. Unfortunately the location of these settings is not easily accessible to the BES Administrator, as this function was really only designed for backup and restoration purposes.

However... if we can figure out where these settings are stored perhaps we can modify them somehow from the back end, and push them down to the device. We know that most configuration information is stored in the central SQL database, so this is where the configuration must be stored as well.

Peeking around my test environment I discovered a table in the database called SyncBackupRestore. It appears that much of the device's configuration settings are stored in this table. In the next post we will dig deeper into this table to discover what it holds and how perhaps we can modify it and push the changes to a remote BlackBerry.