Plugin for IDA 8+ #124
Comments
|
As of IDA 1.8 you can have private Lumina servers up, of which you can just configure a connection to in IDA Options. IDA does not allow connection to a private server without credentials (for some reason) - patching it out causes a trusted cert issue. Apparently these instances also require a trusted certificate. |
|
Yes, that's why I would like to create an open source plugin for this (or use this one #117 (comment)). |
|
Okay, I guess found what is The problem with the Lumina Servers Certificate.So I decompiled ida64.dll to of IDA Pro 8.3 to fix that stupid "invalid_remote_certificate" error. So it needs to have a broken chain: Check the sites yourself: Here is the entire function: bool IDA_CheckCert(struct_IdaCert *aCert)
{
if ( aCert->CerErrCode = QueryContextAttributesA(&aCert->sechandle78, 0x53u, &pBuffer) ) {
aCert->CerErrText = "QueryContextAttributes(SECPKG_ATTR_REMOTE_CERT_CONTEXT)";
return 0;
}
memset(&pChainPara, 0, sizeof(pChainPara)); pChainPara.cbSize = 32;
// First time CertificateChain
if ( !CertGetCertificateChain(0i64, pBuffer, 0i64, pBuffer->hCertStore, &pChainPara, 0, 0i64, &pChainContext) ) {
aCert->CerErrText = "CertGetCertificateChain[1]"; aCert->CerErrCode = GetLastError();
return 0;
}
TrustStatus_dwErrorStatus = pChainContext->TrustStatus.dwErrorStatus; CertFreeCertificateChain(pChainContext);
if ( (TrustStatus_dwErrorStatus & 1) != 0 ) { // =0x1 -> CERT_TRUST_IS_NOT_TIME_VALID
aCert->CerErrText = "expired_remote_certificate";
return 0;
}
// Problem the lumina servers certificate must have the error of an broken certificate chain to be 'genuine'
// https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/ns-wincrypt-cert_trust_status
if ( TrustStatus_dwErrorStatus != CERT_TRUST_IS_PARTIAL_CHAIN ) { //= 0x10000 The certificate chain is not complete.
aCert->CerErrText = "invalid_remote_certificate";
return 0;
}
if ( !CertAddEncodedCertificateToStore(pBuffer->hCertStore, 1u, aCert->pbCertEncoded, aCert->cbCertEncoded, 2u, 0i64) ) {
aCert->CerErrText = "CertAddEncodedCertificateToStore"; aCert->CerErrCode = GetLastError();
return 0;
}
// Second time CertificateChain
if ( !CertGetCertificateChain(0i64, pBuffer, 0i64, pBuffer->hCertStore, &pChainPara, 0, 0i64, &pChainContext) ) {
aCert->CerErrText = "CertGetCertificateChain[2]"; aCert->CerErrCode = GetLastError();
return 0;
}
TrustStatus_dwErrorStatus = pChainContext->TrustStatus.dwErrorStatus; CertFreeCertificateChain(pChainContext);
// lumina server cert chain must NOT end in a root certificate
// If lumen.abda.nl Cert is in Root Trust ; TrustStatus_dwErrorStatus gets 0x0 (CERT_TRUST_NO_ERROR)
if ( TrustStatus_dwErrorStatus != CERT_TRUST_IS_UNTRUSTED_ROOT ) { // = 0x20 The certificate or certificate chain is based on an untrusted root.
aCert->CerErrText = "invalid_remote_certificate";
return 0;
}
if ( CertVerifyTimeValidity(0i64, pBuffer->pCertInfo) ) {
aCert->CerErrText = "expired_remote_certificate"; CertFreeCertificateContext(pBuffer);
return 0;
}
else if ( CertGetNameStringA(pBuffer, 3u, 0, "2.5.4.3", pszNameString, 0x400u) <= 1
|| !strcmp(pszNameString, "internal.hex-rays.com") )
{
aCert->CerErrText = "invalid_remote_certificate"; CertFreeCertificateContext(pBuffer);
return 0;
}
else {
CertFreeCertificateContext(pBuffer);
return 1;
}
}So until you somehow get it done to craft a certificate with a broken chain for the lumina server on lumen.abda.nl. Fileoffset: 000B00E8 32 C0 -> B0 01 You are using a different Version of IDA?->So that is how to find the file offset Having ida64.dll loaded press Shift+F4 to open "Strings" Edit\Patch program\Patch Bytes Well file is probably in use and save not possible. |
|
@naim94a you wanted open source? Here you go https://github.com/tomrus88/OpenLumina. But you will have to create new server certificate because your old certificate doesn't use certificate chains as intended by IDA and official Lumina servers (both public and private). Scripts to generate new compatible certificates can be found in plugin repo. Certificates generated by provided scripts use exact same settings that are used to generate official Lumina server certificates, the only difference is that we create our own private keys (because we don't have original ones). The idea is so that this plugin works with both your server as well as official private Lumina servers (but pirated). In the feature, once you update your server certificate, I think it should be possible to include that new certificate within the plugin as preset certificate (hardcode it just like IDA does) so that users don't have to copy both certificate file and plugin to theirs IDA's. There's also performance benefit from using new generated TLS certificates because they are ECC based certificates instead of RSA. ECC certificates use much shorter keys (256 bits instead of 4096 bits) and that means it's much easier for both server and client to deal with encryption.
This is completely new plugin that was created from scratch today and uses different method (compared to method used in old plugin I shared previously) to fix certificate issues in newer IDA versions. Edit: there's appears to be a bug that prevents this method from working correctly if Lumen server is running on Windows OS, server doesn't send whole certificate chain from certificate file to client as intended for some reason, only first certificate from the chain is being sent and that causes validation on client to fail... Bug is probably somewhere in Windows schannel (less likely) or in rust-native-tls library and it's dependencies (most likely)... Edit2: found a workaround for that bug where when hosting Lumen server on Windows OS it's not sending full certificate chain, if you manually install your generated intermediate certificate to "Current User" certificate store under "Intermediate Certificate Authorities" -> "Certificates" category, server will send certificate chain correctly and validation will succeed as intended. Plugin is Windows only because:
Edit3: there's now experimental versions of plugin for Linux and MacOS. If someone knows how to add Linux/MacOS support to the plugin, feel free to submit PR. |
|
I've also created plugins for Linux and MacOS, they seems to work fine during my limited testing on local server. I had to add support for Linux/MacOS to my closed source plugin that brings Lumina functionality to IDA Freeware to be able to test it, but for version 8.4 only, because those OS's are pain to work with and there's some differences in IDA internals between versions making it even more pain. But we still need server certificate update for it to be useful. At least people who run theirs own Lumina server can use plugin now as long as they generate new compatible certificate. |
Update why exactly? Are you claiming it doesn't work with IDA 9.0? |
|
pretty sure it is working, ida 9 supports secondary servers which idk how to setup though |
Ok, that means IDA now checks SDK version of the plugins and don't load any old ones. Need to recompile it with IDA 9.0 SDK. Try this new version for IDA 9.0 Beta 2: luminafix64.zip |
|
I've published new release of OpenLumina plugins with support for IDA 9.0 Beta on https://github.com/tomrus88/OpenLumina/releases/tag/openlumina-v0.3. There's issues with macos version due to bugs in third party plthook library used for hooking. Sadly they still won't work with lumen.abda.nl server because it still uses incorrectly generated certificate... But they should work with any other lumina server that is using correctly generated certificates. Information on how to generate correct certificate can be found here https://github.com/tomrus88/OpenLumina/tree/cmake-build/lumina_ca. |
I don't think there is a saying of "incorrectly generated certificates" for this case, or for the original expected code, any certificate not issued by Hex Rays is an "incorrectly generated certificate". OpenLumina uses hook to turn some "incorrectly generated certificates" into "considered correct certificates". Similarly, we only need more hooks to make Lumen's certificate also become a "considered correct certificate". In addition, there are some components on IDA 9.0 beta that do not load plugins, such as vault/lumina client/server, so a version that is not a plugin is also required. For these reasons, I wrote my own version, opensourced at https://gist.github.com/qwerty472123/c2155683c6c4713bdf160cf8add3fe52 with binaries. |
|
@qwerty472123 Is your solution only for Windows? |
Just open the link https://gist.github.com/qwerty472123/c2155683c6c4713bdf160cf8add3fe52. The linux is prior to the Windows。 I tested for Windows and Linux, and I donnot have a mac. |
Any certificate that is not generated using same settings as original one are considered incorrectly generated. That's matter of a fact. With correctly generated certificate you can just replace hardcoded certificate in any of IDA executable and it will work without any additional changes to the code, need of injection, hooks etc.
This is not true at all. What OpenLumina does is it adds more trusted certificates in addition to hardcoded one.
Yeah and that makes it so much more complicated for no reason. It's much easier to just generate correct certificate instead.
For those I choose to either patch them manually by changing either certificate validation code or replacing original certificate inside them with our own. Those components were not a scope of the plugin anyway.
Your approach is so unnecessary overcomplicated... |
Interesting definition, I admit that I did not notice this possibility. But I prefer the definition 'making the existing Lumen server work is the correct implementation of the plugin for this issue'.
Maybe you're talking about something other than At least this code is clearly using hook. The "adds more trusted certificates in addition" is just the goal that hook achieved. And hook can achieve other things like "adds more trusted certificates in addition even if it is using current lumen settings".
This does make sense. For example, users using the old version of IDA+lumen(this repository) and users using the new version of IDA+lumen can continue to access the same domain as their Lumina server without any modifications from Lumen itself or settings for the old version of IDA now. Or someone may want to use Lumina certificates that are trusted by Windows certificate store.
I think the complexity of this approach lies in its code implementation, but not in its dependencies and its users. In fact, the version that only supports “Lumen settings” certificates is equally simple (only requiring a hook, a memcmp). But after reading your version, I realized that it can support for other "settings", and the "overcomplicated" is actually introduced to support certificates with trusted(by Windows certificate store) roots. Note: this approach does not trust all root certificates in the Windows certificate store, but only allows users to add trust to the certificates stored there. |
No it's not correct implementation as it makes it work with incorrectly generated certificates. Existing server must update its certificate to be compatible with a plugin. Updating it is not that hard. But it's been a months and certificate used by lumen.abda.nl is still not updated... |
Well, if you insist on a definition of "correctness" that has inconsistent behavior with the Linux version (the Linux version allows any root certificate to be trusted), relies on the user's specific configuration of the operating system (the user cannot add any root certificate trusted by IDA to the system root certificate store, otherwise it will be prompted that the certificate is "invalid"), and is incompatible with existing lumen services. I admit that is indeed an interesting point of view. |
|
Your linux version works fine for lumen server, which you called it "bad certificate". The correct certificate verification process should clearly not trust any certificate that is considered "bad" by its writer.
As you mentioned, the prompt is "invalid remote certificate". If you believe this is caused by improper local configuration, then IDA should prompt "improper local configuration". Like those crashes in IDA 9.0 beta for Arm, this is another IDA bug, has minor effects.
The existing Lumen server requests people to add "End Entity" trust to a domain owned by its owner, which is a very normal and reasonable certificate behavior. And your configuration requires people to trust a "CA" organization, which will have a clear dishonest behavior of issuing a certificate to someone who has never owned the vault.hex-rays.com domain. Obviously, the former method is more correct. |
If this is a case (which i'm not even sure is true), then it's IDA's internal certificate verification logic flaw, we have no control over it and we should not interfere with it as long as connection to server works.
I don't believe anything, it's matter of a fact. Error message may not be great, but we don't have a control over what error IDA shows when it doesn't like remote server certificate. This is non issue.
This is a lie. In both cases user must trust certificate of the server. There's absolutely no difference if it's so called "End Entity" or CA. They are both self signed certificates issued by server owner. You either trust them or not, simple as that. Somehow official Hex-Rays customers doesn't complain they have to trust to self signed CA certificates. Basically you just taken it all out of your arse just to argue with me. There's also many benefits of having CA and certificate chain. For example this way you can re-issue server certificate literally every day and users won't have to do anything on theirs end as long as root CA certificate is still valid (not expired), since IDA uses CA root certificate for validation. Contrary if server used incorrectly generated certificates without CA and chain like you are suggesting, users will be forced to download new certificate every single time new certificate is issued to continue using server, which is not great user experience. Another benefit of correctly generated certificate is performance (i've already talked about that before) as it uses different encryption algo that is faster, but provides same (if not better) security. |
The purpose of a certificate is not just to work, otherwise we wouldn't even need TLS.
But this situation is that the remote certificate has not changed, only the configuration of the user's operating system has changed to add more trust to the certificate.
End Entity cannot issue certificates.
Hex Rays' self signed certificates have honest behavior of issuing certificates for the domains they own, while the "correctly generated certificates" you claim are the opposite.
In fact, it is you not me. There are no technical issues with supporting existing Lumen certificates, but in order to oppose this, you have created the concept of "correctly generated certificates" that must have the same settings as Hex Rays. But if you acknowledge that these "settings" have make sense, then it cannot be avoided that the settings you provide involve dishonest behavior such as claiming to be the owner of "Hex-Rays" and "vault.hexrays. com".
In fact, during the IDA7.0 era, Lumen certificates could be easily trusted, even easier than what you call "correctly generated certificates", as it did not require any change in binaries. Obviously, in that era, it was a "more correct certificate". The counts for user-participated certificate updates to adhere to "correctly generated certificates" (yes, this does not matter for new version IDA users, but old version IDA users are also required to synchronize certificate updates) will only increase.
This is a lie. Longer certificate chains require more network traffic, and clients must verify the entire certificate chain (including multiple RSA and ECDSA signature verifications), which wastes more resources (if not ignorable). Any signature on the certificate chain that can be forged can achieve a MITM attack, so its security will be the minimum value of RSA and ECDSA, so this scheme will only be less secure (if not equal). |
Majority of people don't care. All they want is things to work.
Adding random self signed certificate into system certificate store doesn't "add more trust to the certificate", stop being delusional.
Doesn't matter if it can or can't issue certificates. I repeat it again: you either trust it or not.
No they don't have "honest behavior", you keep pulling shit out of your arse, they are even more dishonest, because you are not even connecting to domain that is specified in theirs certificate when using official lumina servers, you are connecting to absolutely different domain. The reason they do it is because domain doesn't matter, you can put literally anything as domain name and it will still work just fine. Neither you can verify that they in fact own that domain listed in theirs certificate. Not that it actually matters...
There's no technical issues other than wasting more time to support those incorrectly generated, broken certificates. So why bother when anyone can make proper ones in a matter of seconds. Also there's no claim of being owner of some domain, you are pulling that shit out of your arse again. It's just settings that are identical to official certificate, nothing more. If anything, it only makes those proper certificates more of official ones. In the end no one is preventing you from changing organization and domain name in provided openssl configuration. It's just a template for people to use, but you are too dumb to understand that...
No they won't increase, stop pulling shit out of your arse.
Stop making claims when you have absolutely no clue what you are talking about, you are starting to look like a clown that comes here every day just to argue with me and make me laugh so hard... So please shut the fuck up and stop wasting my time.
https://www.ssl2buy.com/wiki/rsa-vs-ecc-which-is-better-algorithm-for-security |
The certificate chain you issued consists of two 4096-bit RSA certificates and one 256-bit ECDSA certificate. The consumption during transmission and client verification is the sum of the three, and security is the minimum value of the three. As mentioned in the link you provided(do you read it actually?), the security of 256 bit ECDSA is generally considered to be the same as 3072 bit RSA, rather than 4096 bit. If you believe that the final level certificate requires more time, please review the TLS handshake process instead of engaging in verbal harassment. One more thing, these beginner's introduction do not inform you that signature algorithms that rely solely on ECDLP including EdDSA which based on Fiat-Shamir transform, while ECDSA need extra relies on the correctness of ECCDH assumption. The selection of the P-256 curve is also highly controversial. If you are interested in getting started with cryptography instead of continue arguing without reason, please refer to https://safecurves.cr.yp.to/.
Please review the meaning of the CN field (Common Name) in the certificate, rather than engaging in speech attacks. If you still can't understand, please create a website yourself and use a CDN to proxy it by TLS , and then read the CN field of the certificate it provides.
Please read the section in Microsoft documentation about the usage of adding a certificate to root certificate store, rather than questioning it out of thin air.
My reasons have been given, please respond with reason instead of using aggressive language to refute.
Yes, and my tools(https://gist.github.com/qwerty472123/c2155683c6c4713bdf160cf8add3fe52) work, your tools need extra server-side changes. So don't argue with me just to argue with me, don't waste my time anymore, okay? |
And this is more than enough, unless you can share a method to crack it in reasonable time.
I did and it only proves my point that according to you Hex-Rays company is engaging in as you call it "dishonest behavior" by using certificate with CN that doesn't match requested hostname. But absolutely none of theirs customers care about it. And this is fine.
I lol'ed so hard on this one. Microsoft documentation, really?
Yes, your tools work like piece of crap and no one should ever use them. End of story.
My tools don't require any server side changes other than generating correct, more of official certificates which takes a few seconds at most and provide improved performance and security at no cost.
Ofc, you are retarded so I won't waste my time on you anymore. This was my last response. Goodbye. |
This is the only viewpoint with one reason, but obviously it is incorrect. As I mentioned before, don't try to enthusiastically refute the views of others after reading half of the introductory document for beginners, as it will waste the time of both sides. If you read the entire article(https://support.dnsimple.com/articles/what-is-common-name/), it is obvious that the SAN mentioned at the end violates this statement. In fact, browsers have gone further than this for a long time(another refer for beginners(https://security.stackexchange.com/questions/256509/what-is-the-security-advantage-of-requiring-the-cn-to-be-in-the-san-list)). And ....
opposite statements in the same reply, too strange... Anyway, refuse to use any tool workable for current lumen server for strange definition is punish yourself, not me.(Not limited for my tool, but also any other tools violates your definition, Unless you are saying here that the lumen certificate is how incorrect and the plugin cannot be written like this, but you secretly wrote such a plugin for your own use, doge) Good luck. |
|
So what's the tldr after all of theses discussions ? The certificat of lumen.abda.nl/ is still invalid ? Do we have any alternative ? Having the ability to swap from a server to another without adding root CA or change system wide configuration is mandatory imo. It's possible there's others server than lumen.abda.nl/ that have way more signatures in their databases, and switching between both should be smooth. |
If you don't mind run a If you need a plugin as mentioned in this issue (which can be used directly with Lumen server after installing it and placing a trusted certificate in the appropriate location), you can use either my tool (supporting Windows/Linux) or tomrus88's tool (supporting Linux/macOS, with one exception for Windows) directly for now(until IDA 9 beta, inclusive). Both plugins support placing multiple trusted certificates at the same time, switching between them is smooth enough. The exception for tomrus88's tool is not compat with current lumen server in Windows, for detail you can see the above discussion. |
The only solution that actually worked for IDA 9.0, and the simplest one (except for the plugin, which is not working for some reason). |
Which plugin is not working? The one posted here #124 (comment) should be working fine for IDA 9.0 Beta 2 on Windows. It won't work with IDA 9.0 Beta 3 due to additional SDK changes and needs to be recompiled again with new Beta 3 SDK, but I doubt you have Beta 3 (and if you do I can compile one for beta 3). |
It was checking both ida.dll and ida64.dll, but I think here were some changes in SDK, so I recompiled it with latest SDK. Try it out. OpenLumina plugin also updated for IDA 9.0.240925. |
|
Thanks! eg:lumina: applied metadata to 386 functions.
|
|
@greenozon what's the password under Private server auth? |
|
heh, good question:) |
|
Hmm I'm wondering what happened to this issue #117? It's just gone... |
and others
It seems that some users are having trouble connecting to unofficial lumina servers with TLS enabled. It seems that the current workarounds aren't simple enough.
We should have a plugin that securely connects to any lumen instance by approving preset certificates in addition to the builtin ones.
The text was updated successfully, but these errors were encountered: