For successful exploitation, Scripting Plugin version 1.0 should be installed AND enabled in any DC client / versions that support DC Plugins. DC clients having this particular plugin not installed (or installed but as long as the plugin is in disabled state) are NOT vulnerable.

For users running Scripting Plugin version 1.0 it is highly recommended to upgrade to version 1.10 as soon as possible to get protected from this vulnerability.

Please note that a vulnerable function named LuaExec has been completly removed from the plugin’s scripting API and that this release also updates the internal Lua engine to the latest version, both of which changes may cause incompatibilities with existing customly created Lua user scripts.

We’d like to thank RoLex of Team Elite for reporting, sharing proof of concept and recommending fixes for this issue.

Native 64-bit support

As various MinGW forks that used to compile DC++ and target 64-bit are already stable enough, version 0.820 was the first DC++ that ships with native exectutables for 64 bit Windows operating systems. We provide two different portable versions for both of the architectures; on the other hand the installer package that most people use contains both the 32 and 64-bit builds and by default it automatically chooses the right binaries to install, depending on the used architecture. There’s an option though to override the default behavior and install the 32-bit version of the program on 64-bit systems.

Improved plugin interface and features

The first bits of the DC plugin API shed the light in DC++ version 0.800.  Since then the API has become matured and stable enough for wider usage.

Along with several fixes and improvements, plugins now possible to load/unload on the fly. DC++ also received new GUI controls for the most frequently used plugin functions. The new commands are available form File menu and also from the toolbar in form of a dropdown menu.

DC plugins also introduce a nice new packaging format (with .dcext file extension) that can contain several plugin binaries for different OSes and architectures as well as any additional files the creator of the plugin whishes to distribute with the plugins – all in a single compressed file.

Along with the new release of the newest plugin API in DC++ 0.822, the first DC Plugin Repository is also launched.  At the time of writing it already contains several nice new plugins made by the DC++ team to start with. We hope we’ll be able to expand the repository soon with 3rd party made plugins as well.  For more information how to download, install and use the plugins in your DC client, please visit the repository site.

The updated Plugin SDK is still available for developers;  you can also find detailed information about the plugin packaging to be able to create and distribute your own plugins. The DC Plugin repository is open for 3rd party developers and we encourage you all to create plugins for DC clients. When you ready to distribute your plugin you can find howto and contact information right there in the repository.

Introduce of expandable list items

Many DC++ users missed the expandable merged search results for a long time. They’re really useful and known from other DC clients. Good news: they’re here. Search results with the same TTH are grouped from now, you can easily add all the sources with one click or expand the results row and pick the one(s) you wish.

Due to the possibility of expandable list items the Transfers view is also completly revamped and merged from now. There’s no need of the cluttered Downloads and Connections tab anymore; all the downloads and uploads occupy one item in the list of all transfers and if there’s multiple connections to any transfer then you can view the individual connections by expanding the transfer list item. This change makes the Transfers view as usable as it was in the older versions of DC++ while the display structure is nicely adopted to the modern segmented transfers.

Various additional improvements

• User commands in the Transfers view context menu are back again
• It’s possible to log off from a hub without actually closing its window using the new Disconnect command in the tab’s context menu
• The entered search values are validated if you search by TTH from now;  only valid values will be sent and you get an error message on invalid values. This prevents unnecessary traffic to hubs as well as it comes handy when you want to send a textual search but you accidentally leave the TTH option selected (and get suprised as no results coming at all)
• HTTP transfers (hublists, version information) are shown in the Transfers view. It is useful in case of slow hublist transfers or when you want to pinpoint issues with hublist servers.
• Added support for region- or city-level GeoIP databases; you can use new formatting values to show more precise information about the user’s location in the Country coloumn of the users list and also in the Transfers view.

Note that version 0.820 is already released a week before 0.822, marked as “testing”. Due to some additional fixes and improvements on plugins handling the version number of the current stable release is bumped to 0.822. Upgrade is strongly recommended as usual.

I’d like to highlight three improvements that might need more attention:

• The Plugin API has been evolved further but it’s still not reached the stage where the plugin binaries are possible to distibute with the client. They’re still in a testing phase but binaries available from now to those who interested on testing. As long as the the final plugin distribution format is beeing implemented the nightly plugin binary builds are available in a simple .dll format at the Plugins archive of the DCBase Builds server.
  At the time of writing two fully functional and a test plugin are available. The LUA 5.2.1 client side Script Plugin is able to run all BCDC++ client side scripts. The Dev Plugin offers functions like monitoring the protocol talk, follow search requests (former Search Spy function) and more. Make sure you consult the readme file before downloading any revision of any plugins.
  For those who interested in creating plugins the source code,  SDK and Doxygen documentation is still available in the DCPP Plugins SDK repositories (C and C++).

• Fixing of two the two following long standing problems required to change the hash data file format: the case insensitive share format that caused problems on non-Windows clients based on the dcpp library and a bug with merging shares  containing same filenames/folders resulted an inconsistent behaviour.
  Because of these fixes if you upgrade from an eralier release the first start of the client might require a bit more time than usual. An automatic share format conversion will make you wait a bit more, depending on how large your share is.
  The bad news is that the automatic conversion is possible only on Windows Vista and later. Due to lack of extended file handling capabilities of the OS, the entire share needs to be rehashed for XP users.

• The only remarkable and very useful GUI improvement this time is the ability to copy data from every list view to the clipboard. It is possible through the lists’ context menus, using a new ‘Copy’ menu item. You are able to copy the content of one column or the data of all columns in one go.
  There’s also a special new menu item  (called “Copy user information”) for lists containing users; it’s made to easily gather all the available info (not just what’s displayed) about one user or multiple selected users copied to the clipboard.

Things looking good so far; this means that DC++ 0.810 should make stable within days. Upgrade is recommended as always.

The most important thing is that this feature marks a new era of DC++ in terms of customizability. In the last 10 years DC++ users have constantly come up with ideas to implement various options and features into DC++ and most of these were denied or put on hold forever – mostly because those features were thought to not be attractive to all or majority of the users. With the new plugin API, many of these features can be realized in a form of a separate plugin. Even rarely used existing features can be moved into plugins (first example of this is the Search Spy function which was moved to the Dev plugin). This keeps the client code clean and optimized to the most fequent usage scenarios.

But the list of general advantages of the plugin interface is not over yet. The additional benefits were already discussed and published here when the plugin API was in an early stage.

So what you have here is a quick Q&A about the most important information about this new feature; hopefully one of the actual developers of the API will come up with more detailed techincal information soon (and thanks iceman50 for helping me out with a few answers to the following questions).

Q: Is this plugin interface planned and made from scratch or maybe some previous versions/implementations are already released in some clients?

A: The current API was based off of the original implementation from ApexDC++. The original design is from Twinks plugin API in PhantomDC++ and the current API is what evolved from the ApexDC++ API.

Q: Is the current API compatible with any old plugins made for previous APIs?

A: No. The API has a versioning system that clearly defines what plugins can be used in a certain impementation of the API.

Q: Has the current state (version) of the API already been released in any client?

A: Yes. In ApexDC++ and DiCe++.

Q: Are there any plugins available to use?

A: Yes, though only a few yet. They can be built from the DC++ repository or downloaded from the DCBase builds archive. Update: as of 2012.11.15 C and C++ plugins have their own SDK and repository at https://code.launchpad.net/dcpp-plugin-sdk-c and https://code.launchpad.net/dcpp-plugin-sdk-cpp respectively. The repositories also contain the source code of the existing example plugins. Note that plugins built from the SDK are not compatible with the current DC++ release (0.802). For those plugins to properly run you need the latest nightly build of DC++.

Q: What about the LUA scripting plugin availabe in the DC++ repository? Is it the one that’s been in BCDC++ for a while? Is this plugin compatible with the client side LUA scripts already available for BCDC++?

A: Yes, the LUA 5.2.1 client side script plugin works with all BCDC++ scripts in their Bzr repository.

Q: I want to make plugins for DC++. Is there any documentation to start with?

A: There’s no documentation yet, but DC++ the repository contains a self-explanatory example plugin what you can use for a start. Update: use the links to the SDKs above to get example source codes.

Q: Will this plugin API be frozen for a while or it’ll be developed further?

A: The API will certainly change with time. Most likely the next improvement will be a binary format change; the plugin .dll planned to be packed in to an archive with an accompanying .xml file containing the plugin version and other information. You can expect further changes coming as well.

2013.06.11 update: more recent information about the current state of the plugin API and the official DC Plugin Repository in the DC++ 0.822 announcement post.

Some, but not all, of their functionality could be implemented via a plugin interface which would allow many users of those mods to instead use the official DC++ client. This has advantages in terms of:

• bug reporting (rather than users in each client having to independently discover bugs, bug reporting could be more centralized)
• bug fixing (rather than a choice of either each mod author separately patching his client or syncing with DC++ when it might not be appropriate)
• security responsiveness (an important special case of bug fixing; especially a problem for second or third-tier derivatives which need to either wait for fixes to propagate down the mod dependency graph, remain vulnerable, or specifically re-implement some fix that will automatically appear for them in DC++ regardless)
• security improvement, if features already extant in DC++ can be reimplemented in a safer scripting language as opposed to C++ (Python/Perl/Lua/etc all avoid entire classes of bugs by default which C++ code can be vulnerable to)
• ease maintenance of somewhat fringe/marginal features which some people enjoy (for example, now-playing song/music spamming) but which aren’t necessarily appropriate to maintain in the core DC++ application
• maintaining a DC++ brand image (every mod doesn’t have to be identical, but because each mod can lag, it can force users into unpleasant choices, which can hurt the DC++ brand)
• user control of clients (some changes can be easy for technically sophisticated end-users to create and distribute, but again are not always appropriate for all users)

One such proposal, which I essentially support, has been implemented by Crise and proposed by him and Toast.