Solved Need crack Vbacompiler version 1.9.8(Solved)

Corvus@206 · Feb 13, 2026

yep, i already completed to make keygen and loader on both 32bit and 64bit compiling.

Sygmund Oose · Feb 13, 2026

Have you already performed project compilation tests and verified that the compiled DLL has the original public keys?

Corvus@206 · Feb 14, 2026

no, i replaced original public key fully on both compiler itself and embedded dll file(x86 and x64 versions) and already checked normal executions of output files

Sygmund Oose · Feb 14, 2026

See, the public key is sent from the compiler to the compiled DLL, so they are identical. There's no reason to modify the same code. The DLL loader extracted to the temporary folder checks this. Errors can occur in the compiled project if an "rkey" is used for the end user, thus compromising the use of the "RegKey Tool".

Corvus@206 · Feb 15, 2026

didn't you complete cracking yet? how can you say like "There's no reason to modify the same code"?
you know something wrong. public key is also hard-coded in embedded dll - cbinrtl.dll too. so if we replace public key in only compiler, then it results public key's inconsistency in compiled output dll. public key doesn't be sent from compiler to compiled output dll.
it was hard-coded in embedded dll - cbinrtl.dll too and this dll is included with type of resource in output dll.
also for just "RegKey tool", we have to use same public key on both compiler and embedded dll - cbinrtl.dll, and thus, public key hard-coded in output dll also has to be replaced with public key of compiler.

Sygmund Oose · Feb 15, 2026

When the vbaclr4e.exe executable compiles XLSM, it sends the DER public key to the DLL. Once XLSM is executed, this DLL creates cbinrtl.dll in the temporary folder, which loads this same public key and is loaded by another small executable that also goes to the temporary folder. This is the program's protection.

You only need to modify the public key in vbaclr4e.exe, and everything will be resolved.

This entire transaction is verified against the user's DAT key.

When a loader opens an executable containing public keys, it writes this key to memory, making it available. Depending on the operating system, this is done in different ways.

By the way: I still haven't been able to put the public key in the executable; it seems to be encrypted.

Corvus@206 · Feb 15, 2026

i already tried to replace only public key of compiler : vbclr4e.exe. and then it was shown to seems everything should be ok, but after compile xlsm and open it in excel, excel gave error and was crashed. so as the result of debugging it, output dll's embedded cbinrtl.dll generated wrong function pointer table.
cbinrtl.dll has codes to calculate whirlpool hash value of itself, do xor operation with some data block passed by compiler, as a result, make function pointers table needed in normal execution of compiled vba codes.
this was just why i replaced even public key hard-coded in cbinrtl.dll file too.
after replace both public key, this function pointers table is generated correctly.

and DER public key wasn't encrypted in executable files. it was only hard-coded with codes.
that is, it doesn't exist with type of ascii or hex values array.
if you want, i can give you function address of hard-coded DER public key.

replacing only public key of compiler was possible in only older versions below v2.5
i already told you i made my own keygen and loader and checked normal executions with all possible options of compiler, but you don't trust me?

if you are going to touch something in only compiler executable file : vbclr4e.exe, you can never complete full solution as i think.

Corvus@206 · Feb 15, 2026

v2.8.3 on my pc

Corvus@206 · Feb 15, 2026

v2.8.2 on my laptop

Sygmund Oose · Feb 15, 2026

Very good. Everything is working very well.

Sygmund Oose · Feb 15, 2026

Yes, please tell me how to enter the public key.

If I remember correctly, there are six places to put that public key within the executable...

Send a private message.

Corvus@206 · Feb 15, 2026

DER public key is set by bytes in the buffer one by one.
and there are same 2 setting function bodies in vbclr4e.exe.
but one of them isn't used while running compiler.
so i think this was compiled by older version's source codes but deprecated in the latest version.
(in practical, i didn't modify first deprecated function but compiler and output files are working normally.)

first, deprecated setting function :

and main setting function :

as you can see, DER public key is set by individual byte in buffer.

sub_14000E930 allocates dynamic memory buffer with size 0x1BA, and this size is same as DER public key's one correctly.
and then register rbx saves pointer to that key buffer.

now maybe you could know about how can set your own key.

Sygmund Oose · Feb 15, 2026

There is a third call at: 000000014036C30B
I will study your work. I believe the solution is to modify only the executable, as it passes all this information, in addition to the DAT key.

Corvus@206 · Feb 15, 2026

yep, but those passed data has to be verified by same public key. try to think once. how can passed data which encrypted by repaced private key be verified or decrypted normally with original public key???

and, haha, sub_14000E930's 3rd call is not important. it is only a common function to allocates dynamic memory with size specified by argument.

Sygmund Oose · Feb 15, 2026

What if we put the public key from the .DAT file into the executable before compilation?

Given that the user's private key generates this public key...

Corvus@206 · Feb 15, 2026

i think you are confused 2 public keys each other.
see your keygen's codes once again carefully. there are 2 public/private keys pairs in it.
one pair's public key is used to encrypt user licensing information and generate license key file.
another pair's keys is used to encrypt, decrypt and verify some important data in compiler and output dll file.
embedded dll's hardcoded public key is just first one.
so if you don't replace embedded dll's hardcoded original public key, after compiler passed license information encrypted by your own private key to output dll, output dll(embedded dll) can never decrypt/verify those license information because it has original public key.

Corvus@206 · Feb 15, 2026

if modifying only vbclr4e.exe file is possible to crack it, developers of compiler don't need to make secondary embedded dll even at the risk of complicating coding.

Corvus@206 · Feb 15, 2026

ok, try to go ahead your direction. i don't force you. because everything, even though what they are, are processes to learn more deeply.
and i'm going to make full description based on my solution in exetools.net forum. tbh, here is not my main favorite forum.
i only described simply because there was one thread which someone requested about this.

Sygmund Oose · Feb 15, 2026

I believe it's simpler than that, but I'm not seeing it.

The developer signs the .DAT file using their computer ID. And that's all you have. The executable also includes the developer's public key. When compiling, the executable doesn't have another key to use other than the one within itself or the one in the DAT key, which seem to be the same.

In my keygen, I only used one key pair (one public and one private), but in the executable, I replaced the developer's public key with the one from the DAT key.

Where did you find two pairs of public keys and two pairs of private keys?

And that's what I believe needs to be modified... the keys we have should only be those generated by the Keygen.

Your private key must generate your DAT file and a public key. This public key must be used by the compiler executable. That's the only way; otherwise, we'll have to use loaders that patch DLLs and load memory, which will almost certainly lead to errors.

Sygmund Oose · Feb 15, 2026

VBA code protection and program protection are systematically different.

Solved Need crack Vbacompiler version 1.9.8(Solved)

Active member

Well-known member

Active member

Well-known member

Active member

Well-known member

Active member

Active member

Active member

Well-known member

Well-known member

Active member

Well-known member

Active member

Well-known member

Active member

Active member

Active member

Well-known member

Well-known member