Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 04-09-2013, 15:04   #31
Registered User

Join Date: Aug 2013
Boat: Landlocked
Posts: 16
Re: S-63 Confusion

Thanks for your input SamsonovAnton. I guess it might look like we are considering the implementation to be easy, but it's more that the implementation should be straightforward. Yes there is code to write, but all the technical information appears to be available for the encryption and key management. You are correct to note that the data exchange is not well defined.

I think your statement that "there is also a possibility that IHO does not actually conduct implementation audits against the manufacturers, or does it in a very formal way with no real checks." is likely to be true. From their own specification it appears to be allowable to store decrypted data to disk (temporarily). It also appears there are no particular requirements for obfuscation to prevent a user retrieving the keys with a debugger.

I think they are fairly safe in that the data sets are expensive to get your hands on in the first place, and all the larger shipping outfits are legally required to carry the correct charts in any case, so they have no incentive to circumvent the encryption because they would then not be able to demonstrate use of the correct charts.

Yes I understand S-63 was developed from the Primar Security Scheme. I'm sure we will have to add a lot of code to handle the variations from different distributors. Have you any experience in how much this layout changes between distributors? Handling this variation is less straightforward than perhaps a basic implementation but it should be achievable. The main issue I guess is we will need a user to buy the charts and give us enough information to debug the issues. I can't see this being insurmountable as Polar view have achieved it, but I have seen references to data suppliers converting to SENCs for a particular platform noting that they handle all the "irregularities". I think there is an expectation we'd need to build the functionality either into the OpenCPN fork of GDAL or outside of it to feed it the S-57 cells by interpreting the extra data in S-63. I'm not sure using a hardware token would reduce the implementation effort, but that isn't an area I have knowledge in.

In terms of the IHO being flexible enough for exotic guys like us, I guess the idea is to put on our formal wear, approach them professionally and satisfy their requirements so that they have no problem with us. I don't see why we shouldn't be able to interact with them like any other organisation.
__________________

__________________
redcane is offline   Reply With Quote
Old 05-09-2013, 06:58   #32
Registered User

Join Date: Jun 2013
Location: Moscow, Russia
Boat: Clerk Chair 1.6ft
Posts: 39
Re: S-63 Confusion

Quote:
Originally Posted by redcane View Post
It's more that the implementation should be straightforward. Yes there is code to write, but all the technical information appears to be available for the encryption and key management. You are correct to note that the data exchange is not well defined.
Parsing those additional data is indeed easy to implement, with the only exception that the authors of the S-63 were crazy enough to mix binary hashing and ciphering with textual ASCII strings, and that the parent signature of a PQG-certificate is verified against its textual representation including actual line breaks.

Handling those additional data is not that easy, though.
  • With a plain bunch of S-57 charts, you only have to scan the entire data folder and assemble a revision list for each chart.
  • With a single S-63 supplier for specific country / agency, you may have to deal with volume and media sets, “base” and “update” sets (which appear to have no real difference in handling), all those meta-data, switching to a new decryption key for a chart over time, ignoring any charts that the user did not bought, ignoring “faux” updates that just inform the user of a new chart edition (which must be purchased separately, I suppose).
  • With multiple S-63 suppliers of worldwide scale, you will have to be able to get the most out of available data, combining older revisions from one supplier with newer updates from another (with different key-sets), selecting the best available edition, resolving duplicates, some of which might seem newer but cannot be actually assembled.
That's why one need to study as much real-world datasets as possible, before trying to implement the S-63 import procedures. The only example I could find is the Australian collection, but it has a very simple layout and still requires a key-set for practical tests. That's why I temporarily suspended my development, for example; good luck to everyone daring to succeed.

Quote:
It appears to be allowable to store decrypted data to disk (temporarily).
Technically, there is no need for this at all, as S-57 reader could just accept a stream instead of a file, with that stream being wrapped with hashing, decryption, decompression, etc. However, GDAL currently accepts filename only in S57Reader constructor, but I think this could be enhanced, as OpenCPN doesn't rely on other GDAL drivers. The only trick with decryption is that the upper-level wrapper should check that the key matches the data (by examining the first decrypted block, being it a ZIP header or a DDF header) — to prevent big waste of resources when decrypting a newer chart with an older key.

Quote:
It also appears there are no particular requirements for obfuscation to prevent a user retrieving the keys with a debugger.
That's simply because 99,999 % of those users have a “black box” ECDIS, which doesn't expose its interiors to anybody except their manufacturer-authorized maintenance personnel, and accepts nothing more than properly protected S-63 ENCs or SENCs.

Quote:
I think they are fairly safe in that the data sets are expensive to get your hands on in the first place, and all the larger shipping outfits are legally required to carry the correct charts in any case, so they have no incentive to circumvent the encryption because they would then not be able to demonstrate use of the correct charts.
Moreover, even if someone managed to extract and decrypt those charts, he/she would not be able to feed those charts to any certified ECDIS, unless that recipient “black box” is cracked, too. That's the key strength of the S-63 protection scheme — it employs organizational means to a greater degree than technical means of cryptography. And that's why “open boxes” put this scheme in a grave danger.

Quote:
I have seen references to data suppliers converting to SENCs for a particular platform noting that they handle all the “irregularities”.
By the way, as far as I understood from an IHO report, majority of manufacturers honestly admit that their systems are not up to the date with the most current S-63 specification. Thus, I suppose, most ECDIS are tied to predefined chart suppliers — like the mentioned PolarView NS is tied to ChartWorld.

Quote:
I'm not sure using a hardware token would reduce the implementation effort.
It would increase the efforts, obviously. But it could be the only way to get approvement from IHO.

Quote:
The idea is to put on our formal wear, approach them (IHO) professionally and satisfy their requirements so that they have no problem with us.
They are only dealing with organizations, not individuals. As far as I understand, OpenCPN is not backed by a legal body, but by an unofficial community of individuals not connected to charting / plotting industry.
__________________

__________________
SamsonovAnton is offline   Reply With Quote
Old 05-09-2013, 11:42   #33
Registered User

Join Date: Jun 2013
Location: Moscow, Russia
Boat: Clerk Chair 1.6ft
Posts: 39
Re: S-63 Confusion

For those who may be curious about S-63 internals, but don't have time to dig into specifications, I'll try to explain basic concepts of this protection scheme — in hope that it may help in understanding why IHO is likely to deny registration for any “open system”.

As already mentioned, the S-63 was adopted from a proprietary scheme already in service by late 1990-s. For that time, the chosen cryptographic means were strong enough:
  • Blowfish encryption with 40-bit key — that key is either a specific chart key or the Hardware-ID, unknown to the user;
  • Blowfish encryption with 48-bit key — essentially the same Hardware-ID with repeated first byte, so the actual strength is 40 bits, too;
  • DSA signature, which takes 160-bit SHA-1 hash and outputs a pair of 160-bit numbers.
Nowadays, 40-bit keys seem too weak for a quick brute-force recovery on a commodity desktop machine. Even more so, the symmetric block cipher is used in it's raw form, called “electronic codebook”, so the same input always produces the same output. As a result, if we know the plain-text data or can make some assumptions about it, we can automatically detect a successful brute-force attempt. With an S-63 chart, the first block (8 bytes) is almost fixed, as it is ZIP archive header.

However, the ancient Blowfish algorithm is known for its resistance to brute-force attacks, as each initialization is equivalent to encrypting (or decrypting) a block of 4168 bytes — which is relatively fast, but not that fast. Just to bate my curiosity, I created a program to benchmark this procedure. An optimized version in pure C with heavy function inlining topped to 200'000 keys per second when run in 10 threads on a Core i7-2600 with hyper-threading and dual-channel DDR3-1333 memory, which means that only 63,5 days are required for a full scan and less than 32 days in average, statistically.
Perhaps, it may be optimized even further, especially using pure Assembler, — I'm not a guru of low-level programming. Unfortunately (for an attacker), Blowfish is difficult to implement on tiny hardware because of relatively high memory requirement, and on GPU because of slow access to global video-memory bus; although I read that modern GPUs may offer thousands and tens of thousands of 32-bit integer registers — that is enough to run 4 to 16 workers per GPU that are times faster than CPU workers.

Also, I was recently answered on Crypto.StackExchange that it may be possible to recover the key significantly faster than with brute-force approach, but still didn't understand their idea, as I'm not very knowledgeable in cryptanalysis. Let's just assume that a half of complete range scan is required, which is roughly 1 month of 24x7 crunching.
As you can see, the encryption used by S-63 charts can't be considered a serious technical measure nowadays. Why is the S-63 still considered more than adequate then?

The first reason is of technical nature: each chart has its own decryption key, that is transferred to the user in an encrypted form, with Hardware-ID used for decryption.
  • So, if one has a PERMIT.TXT list for all charts, he/she first needs to recover a single chart key, and then use it as a known plain-text to recover Hardware-ID, so that it can later be used to decrypt any chart listed in PERMIT.TXT.
  • If a PERMIT.TXT is not available or contains too few keys, then all other charts need to be cracked one-by-one. The only relief is that a single key is used for all chart's updates, until it's replaced by another key.
The latter case is more real for unorganized individual infringers, and will require plenty of computational time even with modern hardware. As it seems unlikely that an application could run for months uninterrupted, the key-recovery utility should be written with limited time sessions and small sub-tasks in mind, — this raises the complexity, not to mention that an occasional processing will increase total recovery time (8 hours per day result in tripled time). If the sub-tasks are to be run in parallel in a distributed environment, it would require a complex infrastructure like BOINC or other grid computing frameworks.

The second reason is organizational.
  • Many users of “black box” ECDIS don't have access even to the encrypted S-63 charts, as they are imported by service personnel only or are automatically downloaded by ECDIS from supplier's site via an SSL-encrypted channel (and that kind of encryption isn't bound by decrepit S-63 regulations). Although this is not required, and some data suppliers publicly distribute a single CD/DVD set — it is PERMIT.TXT with chart keys that is generated personally for each user; this protection scheme resembles that of cable / satellite TV.
  • As I already noted, even if one copied S-63 charts and recovered their keys, he/she wouldn't be able to load them into another useful “black box” ECDIS, because that box would require proper PERMIT.TXT encrypted for its own Hardware-ID.
As you can imagine, “open box” systems (not necessarily open-sourced) make things much easier to be manipulated by user. Given an open-source library, one could simply write a program that replaces encrypted charts with their plain-text versions — and the entire dataset would be easily importable in any plotting application that accepts raw S-57 charts (although signature verification wouldn't be possible).

Overall, “open box” systems are incompatible with the security model of S-63, even more so if the system is both completely open-sourced (“white box”) and accessible to the user. They make it too easy for an unqualified user to circumvent the protection.
__________________
SamsonovAnton is offline   Reply With Quote
Old 05-09-2013, 12:28   #34
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 2,766
Re: S-63 Confusion

First I would like to invite another time not to center debates if the standard is good, bad or ugly. Or oldfashioned. Or how to crack the schemes.

Having a (bad) opinion about an organisation or a standard will not help us to deal with the practical implications when we want to work with it.

In relation with the Manufacturer id I just want to remember that there some - more than two - acredited implementations on PCs without hardware dongle. And some of those are from really not big organisations.
So why we shouldn't get one?
And very probably one will need a lot of pacience and a high allowance for frustation dealing with standard bodies.

An yes the hurdles to get into the very exclusive club of chart distributors are higher. If even possible. But one step after the other.

Number one: building the technical basis in form of a plug-in.
Number two: with that one applying for the manufacturer ID for OpenCPN

Step 3: which charts from which source we shall see when we mastered the first two challenges.

And one big advantage has working in this environment of OpenCPN: there is no problem in case we fail. Just some time spent and learnt a lot of new stuff. So let's be pragmatical.

And Anton: of course you are invited to participate if this suits into your ideas and plans. I'm sure you have already a very valuable part for task number one covered.

For instance your observation that the manufacterers are centering their efforts in working with just one VAR/chart reseller is most probably right - at least what I have seen at the first glance.
Why? Makes the investment and maintenance cheaper - they are companies. And if you get all the charts you need at more or less the same price - IHO sells the charts at the same conditions to all resellers, they state - why looking then for wider solutions, if the business is done with one? (There enters the "Value Added Reseller" - how can I make the difference)
__________________
bcn is online now   Reply With Quote
Old 09-09-2013, 22:12   #35
Registered User

Join Date: Aug 2013
Boat: Landlocked
Posts: 16
Re: S-63 Confusion

Quote:
Originally Posted by SamsonovAnton View Post
They are only dealing with organizations, not individuals. As far as I understand, OpenCPN is not backed by a legal body, but by an unofficial community of individuals not connected to charting / plotting industry.
I was intending to set up a legal entity to approach the IHO from. That entity would have to manage the issued hardware IDs, as well as being responsible for the manufacturer key. However given the difficulties you have noted of building a working implementation it might be wise to write a proof of concept first.

Given the weakness of the encryption in use, I'm not sure if the IHO will be that concerned by the open nature of the system making it easy to circumvent the protections or not. I will have to draft a letter to the IHO to be sure I suppose.
__________________
redcane is offline   Reply With Quote
Old 11-09-2013, 02:39   #36
Registered User

Join Date: Sep 2013
Posts: 2
Re: S-63 Confusion

Hi everyone,
please help me! i want to find a method or algorithm for decryption s-63 chart and save s-57 format?
__________________
kmrnu is offline   Reply With Quote
Old 11-09-2013, 04:01   #37
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 2,766
Re: S-63 Confusion

Quote:
Originally Posted by kmrnu View Post
Hi everyone,
please help me! i want to find a method or algorithm for decryption s-63 chart and save s-57 format?
It does not exist as open software - and this is why we will have to write it.
Have a look through the las two pages of this thread.....
__________________
bcn is online now   Reply With Quote
Old 18-09-2013, 10:58   #38
Registered User

Join Date: Jun 2013
Location: Moscow, Russia
Boat: Clerk Chair 1.6ft
Posts: 39
Re: S-63 Confusion

Quote:
Originally Posted by bcn View Post
Step 1: building the technical basis in form of a plug-in.
Step 2: with that one applying for the manufacturer ID for OpenCPN
There is a vicious circle here: to apply for an Manufacturer ID, you already need (at least formally) a correctly working implementation, for which you need a chart collection to test against — but to get such a collection, you need some recognized Manufacturer ID/Key in advance, unless IHO updates the S-64 encrypted dataset to a usable state.

That's why I studied the possibility to crack a data from some existing system, PolarView as an example, but still found no shortcuts that would keep from brute-forcing.

Quote:
One big advantage has working in this environment of OpenCPN: there is no problem in case we fail. Just some time spent and learnt a lot of new stuff.
If you mean a failure to register initially, then yes. But if registration succeeds, people start buying charts, and then the key will be revoked because of newly discovered “imperfections”, all those charts would become semi-useless due to inability to update them.

Quote:
Anton, I'm sure you have already a very valuable part for task number one covered.
Unfortunately, the “experimental” branch of my program, that has initial S-63 support (loading, parsing, validating, but not actually using, except for several hard-coded step-by-step demo scenarios), is targeted for .Net/Mono; moreover, it's written in VB.Net, so not directly usable in a C++ code, although automatic conversion tools may help with this — excluding math and crypto, but those are better taken from OpenSSL for example. The “production” branch is written in C++ and uses GDAL (upstream), but it's nowhere near S-63 implementation. If you find it helpful, I may provide the “experimental” version to anyone else who will be involved in development (privately). I hope to be helpful with coding as well, but looks like won't have spare time next weeks.
__________________
SamsonovAnton is offline   Reply With Quote
Old 18-09-2013, 12:18   #39
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 2,766
Re: S-63 Confusion

Quote:
Originally Posted by SamsonovAnton View Post
There is a vicious circle here: to apply for an Manufacturer ID, you already need (at least formally) a correctly working implementation, for which you need a chart collection to test against — but to get such a collection, you need some recognized Manufacturer ID/Key in advance, unless IHO updates the S-64 encrypted dataset to a usable state.
Hi Anton, thanks for your clarifications and comments. Helps to get quicker to the points

From the IHB documents:
------------------------------------------------------------------------
2. Test Definitions
2.1 Default test data parameters
The ENC permits that accompany the encrypted ENC test data have been generated for the Userpermit specified below. To carry out the tests described in this document manufacturers will have to create a hard lock device or program their software with the following manufacturer information and hardware ID (HW_ID).
Manufacturer ID: (M_ID) = 10 (or 3130 hexadecimal)
Manufacturer Key: (M_KEY) = 10121 (or 3130313231 hexadecimal)
Hardware ID: (HW_ID) = 12345 (or 3132333435 hexadecimal)
USERPERMIT = 66B5CBFDF7E4139D5B6086C23130
This is the official manufacturer information issued for and by the Scheme Administrator (IHB) and is provided expressly for the purpose of producing encrypted ENC test data. This data is provided specifically for the following purposes:
. OEM Type approval against the S-64 Test Data for Encrypted ENCs (This document).
. OEM and Data Server self certification of their systems against the S-63 Data Protection Scheme.
---------------------------------------------------------------
I understand from your previous comments that you have tested with these parameters and the S-64 data sets (and found some flaws in the data sets). Passing the tests would entitle to get a valid M-ID, having signed an OEM-Agreement of course.
And on this basis one can check against other datasets from different sources. Will cost some money perhaps.

BTW.: the S-64 dataset also provides tests for the S-52 presentation standard - even if OpenCPN is not aiming to be a type-approved software for commercial purposes compliance is the target.

Anyhow - we have contacted the IHB and are waiting for some answers.
Will report back when getting those. Shall see ...

In the meantime with the corresponding bottle of good red wine or a six-pack, whatever is preferred
__________________
bcn is online now   Reply With Quote
Old 18-09-2013, 12:32   #40
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 2,766
Re: S-63 Confusion

To make things easier for those who don't want to enter into details or perhaps are looking for some specific information:

The "S-xx" standards are defined by the IHO (International Hydrograhic Organisation) and administered by the IHB.

S-57 Electronic Navigational charts (Vector charts, formats, data)
S-58 Recommendd ENC validation checks
S-52 Presentation of the S-57 charts by a system
S-63 Encrypted distribution of S-57 data sets
S-64 S-63 compliance test data sets and procedures

All these standards are downloadable from
Downloads for IHO Member States and Subscribers
__________________
bcn is online now   Reply With Quote
Old 18-09-2013, 16:47   #41
Registered User

Join Date: Aug 2013
Boat: Landlocked
Posts: 16
Re: S-63 Confusion

Quote:
Originally Posted by SamsonovAnton View Post
There is a vicious circle here: to apply for an Manufacturer ID, you already need (at least formally) a correctly working implementation, for which you need a chart collection to test against — but to get such a collection, you need some recognized Manufacturer ID/Key in advance, unless IHO updates the S-64 encrypted dataset to a usable state.
I don't suppose there is any value in using the freely available S-57 data sets and encrypting them with the S-64 key to produce our own s-63 charts? You have noted that the decrypted S-63 data tends to have additional data not included in most S-57 charts?

Quote:
Originally Posted by SamsonovAnton View Post
If you mean a failure to register initially, then yes. But if registration succeeds, people start buying charts, and then the key will be revoked because of newly discovered “imperfections”, all those charts would become semi-useless due to inability to update them.
I think the first few users could certainly be considered experimental beta users, but I'd also hope the IHO would be reasonably up front about any imperfections they become aware of, and allow an opportunity to remedy them. I realise this is completely up to them however.
__________________
redcane is offline   Reply With Quote
Old 19-09-2013, 00:13   #42
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 2,766
Re: S-63 Confusion

Quote:
Originally Posted by redcane View Post

I think the first few users could certainly be considered experimental beta users, but I'd also hope the IHO would be reasonably up front about any imperfections they become aware of, and allow an opportunity to remedy them. I realise this is completely up to them however.
Agree - there is a beta phase required - think that our zoo has a lot of different species: Linux various distros, Windows XP thru 8.1, Mac OS.X 10.5 --> 10.? and all these if possible with data sets from different sources.

With respect to the IHO/IHB and imperfections the OEM agreement states:

Quote:
8.1 The IHB acting as SA has the right, without giving the Company any right to claim for indemnification, damages etc. to terminate this Agreement with immediate effect and withdraw the Company’s permission to use the Proprietary Information and participate in the S-63 Data Protection giving the Company a minimum of one calendar months notice if :


8.1.1 The Company has compromised the S-63 Data Protection Scheme by disclosing Proprietary Information marked as confidential.


8.1.2 The SA has detected significant errors or inadequacies in the implementation of the S-63 Data Protection Scheme within the Company’s EPS related to the technical requirements set out in this Agreement or to the security of the Proprietary Information provided under the terms and conditions of this Agreement andif the infringements are not rectified within 60 working days for new EPS units and within one year for existing EPS units of the notification of the infringement or as otherwise so agreed with the SA.


8.2 The Company may terminate this Agreement at any time giving the SA a minimum of one calendar months notice.
__________________
bcn is online now   Reply With Quote
Old 19-09-2013, 16:24   #43
Registered User

Join Date: Aug 2013
Boat: Landlocked
Posts: 16
Re: S-63 Confusion

Quote:
The SA has detected significant errors or inadequacies in the implementation of the S-63 Data Protection Scheme within the Company’s EPS related to the technical requirements set out in this Agreement or to the security of the Proprietary Information provided under the terms and conditions of this Agreement andif the infringements are not rectified within 60 working days for new EPS units and within one year for existing EPS units of the notification of the infringement or as otherwise so agreed with the SA.
I'm not sure how we could be sure to 'rectify' existing EPS units within any time frame... If a user holds on to the old software it would remain un-rectified. However I guess we could reach an agreement with the IHO...

Otherwise we'd need to force people to upgrade I guess. In the case of an open source plugin compiled with a private key embedded, I suppose we could compile it with code that would 'phone home' to a web service to check for updates, and require any updates to be installed.
__________________
redcane is offline   Reply With Quote
Old 20-09-2013, 00:20   #44
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 2,766
Re: S-63 Confusion

Quote:
Originally Posted by redcane View Post
I'm not sure how we could be sure to 'rectify' existing EPS units within any time frame... If a user holds on to the old software it would remain un-rectified. However I guess we could reach an agreement with the IHO...

Otherwise we'd need to force people to upgrade I guess. In the case of an open source plugin compiled with a private key embedded, I suppose we could compile it with code that would 'phone home' to a web service to check for updates, and require any updates to be installed.
New question for the IHB....

This is valid for all the othe Manufacturers with S-63 support as well.
Any user of Coastal Explorer, PolarView, MaxSea or the Australian Seafarer ChartViewer here to comment?

A comercial black box user has to update charts but in the recreational field?
Obviously it would be possible to blacklist all installations that did not upgrade after one year in order to exclude those from getting new chart material.
__________________
bcn is online now   Reply With Quote
Old 21-09-2013, 16:34   #45
Registered User

Join Date: Aug 2011
Location: UK
Posts: 10
Re: S-63 Confusion

Quote:
Originally Posted by redcane View Post
I'm not sure how we could be sure to 'rectify' existing EPS units within any time frame... If a user holds on to the old software it would remain un-rectified. However I guess we could reach an agreement with the IHO...

Otherwise we'd need to force people to upgrade I guess. In the case of an open source plugin compiled with a private key embedded, I suppose we could compile it with code that would 'phone home' to a web service to check for updates, and require any updates to be installed.
An alternative would be to request a new M_KEY.
It would be easier if the userpermit contained details of the client software release, but unfortunately it doesn't and probably won't until S.63 2.0 is released, which is some time away.
When it does, data servers can be alerted to stop issuing permits for those versions and to change affected cell keys if necessary.

However, if a user is savvy enough to copy unencrypted data from temporary files or even debugging the ECDIS code, they're probably also capable of brute-forcing the protected charts. That way they get access to all charts, not just ones they have permits for.

On another point, I'd be interested to see how you get on with your opensource solution. I always thought it wasn't possible as you would need to black-box a lot of it.
__________________

__________________
bukko is offline   Reply With Quote
Reply

Tags
paracelle

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
12vdc Refrigeration Confusion SailVanora Plumbing Systems and Fixtures 24 18-10-2011 02:24
Mast Wiring Confusion unbusted67 Electrical: Batteries, Generators & Solar 11 03-07-2010 08:35
confusion about destination fardownbelow12 Polar Regions 5 11-08-2009 08:14



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 12:00.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.