CDL internet protocol - what is it (used for) ?

[Default] On Fri, 26 Feb 2016 11:45:45 +0100, in
microsoft.public.windowsxp.general "R.Wieser"
wrote:

Paul,

Now, because it's grouped with some other early
browser protocols, the implication is that whatever
CDL is, it was part of some previous generation.

I got the same feeling, but did not want to act too rash.

Thanks for the link. Alas, I cannot seem to be able to extract anything
usefull (for me) from it.

Have you been attacked lately? Even if you have, the entry point
probably was not these whatevers, because there are so many things
running. So the trouble is that if you remove these things, you
probably won't miss them for weeks or months. And when you do, you
may not have the backup you made weeks earlier before removing them,
and even if you do, it won't have changes you made since then.

You'll be stuck doing some very complicated restore, if you even can
get back to where you were.

Before anyone tries, I've (ofcourse) also searched for the class id of the
protocol. No luck there either.

Thanks for the help.

Regards,
Rudy Wieser


-- Origional message:
Paul schreef in berichtnieuws
...
R.Wieser wrote:
Hello all,

While looking at some web protocol names in te registery I found one
named
CDL ( CLSID {3dd53d40-7b8b-11D0-b013-00aa0059ce02}). Other than that a
google shows its a miltitary "Common Data Link" protocol I've not been
able
to find anything about it.

Does anyone know what its used for / why its on my computer ?

Looking at that list again I can see a few others that I have never
heard
of. Like "its", "mk", "msdaip", "ms-its" and "wia" (all under
HKEY_CLASSES_ROOT\PROTOCOLS\Handler)

Can I just kill the ones I do not remember of having ever used (removing
their CLSIDs from the registry, effectivily making them unaccessible),
or do
they actually have a purpose on a users computer ?

Regards,
Rudy Wieser

While I could find "military" references to that acronym, they were
also associated with "Ku" band.

I found another reference

https://www.winehq.org/pipermail/win...ly/018793.html

+ INF_SET_CLSID(CdlProtocol);
+ INF_SET_CLSID(FileProtocol);
+ INF_SET_CLSID(FtpProtocol);
+ INF_SET_CLSID(GopherProtocol);
+ INF_SET_CLSID(HttpProtocol);
+ INF_SET_CLSID(HttpsProtocol);
+ INF_SET_CLSID(MkProtocol);

Now, because it's grouped with some other early browser
protocols, the implication is that whatever CDL is,
it was part of some previous generation. I mean,
nobody uses gopher any more. Perhaps some of those
things, were from another time.

Paul

[Default] On Fri, 26 Feb 2016 12:13:49 +0100, in
microsoft.public.windowsxp.general "R.Wieser"
wrote:

Philo,

He ignored all advice and did nothing but shoot off his mouth.

Answer the question first, *only than* come with advice.

Definitily *do not* replace someones question with one you "are just sure
of" he's actually asking.

Your "advice" had *absolutily nothing* to do with my question. Your "why
do you still use XP" had nothing to do with the matter either.

People, most people, do all these things all the time on Usenet, in
groups of all sorts, while intending to be helpful. I know you've
been posting for years and I'm surprised you're not used to it, in
reply to your posts and others' too.

Maybe you didn't sleep well last night.


Bottom line: You have showed all the signs of someone who "knows better" and
for that reason thinks he may hijack the question. Better to cut that
short than to, after a couple of messages, be left with a lot of irrelevant,
and therefore quite wortless "suggestions".

Regards,
Rudy Wieser


-- Origional mesage:
philo schreef in berichtnieuws
...
On 02/25/2016 04:39 PM, VanguardLH wrote:

I believe he was trolling so I put him in my kf

A program does not require a protocol be registered in Windows for it to
make an outbound connection or act as a listener for unsolicited inbound
connects (which the upstream firewall in his router should take care of
- unless he has punched holes in the firewall to reroute inbound
requests). Protocols are defined to point at handlers. A program
doesn't need to find a handler in the registry if it *is* the handler
hence why he should be using a firewall (on his host or upstream).




That's why all he is doing is trolling.

He ignored all advice and did nothing but shoot off his mouth.

Micky,

So the trouble is that if you remove these things, you
probably won't miss them for weeks or months.

I'm not really in the habit of making irreversible changes. Mostly I just
rename the involved parts (or in this case: the registry entry pointing to
the involved DLL/COM object), document it so I know what I changed, and see
what happens. In the case of any usage and/or problems with it it will be
quite easy to reverse. Don't worry about that. But thanks for the warning,
appreciate it.

Regards,
Rudy Wieser


-- Origional message:
Micky schreef in berichtnieuws
...
[Default] On Fri, 26 Feb 2016 11:45:45 +0100, in
microsoft.public.windowsxp.general "R.Wieser"
wrote:

Paul,

Now, because it's grouped with some other early
browser protocols, the implication is that whatever
CDL is, it was part of some previous generation.

I got the same feeling, but did not want to act too rash.

Thanks for the link. Alas, I cannot seem to be able to extract anything
usefull (for me) from it.

Have you been attacked lately? Even if you have, the entry point
probably was not these whatevers, because there are so many things
running. So the trouble is that if you remove these things, you
probably won't miss them for weeks or months. And when you do, you
may not have the backup you made weeks earlier before removing them,
and even if you do, it won't have changes you made since then.

You'll be stuck doing some very complicated restore, if you even can
get back to where you were.

Before anyone tries, I've (ofcourse) also searched for the class id of
the
protocol. No luck there either.

Thanks for the help.

Regards,
Rudy Wieser


-- Origional message:
Paul schreef in berichtnieuws
...
R.Wieser wrote:
Hello all,

While looking at some web protocol names in te registery I found one
named
CDL ( CLSID {3dd53d40-7b8b-11D0-b013-00aa0059ce02}). Other than that
a
google shows its a miltitary "Common Data Link" protocol I've not
been
able
to find anything about it.

Does anyone know what its used for / why its on my computer ?

Looking at that list again I can see a few others that I have never
heard
of. Like "its", "mk", "msdaip", "ms-its" and "wia" (all under
HKEY_CLASSES_ROOT\PROTOCOLS\Handler)

Can I just kill the ones I do not remember of having ever used
(removing
their CLSIDs from the registry, effectivily making them
unaccessible),
or do
they actually have a purpose on a users computer ?

Regards,
Rudy Wieser

While I could find "military" references to that acronym, they were
also associated with "Ku" band.

I found another reference

https://www.winehq.org/pipermail/win...ly/018793.html

+ INF_SET_CLSID(CdlProtocol);
+ INF_SET_CLSID(FileProtocol);
+ INF_SET_CLSID(FtpProtocol);
+ INF_SET_CLSID(GopherProtocol);
+ INF_SET_CLSID(HttpProtocol);
+ INF_SET_CLSID(HttpsProtocol);
+ INF_SET_CLSID(MkProtocol);

Now, because it's grouped with some other early browser
protocols, the implication is that whatever CDL is,
it was part of some previous generation. I mean,
nobody uses gopher any more. Perhaps some of those
things, were from another time.

Paul

On 02/26/2016 07:38 AM, Micky wrote:
h.

Answer the question first, *only than* come with advice.

Definitily *do not* replace someones question with one you "are just sure
of" he's actually asking.

Your "advice" had *absolutily nothing* to do with my question. Your "why
do you still use XP" had nothing to do with the matter either.

People, most people, do all these things all the time on Usenet, in
groups of all sorts, while intending to be helpful. I know you've
been posting for years and I'm surprised you're not used to it, in
reply to your posts and others' too.

Maybe you didn't sleep well last night.




To properly answer any question one needs to know what one is really
asking...or what the ultimate goal is.

If one uses an engineer's approach, the answer may very well be nothing
to do with the original question.


My initial thought was that the OP was naive, but he was just trolling.,


Yep, you are right I should have figured that out after his first reply
rather than the second.

Philo,

To properly answer any question one needs to know what
one is really asking...or what the ultimate goal is.

Than ask. And even more important, *listen*.

If one uses an engineer's approach, the answer may very well
be nothing to do with the original question.

Possible. Again, just ask. But do yourself a favour, and do not assume
that whomever is asking a question has no clue to what he's asking /what he
really wants to have answered.

In my case you certainly misjudged. I still want to know what those
protocols are used for, even if I have already rerouted the paths for them
in the registry to a dummy "hey, I'm called!" DLL (and ofcourse checked if
that works. It does seem to).

My initial thought was that the OP was naive, but he was just trolling.,

Neither. But if that will help you sleep at night, be my guest.

Regards,
Rudy Wieser


-- Origional message:
philo schreef in berichtnieuws
...
On 02/26/2016 07:38 AM, Micky wrote:
h.

Answer the question first, *only than* come with advice.

Definitily *do not* replace someones question with one you "are just
sure
of" he's actually asking.

Your "advice" had *absolutily nothing* to do with my question. Your
"why
do you still use XP" had nothing to do with the matter either.

People, most people, do all these things all the time on Usenet, in
groups of all sorts, while intending to be helpful. I know you've
been posting for years and I'm surprised you're not used to it, in
reply to your posts and others' too.

Maybe you didn't sleep well last night.


To properly answer any question one needs to know what one is really
asking...or what the ultimate goal is.

If one uses an engineer's approach, the answer may very well be nothing
to do with the original question.

My initial thought was that the OP was naive, but he was just trolling.,

Yep, you are right I should have figured that out after his first reply
rather than the second.

Micky,

I know you've been posting for years and I'm surprised
you're not used to it,

Used to it ? Never. It does become harder-and-harder over time to even
tolerate.

Maybe you didn't sleep well last night.

Or maybe just *yet another* "helpfull" person I *ofourse* have to handle
with velvet gloves, trying to guide him to the answer I already said I was
looking for ... Just assume something broke.

Does that really change anything to what I said ? And can you even guess
the frustration I feel having to deal with such "helpfull" people ?
Having a lengthy exchange with them trying to get them to answer the goddamn
question and in the end being shown all kinds of irrelevant places, but not
even having gotten near to it ?

Not funny at all.

Regards,
Rudy Wieser


-- Origional message:
Micky schreef in berichtnieuws
...
[Default] On Fri, 26 Feb 2016 12:13:49 +0100, in
microsoft.public.windowsxp.general "R.Wieser"
wrote:

Philo,

He ignored all advice and did nothing but shoot off his mouth.

Answer the question first, *only than* come with advice.

Definitily *do not* replace someones question with one you "are just sure
of" he's actually asking.

Your "advice" had *absolutily nothing* to do with my question. Your
"why
do you still use XP" had nothing to do with the matter either.

People, most people, do all these things all the time on Usenet, in
groups of all sorts, while intending to be helpful. I know you've
been posting for years and I'm surprised you're not used to it, in
reply to your posts and others' too.

Maybe you didn't sleep well last night.


Bottom line: You have showed all the signs of someone who "knows better"
and
for that reason thinks he may hijack the question. Better to cut that
short than to, after a couple of messages, be left with a lot of irreleva
nt,
and therefore quite wortless "suggestions".

Regards,
Rudy Wieser


-- Origional mesage:
philo schreef in berichtnieuws
...
On 02/25/2016 04:39 PM, VanguardLH wrote:

I believe he was trolling so I put him in my kf

A program does not require a protocol be registered in Windows for it
to
make an outbound connection or act as a listener for unsolicited
inbound
connects (which the upstream firewall in his router should take care
of
- unless he has punched holes in the firewall to reroute inbound
requests). Protocols are defined to point at handlers. A program
doesn't need to find a handler in the registry if it *is* the handler
hence why he should be using a firewall (on his host or upstream).


That's why all he is doing is trolling.

He ignored all advice and did nothing but shoot off his mouth.

R.Wieser wrote on 2016/02/26:

Nope. Those protocols might be used to *sneak into* a machine (not checked
as much, having received fewer bugfixes -- if any). What the snuck-in
programs might than do ? What *couldn't* they than do would be a much
shorter list. :-)

Can't sneak into a machine without a socket hence why I mentioned
watching with a firewall.

Bottom line: I'm *NOT* out to receive a generic lecture about securing ones
machine. I'm *REALLY* looking for information on the usage of that CDL
protocol, and possibly those others too.

Then, as mentioned, you might want to use a registry monitor to see
which process touches those registry keys defining the protocols. (too
late to see who created them so see who reads them). There are lots
more places to look for where protocols are defined than the key you
mention.

VanguardLH,

Can't sneak into a machine without a socket hence why I
mentioned watching with a firewall.

Why put guards next to a door when you can also just remove it and brick the
hole up ? :-)

Then, as mentioned, you might want to use a registry monitor
to see which process touches those registry keys defining the
protocols.

There is no indication that those protocols I named are actually in use.
Monitoring them would most likely not show anything happening.

Also, I've redirected which DLL will be used by them, and by that way will
be alerted to any attempted usage of them.

But... I will see if I can find anything about a registry monitor which
also can keep an eye on those registry entries.

Regards,
Rudy Wieser

R.Wieser wrote on 2016/02/26:

VanguardLH,

Can't sneak into a machine without a socket hence why I
mentioned watching with a firewall.

Why put guards next to a door when you can also just remove it and brick the
hole up ? :-)

I'm not the one concerned over what unwanted people want to use your
door. Your analogy means you disable your network (yank the cable) to
prevent all use of the door by ALL processes. Yet you are posting here
so you do still want to use the door.

Instead having guards at the [network] door, you want to have guards at
the registry door but for definitions you don't what they are for yet
you intend to blindly modify them.

Then, as mentioned, you might want to use a registry monitor
to see which process touches those registry keys defining the
protocols.

There is no indication that those protocols I named are actually in use.
Monitoring them would most likely not show anything happening.

Also, I've redirected which DLL will be used by them, and by that way will
be alerted to any attempted usage of them.

Since the CDL protocol points to urlmon.dll, you will be affecting a ton
of network-centric processes, including those that merely talk themself
on a port on localhost. URLMON is a library (OLE32 extensions later
renamed to ActiveX) to extend the Win32 API.

https://msdn.microsoft.com/en-us/lib...dded.5%29.aspx

You will find programs that use the URLmon library to perform their
functions, like downloading files in your web browser. For example:

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

That calls the urlmon.h header file to define calls to the URLMON
library. Although there might be a Microsoft Technet or MSDN article
listing the exports (entry points to the DLL that are the methods or
functions the DLL provides to caller processes), I found lists at:

https://source.winehq.org/WineAPI/urlmon.html
http://www.geoffchappell.com/studies.../api/index.htm

Just how are you "redirecting" processes that access the registry to
lookup a protocol definition? There are multiple protocols (most of
which are not defined under the key you mentioned) that point to
urlmon.dll. Use regedit.exe to search on "URL Protocol". Nirsoft's
RegScanner found 70 occurrences.

Perhaps instead of asking in a newsgroup that discusses of an operating
system, you should ask in an OS programming newsgroup. Those that
actually code with calls to urlmon.dll might provide you with more
information about what that library is for although I suspect that
discussion could quickly go outside your (and my) expertise. For
example, urlmon.dll is statically linked to:

mscvrt.dll (Microsoft C runtine)
ntdll.dll (NT kernel functions)
ole32.dll (Object Linking Embedding aka ActiveX)
oleaut32.dll (core OLE functions)
rpcrt4.dll (Remote Procedure Calls)
shlwapi.dll (https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx)
user32.dll (WinAPI to user interface functions)
advapi32.dll (security calls; e.g., registry calls)
kernel32.dll (obvious)
iertutil.dll (runtime lib starting with IE7, used by HTAs to create
their UIs and by the Windows Graphical Shell for desktop,
start menu, file manager)

Most of them are system-level (OS core) libraries and you will monkeying
around with their integration with urlmon.dll.

VanguardLH,

Your analogy means you disable your network (yank the cable) to
prevent all use of the door by ALL processes. Yet you are posting
here so you do still want to use the door.

My house has got ... about 10 different doors to enter it, many of which I
have no idea of if they are resistant against break-ins, and nobody I ask
has got any clue of what they made of and if their locks are any good. I
think that having I can live with a (quite a) few less and *still* enter my
house at my leisure.

In other words: I have *no* intention to bar *all* doors. Just the ones I
can't find any documented purpose of.

Instead having guards at the [network] door, you want to have
guards at the registry door ...

No, I do not. Though I did not directly want to reject that possibility.

I've choosen to bar the door and instead of an active "you shall not pass!"
guard use someone who only needs to jot down any attempt to use that door.
I think the end effect is quite similar, but I do not need to wonder if that
guard actually does its job every time.

Since the CDL protocol points to urlmon.dll, you will be affecting
a ton of network-centric processes,

If any process will try to use that protocol I will be notified immediately.
That much I've already made sure of.

You will find programs that use the URLmon library to perform
their functions, like downloading files in your web browser. For
example:

You have not understood: I'm *not* blocking/renaming URLMON.DLL itself, I
just let a *specific* protocol (like the CDL one) point to another DLL (a
dummy one).

Just how are you "redirecting" processes that access the
registry to lookup a protocol definition?

Now thats a sensible question. :-)

-- Registry entry for: CDL: Asychronous Pluggable Protocol Handler
HKEY_CLASSES_ROOT\CLSID\{3dd53d40-7b8b-11D0-b013-00aa0059ce02}\InprocServer3
2

Replacing the default keys characterstring value of
"C:\WINDOWS\SYSTEM32\urlmon.dll" with the path and filename of of own, dummy
DLL.

Perhaps instead of asking in a newsgroup that discusses of
an operating system, you should ask in an OS programming
newsgroup.

No.

Its only because of your questions that we have veered into the realm of the
technical details. I've been answering them because I did not really see
a reason not to. I've gotten pretty-much zero usefull information from it
(other than the idea of using a registry-key monitoring program to find out
which programs are sniffing at the CLSID key for a certain protocol.
Something which could be usefull to know).

All *I* want to know is, as in the subject line, what that CDL protocol is
used for. As of yet I still have zero idea. :-\

But.... Thanks for trying to warn me for the negative effects of judiciously
mucking about with OS related stuff. Though I think I'm rather carefull in
that regard I appreciate the sentiment.

Regards,
Rudy Wieser

P.s.
The CDL protocol is present in MS OS versions ranging from Win98 (and
probably '95 too) upto and including Win10.


-- Origional mesage:
VanguardLH schreef in berichtnieuws
...
R.Wieser wrote on 2016/02/26:

VanguardLH,

Can't sneak into a machine without a socket hence why I
mentioned watching with a firewall.

Why put guards next to a door when you can also just remove it and brick
the
hole up ? :-)

I'm not the one concerned over what unwanted people want to use your
door. Your analogy means you disable your network (yank the cable) to
prevent all use of the door by ALL processes. Yet you are posting here
so you do still want to use the door.

Instead having guards at the [network] door, you want to have guards at
the registry door but for definitions you don't what they are for yet
you intend to blindly modify them.

Then, as mentioned, you might want to use a registry monitor
to see which process touches those registry keys defining the
protocols.

There is no indication that those protocols I named are actually in use.
Monitoring them would most likely not show anything happening.

Also, I've redirected which DLL will be used by them, and by that way
will
be alerted to any attempted usage of them.

Since the CDL protocol points to urlmon.dll, you will be affecting a ton
of network-centric processes, including those that merely talk themself
on a port on localhost. URLMON is a library (OLE32 extensions later
renamed to ActiveX) to extend the Win32 API.


https://msdn.microsoft.com/en-us/lib...dded.5%29.aspx

You will find programs that use the URLmon library to perform their
functions, like downloading files in your web browser. For example:

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

That calls the urlmon.h header file to define calls to the URLMON
library. Although there might be a Microsoft Technet or MSDN article
listing the exports (entry points to the DLL that are the methods or
functions the DLL provides to caller processes), I found lists at:

https://source.winehq.org/WineAPI/urlmon.html
http://www.geoffchappell.com/studies.../api/index.htm

Just how are you "redirecting" processes that access the registry to
lookup a protocol definition? There are multiple protocols (most of
which are not defined under the key you mentioned) that point to
urlmon.dll. Use regedit.exe to search on "URL Protocol". Nirsoft's
RegScanner found 70 occurrences.

Perhaps instead of asking in a newsgroup that discusses of an operating
system, you should ask in an OS programming newsgroup. Those that
actually code with calls to urlmon.dll might provide you with more
information about what that library is for although I suspect that
discussion could quickly go outside your (and my) expertise. For
example, urlmon.dll is statically linked to:

mscvrt.dll (Microsoft C runtine)
ntdll.dll (NT kernel functions)
ole32.dll (Object Linking Embedding aka ActiveX)
oleaut32.dll (core OLE functions)
rpcrt4.dll (Remote Procedure Calls)
shlwapi.dll
(https://msdn.microsoft.com/en-us/lib...9845%28v=vs.85
%29.aspx)
user32.dll (WinAPI to user interface functions)
advapi32.dll (security calls; e.g., registry calls)
kernel32.dll (obvious)
iertutil.dll (runtime lib starting with IE7, used by HTAs to create
their UIs and by the Windows Graphical Shell for desktop,
start menu, file manager)

Most of them are system-level (OS core) libraries and you will monkeying
around with their integration with urlmon.dll.

Quoting myself:

But.... Thanks for trying to warn me for the negative effects
of judiciously mucking about with OS related stuff.

"Of UN-judiciously mucking about" ofcourse. Sheesh ...

Regards,
Rudy Wieser

R.Wieser wrote on 2016/02/27:

VanguardLH,

Your analogy means you disable your network (yank the cable) to
prevent all use of the door by ALL processes. Yet you are posting
here so you do still want to use the door.

My house has got ... about 10 different doors to enter it, many of which I
have no idea of if they are resistant against break-ins, and nobody I ask
has got any clue of what they made of and if their locks are any good. I
think that having I can live with a (quite a) few less and *still* enter my
house at my leisure.

In other words: I have *no* intention to bar *all* doors. Just the ones I
can't find any documented purpose of.

Instead having guards at the [network] door, you want to have
guards at the registry door ...

No, I do not. Though I did not directly want to reject that possibility.

I've choosen to bar the door and instead of an active "you shall not pass!"
guard use someone who only needs to jot down any attempt to use that door.
I think the end effect is quite similar, but I do not need to wonder if that
guard actually does its job every time.

Since the CDL protocol points to urlmon.dll, you will be affecting
a ton of network-centric processes,

If any process will try to use that protocol I will be notified immediately.
That much I've already made sure of.

You will find programs that use the URLmon library to perform
their functions, like downloading files in your web browser. For
example:

You have not understood: I'm *not* blocking/renaming URLMON.DLL itself, I
just let a *specific* protocol (like the CDL one) point to another DLL (a
dummy one).

Just how are you "redirecting" processes that access the
registry to lookup a protocol definition?

Now thats a sensible question. :-)

-- Registry entry for: CDL: Asychronous Pluggable Protocol Handler
HKEY_CLASSES_ROOT\CLSID\{3dd53d40-7b8b-11D0-b013-00aa0059ce02}\InprocServer3
2

Replacing the default keys characterstring value of
"C:\WINDOWS\SYSTEM32\urlmon.dll" with the path and filename of of own, dummy
DLL.

Perhaps instead of asking in a newsgroup that discusses of
an operating system, you should ask in an OS programming
newsgroup.

No.

Its only because of your questions that we have veered into the realm of the
technical details. I've been answering them because I did not really see
a reason not to. I've gotten pretty-much zero usefull information from it
(other than the idea of using a registry-key monitoring program to find out
which programs are sniffing at the CLSID key for a certain protocol.
Something which could be usefull to know).

All *I* want to know is, as in the subject line, what that CDL protocol is
used for. As of yet I still have zero idea. :-\

But.... Thanks for trying to warn me for the negative effects of judiciously
mucking about with OS related stuff. Though I think I'm rather carefull in
that regard I appreciate the sentiment.

Regards,
Rudy Wieser

P.s.
The CDL protocol is present in MS OS versions ranging from Win98 (and
probably '95 too) upto and including Win10.

-- Origional mesage:
VanguardLH schreef in berichtnieuws
...
R.Wieser wrote on 2016/02/26:

VanguardLH,

Can't sneak into a machine without a socket hence why I
mentioned watching with a firewall.

Why put guards next to a door when you can also just remove it and brick
the
hole up ? :-)

I'm not the one concerned over what unwanted people want to use your
door. Your analogy means you disable your network (yank the cable) to
prevent all use of the door by ALL processes. Yet you are posting here
so you do still want to use the door.

Instead having guards at the [network] door, you want to have guards at
the registry door but for definitions you don't what they are for yet
you intend to blindly modify them.

Then, as mentioned, you might want to use a registry monitor
to see which process touches those registry keys defining the
protocols.

There is no indication that those protocols I named are actually in use.
Monitoring them would most likely not show anything happening.

Also, I've redirected which DLL will be used by them, and by that way
will
be alerted to any attempted usage of them.

Since the CDL protocol points to urlmon.dll, you will be affecting a ton
of network-centric processes, including those that merely talk themself
on a port on localhost. URLMON is a library (OLE32 extensions later
renamed to ActiveX) to extend the Win32 API.


https://msdn.microsoft.com/en-us/lib...dded.5%29.aspx

You will find programs that use the URLmon library to perform their
functions, like downloading files in your web browser. For example:

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

That calls the urlmon.h header file to define calls to the URLMON
library. Although there might be a Microsoft Technet or MSDN article
listing the exports (entry points to the DLL that are the methods or
functions the DLL provides to caller processes), I found lists at:

https://source.winehq.org/WineAPI/urlmon.html
http://www.geoffchappell.com/studies.../api/index.htm

Just how are you "redirecting" processes that access the registry to
lookup a protocol definition? There are multiple protocols (most of
which are not defined under the key you mentioned) that point to
urlmon.dll. Use regedit.exe to search on "URL Protocol". Nirsoft's
RegScanner found 70 occurrences.

Perhaps instead of asking in a newsgroup that discusses of an operating
system, you should ask in an OS programming newsgroup. Those that
actually code with calls to urlmon.dll might provide you with more
information about what that library is for although I suspect that
discussion could quickly go outside your (and my) expertise. For
example, urlmon.dll is statically linked to:

mscvrt.dll (Microsoft C runtine)
ntdll.dll (NT kernel functions)
ole32.dll (Object Linking Embedding aka ActiveX)
oleaut32.dll (core OLE functions)
rpcrt4.dll (Remote Procedure Calls)
shlwapi.dll
(https://msdn.microsoft.com/en-us/lib...9845%28v=vs.85
%29.aspx)
user32.dll (WinAPI to user interface functions)
advapi32.dll (security calls; e.g., registry calls)
kernel32.dll (obvious)
iertutil.dll (runtime lib starting with IE7, used by HTAs to create
their UIs and by the Windows Graphical Shell for desktop,
start menu, file manager)

Most of them are system-level (OS core) libraries and you will monkeying
around with their integration with urlmon.dll.

I'm sure back in '91 that Microsoft did not want to exclude themselves
from sales to the military. CDL is used for encryption between UAVs and
the controller but I'm sure there were controllers that were linked to a
computer for both local/remote control and statistics logging. Just
because the military first came up with a networking spec doesn't
preclude private businesses from utilizing it. After all, networking
originated from Arpanet funded by the DOD.

Caterpillar had a CDL port on their controller for the ECMs on their
huge tractors; however, the acronym CDL here means CAT (Caterpillar)
Data Link. I see mention of J1939 for those discussing Caterpillar
controllers (https://en.wikipedia.org/wiki/SAE_J1939 and
http://www.j1939.org/). Apparently Caterpillar used CDL to communicate
between their ECM (electronics control module aka engine computer
module) to use encryption to prevent interference with its operation.
J1939 is the newer protocol for ECM communications while CDL is an older
spec.

Here is an example of a Caterpillar controller with a CDL port:
http://www.monicoinc.com/cdl-gateway...ts/cdl-gateway

Because of the other ports affording networking to a computer running
some OS, I would expect CDL (CATDL) still be used to transmit and
receive in the network connection between OS and controller. That
device is called a gateway. The product's description also mentions
"used to set up an efficient and effective CAT monitoring system". That
indicates the device gateways to elsewhere where is the monitoring.

So as Paul surmised, it is likely an old protocol that has lingered into
later versions of Windows. The history of the CDL protocol and its
intended purpose and usage has probably been long lost or it is so
esoteric that few, like in avionics, know about it or use it. Also, CDL
seems to always point at military use of UAVs and other avionics so
there may still be some shroud of secrecy associated with CDL. Maybe a
job at the C4ISR division of Cubic (https://www.cubic.com/) might reveal
more tentacles (ancient or still active) between the military and
Microsoft.

I doubt Microsoft knows anything about Caterpillar's proprietary
communications protocol but I added that as an example that CDL may not
mean what you think it means (which was Common Data Link). As for
Common Data Link, which has us all presuming it is the CDL you found:

https://web.archive.org/web/20111003...n_Standard.pdf
Section 3.4.11

So why cannot a base station be an OS running on a general-purpose
computer (operating and logging use of microwave transceivers)? I don't
really believe you will find something from Microsoft documenting
something they added to Windows back in 1991 for this protocol. That
was before Mosaic showed up in '92, Netscape in '94, and when the
Internet just started to take off but still long before everything
started to get cataloged. I remember back then you had to pay some
company (only remember it started with "D") to access their database to
get at their archived data.

http://www.idlsoc.com/Documents/Symp...LS2007_CDL.pdf

That has a data linkk model diagram. That seems to show what the CDL
controller (hardware as the base station) would have but also indicates
that data can also come from or go to a network - which then means an OS
might be involved on some general-purpose (or even specific-purpose)
host (aka computer).

CDL might mean Common Data Link, CAT's CDL, even how to handle CDL files
(http://www.solvusoft.com/en/file-ext...xtension-cdl/). So
far, all we can tell is that the CDL protocol defined in the Windows
registry points at urlmon.dll. Monitoring what exports are called by a
process that found urlmon.dll through the CDL protocol definition might
give a clue as the function of the caller process.

What are you using to detect when your dummy file gets accessed when
something attempts to use the CDL protocol that would've pointed to
urlmon?

VanguardLH,

I'm sure back in '91 that Microsoft did not want to exclude
themselves from sales to the military. [snip]

Yes, that was something I was also thinking of.

Caterpillar had a CDL port on their controller for the ECMs
on their huge tractors; however, the acronym CDL here means
CAT (Caterpillar) Data Link.

Although they have (share) the same acronym I'm not at all sure they are
about even the same thing ...

So as Paul surmised, it is likely an old protocol that has lingered
into later versions of Windows.

Most likely.

As for Common Data Link, which has us all presuming it is
the CDL you found:

Shucks. I'm not in the habit of downloading PDFs (active contents and all
that. Yes, my AV is installed between my ears :-) ). But ... I've used
the name to google it, and landed he
http://dbpedia.org/page/Common_Data_Link

If anything, I think I may conclude that CDL never had any meaning on a
civilian users computer.

What are you using to detect when your dummy file gets accessed
when something attempts to use the CDL protocol that would've
pointed to urlmon?

As I mentioned before, a dummy DLL. One with no externally callable
functions. In its "Process Attach" initialisation I've used
GetModuleFilename to figure out which program tries to use it. It shows
that string in a message box. Thats all. Rather KISS, don't you think ?
:-)

Regards,
Rudy Wieser



-- Origional message:
VanguardLH schreef in berichtnieuws
...

I'm sure back in '91 that Microsoft did not want to exclude themselves
from sales to the military. CDL is used for encryption between UAVs and
the controller but I'm sure there were controllers that were linked to a
computer for both local/remote control and statistics logging. Just
because the military first came up with a networking spec doesn't
preclude private businesses from utilizing it. After all, networking
originated from Arpanet funded by the DOD.

Caterpillar had a CDL port on their controller for the ECMs on their
huge tractors; however, the acronym CDL here means CAT (Caterpillar)
Data Link. I see mention of J1939 for those discussing Caterpillar
controllers (https://en.wikipedia.org/wiki/SAE_J1939 and
http://www.j1939.org/). Apparently Caterpillar used CDL to communicate
between their ECM (electronics control module aka engine computer
module) to use encryption to prevent interference with its operation.
J1939 is the newer protocol for ECM communications while CDL is an older
spec.

Here is an example of a Caterpillar controller with a CDL port:
http://www.monicoinc.com/cdl-gateway...ts/cdl-gateway

Because of the other ports affording networking to a computer running
some OS, I would expect CDL (CATDL) still be used to transmit and
receive in the network connection between OS and controller. That
device is called a gateway. The product's description also mentions
"used to set up an efficient and effective CAT monitoring system". That
indicates the device gateways to elsewhere where is the monitoring.

So as Paul surmised, it is likely an old protocol that has lingered into
later versions of Windows. The history of the CDL protocol and its
intended purpose and usage has probably been long lost or it is so
esoteric that few, like in avionics, know about it or use it. Also, CDL
seems to always point at military use of UAVs and other avionics so
there may still be some shroud of secrecy associated with CDL. Maybe a
job at the C4ISR division of Cubic (https://www.cubic.com/) might reveal
more tentacles (ancient or still active) between the military and
Microsoft.

I doubt Microsoft knows anything about Caterpillar's proprietary
communications protocol but I added that as an example that CDL may not
mean what you think it means (which was Common Data Link). As for
Common Data Link, which has us all presuming it is the CDL you found:


https://web.archive.org/web/20111003...ne.co.uk/docum
ents/ASSC_Study_Application_MPEG2_Digital_Video_Compres sion_Standard.pdf
Section 3.4.11

So why cannot a base station be an OS running on a general-purpose
computer (operating and logging use of microwave transceivers)? I don't
really believe you will find something from Microsoft documenting
something they added to Windows back in 1991 for this protocol. That
was before Mosaic showed up in '92, Netscape in '94, and when the
Internet just started to take off but still long before everything
started to get cataloged. I remember back then you had to pay some
company (only remember it started with "D") to access their database to
get at their archived data.

http://www.idlsoc.com/Documents/Symp...LS2007_CDL.pdf

That has a data linkk model diagram. That seems to show what the CDL
controller (hardware as the base station) would have but also indicates
that data can also come from or go to a network - which then means an OS
might be involved on some general-purpose (or even specific-purpose)
host (aka computer).

CDL might mean Common Data Link, CAT's CDL, even how to handle CDL files
(http://www.solvusoft.com/en/file-ext...xtension-cdl/). So
far, all we can tell is that the CDL protocol defined in the Windows
registry points at urlmon.dll. Monitoring what exports are called by a
process that found urlmon.dll through the CDL protocol definition might
give a clue as the function of the caller process.

What are you using to detect when your dummy file gets accessed when
something attempts to use the CDL protocol that would've pointed to
urlmon?

R.Wieser wrote on 2016/02/28:

I'm not in the habit of downloading PDFs (active contents and all
that.

Don't know which PDF viewer you use. Even Adobe's can be locked down.
I use PDFxchange and configure it for: disable Javascript (the biggie
vunerability), opening any non-PDF attachments in the PDF, disable
launch actions.

Disabling Javascript is probably the best security measure; however, it
will kill any active PDFs that, for example, do input validation. If it
has a form for you to fill in, they can use Javascript to validate you
entered the correct type of data, like a number in a number field and
not an alphabetic character. I've run into very few of those and only
for PDFs distributed within the company to its employees.

PDFs can have attachments. Yep, just like e-mails, you can embed an
attached file into a .pdf file. For example, this can be used to track
changes in a document. You send someone a PDF, they edit it and send it
back to you and maybe to someone else in your team. The other team
member may not have the original so they attach the original .pdf to
their modified .pdf file. However, unfortunately any filetype can be
attached to a PDF, including executables. So I configure my PDF viewer
to only allow PDF attachments to PDFs.

You wouldn't think Adobe would do this but they allow a PDF to define a
launch action. When you load a .pdf, and if it defines a launch action,
it can run a command (which can run any executable) just by loading the
PDF. Very dangerous. So that definitely gets disabled.

Most PDF viewers support all the features of PDF. Yep, the above
features are in the PDF specifications. There are some PDF viewers that
deliberately do NOT support the above features hence they are safer. I
prefer to use a more robust PDF viewer with options to let me disable
all that crap.

There was a vulnerability that was attributed to PDFs regarding a
vulnerability in fonts (somehow using corrupt ones that caused calling
Adobe's font program - long dead). The vulnerability wasn't actually in
the PDF but in Adobe's font manager (Adobe Type Manager) program; see
https://technet.microsoft.com/en-us/.../ms15-078.aspx. The
PDF just happen to carry the font vulnerability because the reader had
to pass the font to ATM to render it in the PDF viewer. Any doc viewer
could express that font vulnerability in ATM. The fix was to get
disable the ancient ATM program or get an update to it that closed the
vulnerability (I think Microsoft actually passed out that patch). Does
anyone still use Type 1 fonts (over 20 years old)?

https://en.wikipedia.org/wiki/Adobe_Type_Manager

I'm using Windows 7 Home Edition x64 Sp-1 and, yep, there are still
atm*.dll files lingering under the \system32 and \SysWOW64 folder. I
don't have any Type 1 fonts so I don't need their ATM software yet
Microsoft leaves it in Windows (just like the likely dead CDL protocol).
Just more cholesterol plugging the arteries. The security bulletin says
how to disable but Microsoft really should list it in the Add/Remove
Programs applet so users can uninstall it. It used to be uninstallable
from there; see http://www.adobe.com/support/techdocs/328603.html.

As I mentioned before, a dummy DLL. One with no externally callable
functions. In its "Process Attach" initialisation I've used
GetModuleFilename to figure out which program tries to use it. It
shows that string in a message box. Thats all. Rather KISS, don't
you think ?

Smart. About the only additional feature you might want is it to log
the accesses rather than annoy you with popups - if you ever get any.

I take it you have not yet seen your popup alert?

VanguardLH,

Don't know which PDF viewer you use.

The best know, and rather default one, Adobes one.

... and configure it for: disable Javascript (the biggie vunerability),
opening any non-PDF attachments in the PDF, disable launch
actions.

I would prefer a *reader* to behave like one. Seeing the never-ending
stream of bug and security fixes going into "it must be able to do
everything" (aka: feature creep encumbered) software I do not believe such
programs will *ever* be even decently secure. Combine that with throwing
active content at it that is found laying on the internet highway somewhere
and you have a recepy for disaster.

I always find it odd: If I pick up some candy from the ground (or appear
to do so :-) ) and offer it to someone they most always decline ....

There are some PDF viewers that deliberately do NOT support
the above features hence they are safer.

I would love to know which ones they are. Some time ago I though to try
FoxIt -- regarded by its own site as a "Secure PDF Reader", and the first
damn thing it tried to do when I started it was to try to go on-line. That
was enough for me to directly de-install it. :-(

About the only additional feature you might want is it to log the
accesses rather than annoy you with popups - if you ever get any.

Not really needed. All the message box is good for is so that I, in the
next few weeks/months, become instantly aware if-and-when something uses
that CDL protocol. If the protocol is not used than I can leave the
message box in for the chance it will get used somewhere (far) in the future
(when I've forgotten I've disabled it).

If it however starts to throw lots of message boxes at me I will know that
there is a problematic program, and will either tame the program itself, or
black-list the programs name in the dummy DLL, bypassing the message box.

Besides, if a program notices that it can't connect thru that CDL (or other)
protocol it will most likely throw an error. The message box is ment as a
kind of fail-safe for the programs which than silently don't.

I take it you have not yet seen your popup alert?

I've seen it once. That was when I entered an URL stating with the CDL
protocol into my browser (hey, I had to test if would actually work. :-) )

Regards,
Rudy Wieser


-- Origional message:
VanguardLH schreef in berichtnieuws
...
R.Wieser wrote on 2016/02/28:

I'm not in the habit of downloading PDFs (active contents and all
that.

Don't know which PDF viewer you use. Even Adobe's can be locked down.
I use PDFxchange and configure it for: disable Javascript (the biggie
vunerability), opening any non-PDF attachments in the PDF, disable
launch actions.

Disabling Javascript is probably the best security measure; however, it
will kill any active PDFs that, for example, do input validation. If it
has a form for you to fill in, they can use Javascript to validate you
entered the correct type of data, like a number in a number field and
not an alphabetic character. I've run into very few of those and only
for PDFs distributed within the company to its employees.

PDFs can have attachments. Yep, just like e-mails, you can embed an
attached file into a .pdf file. For example, this can be used to track
changes in a document. You send someone a PDF, they edit it and send it
back to you and maybe to someone else in your team. The other team
member may not have the original so they attach the original .pdf to
their modified .pdf file. However, unfortunately any filetype can be
attached to a PDF, including executables. So I configure my PDF viewer
to only allow PDF attachments to PDFs.

You wouldn't think Adobe would do this but they allow a PDF to define a
launch action. When you load a .pdf, and if it defines a launch action,
it can run a command (which can run any executable) just by loading the
PDF. Very dangerous. So that definitely gets disabled.

Most PDF viewers support all the features of PDF. Yep, the above
features are in the PDF specifications. There are some PDF viewers that
deliberately do NOT support the above features hence they are safer. I
prefer to use a more robust PDF viewer with options to let me disable
all that crap.

There was a vulnerability that was attributed to PDFs regarding a
vulnerability in fonts (somehow using corrupt ones that caused calling
Adobe's font program - long dead). The vulnerability wasn't actually in
the PDF but in Adobe's font manager (Adobe Type Manager) program; see
https://technet.microsoft.com/en-us/.../ms15-078.aspx. The
PDF just happen to carry the font vulnerability because the reader had
to pass the font to ATM to render it in the PDF viewer. Any doc viewer
could express that font vulnerability in ATM. The fix was to get
disable the ancient ATM program or get an update to it that closed the
vulnerability (I think Microsoft actually passed out that patch). Does
anyone still use Type 1 fonts (over 20 years old)?

https://en.wikipedia.org/wiki/Adobe_Type_Manager

I'm using Windows 7 Home Edition x64 Sp-1 and, yep, there are still
atm*.dll files lingering under the \system32 and \SysWOW64 folder. I
don't have any Type 1 fonts so I don't need their ATM software yet
Microsoft leaves it in Windows (just like the likely dead CDL protocol).
Just more cholesterol plugging the arteries. The security bulletin says
how to disable but Microsoft really should list it in the Add/Remove
Programs applet so users can uninstall it. It used to be uninstallable
from there; see http://www.adobe.com/support/techdocs/328603.html.

As I mentioned before, a dummy DLL. One with no externally callable
functions. In its "Process Attach" initialisation I've used
GetModuleFilename to figure out which program tries to use it. It
shows that string in a message box. Thats all. Rather KISS, don't
you think ?

Smart. About the only additional feature you might want is it to log
the accesses rather than annoy you with popups - if you ever get any.

I take it you have not yet seen your popup alert?