Stop using x64dbg/PluginManger releases for distribution
mrexodia opened this issue · 11 comments
Hey,
Today I checked the plugin manager again and noticed it is still using https://github.com/x64dbg/PluginManager/releases for both plugins and x64dbg updates. I don't think this should be done because it introduces expectations that those binaries are official where in reality they are not. For x64dbg releases I think it should directly use the latest github snapshot and the releases API and for plugins I think there can be a json in the PluginManager repository that points to the official plugin release URL.
Best regards,
Duncan
Hello Duncan, thanks a lot for the bugreport.
I don't think this should be done because it introduces expectations that those binaries are official where in reality they are not.
Yes it is a real problem. We cannot be responsible for the content of some plugins, some of them are not open source
I think it should directly use the latest github snapshot and the releases API
Yes, we can do it. If you can guarantee that the structure of the zip archive format in https://github.com/x64dbg/x64dbg/releases will not change every time.
for plugins I think there can be a json in the PluginManager repository that points to the official plugin release URL.
This is not entirely clear. Should we write our own set of rules in a json file for each plugin, or should developers place a zip file of a certain format at their repos. Then it’s not entirely clear whether we can convince them all to do this, since some plugins have not been updated for years and their developers may not want to continue their development.
I updated the json.list for the current version of x64dbg, but of course this is a temporary solution.
Yes, we can do it. If you can guarantee that the structure of the zip archive format in https://github.com/x64dbg/x64dbg/releases will not change every time.
In the GUI there is a 'Check for updates' mechanism which depends on this structure. Because old versions can query this Github API endpoint it has to stay compatible forever. You can find the code here: https://github.com/x64dbg/x64dbg/blob/193eb52ef55cbd568d4d78b2038ed517a09d6bab/src/gui/Src/Utils/UpdateChecker.cpp#L20 Similar to LFried's updater plugin you could use the commithash.txt to detect the current version, or perhaps use the build date which will be in the executable PE header (I didn't check the existing code).
If you mean to create a new release every time, I'm a bit hesitant because in the past GH enforced limits on repository size but it can be considered (although even if I do this it will change nothing about the update check because I use /latest). If you need stable binary links, all of them are archived on OSDN and SourceForge, perhaps they also offer an API that could be used to check for updates.
The contents of the zip did not change for 4 years and I'm not expecting any changes there either, because currently it's very easy to update manually and I would like to not make this harder :)
This is not entirely clear. Should we write our own set of rules in a json file for each plugin, or should developers place a zip file of a certain format at their repos. Then it’s not entirely clear whether we can convince them all to do this, since some plugins have not been updated for years and their developers may not want to continue their development.
My suggestion for this would be to allow installing any directory structure and then in the JSON for PluginManager put a description where to download + how to install. The author can then send a pull request to update this JSON to directly use their JSON later.
In the GUI there is a 'Check for updates' mechanism which depends on this structure. Because old versions can query this Github API endpoint it has to stay compatible forever. You can find the code here: https://github.com/x64dbg/x64dbg/blob/193eb52ef55cbd568d4d78b2038ed517a09d6bab/src/gui/Src/Utils/UpdateChecker.cpp#L20 Similar to LFried's updater plugin you could use the
commithash.txtto detect the current version, or perhaps use the build date which will be in the executable PE header (I didn't check the existing code).If you mean to create a new release every time, I'm a bit hesitant because in the past GH enforced limits on repository size but it can be considered (although even if I do this it will change nothing about the update check because I use
/latest). If you need stable binary links, all of them are archived on OSDN and SourceForge, perhaps they also offer an API that could be used to check for updates.The contents of the zip did not change for 4 years and I'm not expecting any changes there either, because currently it's very easy to update manually and I would like to not make this harder :)
Fine. From this point everything is clear. :)
I will do it ASAP.
At the moment I do. https://github.com/horsicq/XPEViewer and I want to make a public release within a week. This is an analogue of this project https://github.com/horsicq/XELFViewer, but for PE files, then a new version of DiE is next in line.
Then I will take up this project.
If during this time new versions of x64dbg are released, then I will manually change the json.list. GH size is not a problem, as we can always delete old releases.
My suggestion for this would be to allow installing any directory structure and then in the JSON for PluginManager put a description where to download + how to install. The author can then send a pull request to update this JSON to directly use their JSON later.
It’s possible right now just to replace the link to bundle. For example
"Src": "https://github.com/x64dbg/PluginManager/releases/download/base/Highlightfish.x64dbg.zip",
should replace to http://ANOTHER_REPO/Highlightfish.x64dbg.zip and it will work.
The bundle could easily create with x64dbgPluginManager(GUI or console version).
I'm I was more thinking about something like this:
In list.json on PluginManager repo:
{
"Author": "XeroNicHS",
"Bugreport": "https://github.com/XeroNicHS/x64dbg_AttachHelper/issues",
"CompressedSize": 82395,
"Date": "2020-01-04",
"Info": "This plugin automatically restores 'DbgBreakPoint', 'DbgUiRemoteBreakin'.",
"Is32": true,
"Is64": true,
"Name": "AttachHelper",
"SHA1": "3cbe699622b1094d5c03f95154003482e64df77a",
"Size": 161527,
"Src": "https://github.com/x64dbg/PluginManager/releases/download/base/AttachHelper_1.0.0.x64dbg.zip",
"Version": "1.0.0",
"Transition": {
"Rewrite": {
"AttachHelper.dp32": "files/x32/plugins/AttachHelper.dp32",
"AttachHelper.dp64": "files/x64/plugins/AttachHelper.dp64"
},
"PluginInfo":
{
"Author": "XeroNicHS",
"Bugreport": "https://github.com/XeroNicHS/x64dbg_AttachHelper/issues",
"CompressedSize": 81927,
"Date": "2020-01-04",
"Info": "This plugin automatically restores 'DbgBreakPoint', 'DbgUiRemoteBreakin'.",
"Install": [
{
"Action": "make_directory",
"Path": "x32"
},
{
"Action": "make_directory",
"Path": "x32/plugins"
},
{
"Action": "make_directory",
"Path": "x64"
},
{
"Action": "make_directory",
"Path": "x64/plugins"
},
{
"Action": "copy_file",
"Path": "x32/plugins/AttachHelper.dp32",
"SHA1": "87935e7155658baba1770b16536dc3958f7d6d37"
},
{
"Action": "copy_file",
"Path": "x64/plugins/AttachHelper.dp64",
"SHA1": "1c1e2efc55e306dee154ce70d6b585b9bc5ee958"
}
],
"Is32": true,
"Is64": true,
"Name": "AttachHelper",
"Remove": [
{
"Action": "remove_file",
"Path": "x32/plugins/AttachHelper.dp32"
},
{
"Action": "remove_file",
"Path": "x64/plugins/AttachHelper.dp64"
},
{
"Action": "remove_directory_if_empty",
"Path": "x64/plugins"
},
{
"Action": "remove_directory_if_empty",
"Path": "x64"
},
{
"Action": "remove_directory_if_empty",
"Path": "x32/plugins"
},
{
"Action": "remove_directory_if_empty",
"Path": "x32"
}
],
"Size": 159744,
"Src": "AttachHelper_1.0.0.x64dbg.zip",
"Version": "1.0.0"
}
}
}Hmm. The concept is not quite clear. "Remove" and "install" sections are already in the zip bundle.
Are you offered to simply transfer this to the json.list on the server? What are the benefits of this?
The "rewrite" section is also non-point. Should this work without SHA1? Or how?
OK. Now everything is clear. Yes, that makes sense. I think for some plugins this can be done easily. Of course I need to research this and make some experiments.
It will be something like this
{
"Date": "2020-08-20",
"Modules": [
{
"Author": "mrexodia",
"Bugreport": "https://github.com/x64dbg/x64dbg/issues",
"Info": "An open-source x64/x32 debugger for windows.",
"Is32": true,
"Is64": true,
"Name": "x64core",
"Type": "GITHUB_ZIP",
"Github": "https://github.com/x64dbg/x64dbg",
"Pattern": "snapshot",
"Convert": [
{
"Action": "unpack_file",
"Src": "commithash.txt",
"Path": "commithash.txt"
},
{
"Action": "unpack_directory",
"Src": "release",
"Path": "/"
}
]
},
{
"Author": "hors",
"Bugreport": "https://github.com/horsicq/stringsx64dbg/issues",
"Info": "Strings plugin. ANSI and UNICODE. RegEXP support.",
"Is32": true,
"Is64": true,
"Name": "stringsx64dbg",
"Type": "GITHUB_ZIP",
"Github": "https://github.com/horsicq/stringsx64dbg",
"Pattern": "release.zip",
"Convert": [
{
"Action": "unpack_directory",
"Src": "release",
"Path": "/"
}
]
}
]
}Looks great!