No, because you wouldn’t be able to execute the updated exe without a valid signature. You would essentially brick the install with that method, and probably upset Microsoft’s security software in the process.
I meant the old .exe would check the signatures before initializing the official Windows way to update. Effectively have this run whenever you start the application:
main() {
if (update_available()) {
exe_path = download_update()
if (signature(exe_path) == SIGNATURE) {
install_update(exe_path)
restart()
} else {
put_up_a_warning_or_something()
delete(exe_path)
}
}
# Rest of the application# ...
}
The only thing I have no idea how to implement would be the install_update(path) function. But surely this is one way to install updates without signatures recognized by Microsoft, right?
And if for some reason you aren’t allowed to sign the .exe because this breaks something, then place an unsigned .exe in a signed zip folder.
I don’t know enough about Windows app development to answer this. Maybe it replaces the old .exe and the now replaced .exe is just continuing to run from RAM? Maybe there is some restarter.exe program in the same folder that does all the work. In any case, this depends far too much on the Windows update process and how to launch applications.
I just know when I used Windows applications in the past, they were able to restart themselves after updating somehow.
After an update on Windows, you must close the application to clear the RAM before launching the updated exe.
Upon launching the new binary exe, Microsoft will check the code signing certificate and make sure its valid before letting it execute. If its not signed, you will be met with a warning that the binary publisher is unknown, and I believe that Microsoft won’t even let it launch nowadays
that’s all completely irrelevant…, there is already an update mechanism built into NPP: that’s the entire point of the attack… it’s this update mechanism that got hijacked
there are more ways to do signing than paying microsoft boat loads of money… just check a gpg sig file ffs (probably using detached signatures: again, it’s already built into existing tools and it’s a well-known, easily solved problem)
what’s irrelevant is the argument about how the auto update mechanism would work because it already exists
The answer to that question is honestly super complicated, and it has its own job title tbh. Managing code signing certificates can be really complex depending on the software.
Im not sure. I don’t have Windows to look at the code signing certificate they are using (if they are using one at all). Hopefully someone else can check and let us know.
Yes, but from what I understand this refers to the automatic update functionality and not Microsoft’s own .exe signature verification thing.
Couldn’t you do it like this:
That should work, shouldn’t it?
No, because you wouldn’t be able to execute the updated exe without a valid signature. You would essentially brick the install with that method, and probably upset Microsoft’s security software in the process.
I meant the old .exe would check the signatures before initializing the official Windows way to update. Effectively have this run whenever you start the application:
main() { if (update_available()) { exe_path = download_update() if (signature(exe_path) == SIGNATURE) { install_update(exe_path) restart() } else { put_up_a_warning_or_something() delete(exe_path) } } # Rest of the application # ... }The only thing I have no idea how to implement would be the
install_update(path)function. But surely this is one way to install updates without signatures recognized by Microsoft, right?And if for some reason you aren’t allowed to sign the .exe because this breaks something, then place an unsigned .exe in a signed zip folder.
After you install the update, which exe will you execute after the app restarts?
I don’t know enough about Windows app development to answer this. Maybe it replaces the old .exe and the now replaced .exe is just continuing to run from RAM? Maybe there is some restarter.exe program in the same folder that does all the work. In any case, this depends far too much on the Windows update process and how to launch applications.
I just know when I used Windows applications in the past, they were able to restart themselves after updating somehow.
After an update on Windows, you must close the application to clear the RAM before launching the updated exe.
Upon launching the new binary exe, Microsoft will check the code signing certificate and make sure its valid before letting it execute. If its not signed, you will be met with a warning that the binary publisher is unknown, and I believe that Microsoft won’t even let it launch nowadays
that’s all completely irrelevant…, there is already an update mechanism built into NPP: that’s the entire point of the attack… it’s this update mechanism that got hijacked
If Notepad++ had a valid signing certificate, you wouldn’t be able to run the malicious binary in the update. How is that not relevant?
there are more ways to do signing than paying microsoft boat loads of money… just check a gpg sig file ffs (probably using detached signatures: again, it’s already built into existing tools and it’s a well-known, easily solved problem)
what’s irrelevant is the argument about how the auto update mechanism would work because it already exists
How are they doing it now, then?
The answer to that question is honestly super complicated, and it has its own job title tbh. Managing code signing certificates can be really complex depending on the software.
This gist kinda covers the basics
https://gist.github.com/MangaD/e8f67fb39a35abdbf4ad26711c5957cc
No, I meant how are Notepad++ people doing it currently when people claim they aren’t already signing their exe?
Im not sure. I don’t have Windows to look at the code signing certificate they are using (if they are using one at all). Hopefully someone else can check and let us know.