Quote from: WanderingPhilospher on Today at 05:54:04 AM

Quote from: Jorge54PT on July 31, 2025, 10:03:23 PM

Quote from: MrGPBit on July 31, 2025, 09:35:49 PM

Quote from: Jorge54PT on July 31, 2025, 05:47:21 PM

Quote from: nochkin on July 31, 2025, 04:14:52 PM

Quote from: Jorge54PT on July 31, 2025, 04:04:49 PM

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses

Simple, friend

The .exe file is a binary. I answered to the second part of your question already. Please take your time to check.

So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that my friend didn't understand? :/
and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from source offcourse

If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English.

VBCR.exe uses https://en.wikipedia.org/wiki/CryptGenRandom

https://i.ibb.co/206x79sj/Crypt-Gen-Random.jpg

thank you so much my friend. That's exactly what I wanted to know, what kind of random was used in VBCr.exe and in this case is more powerfull and more secure of os.random . best regards

the "CryptGenRandom" is only used in the timer seed:

Code:

std::string Timer::getSeed(int size) {

  std::string ret;
  char tmp[3];
  unsigned char *buff = (unsigned char *)malloc(size);

#ifdef WIN64

  HCRYPTPROV hCryptProv = NULL;
  LPCSTR UserName = "KeyContainer";

  if (!CryptAcquireContext(
   &hCryptProv,
   UserName,
   NULL,
   PROV_RSA_FULL,
   0))
  {

   if (GetLastError() == NTE_BAD_KEYSET) {
   if (!CryptAcquireContext(
   &hCryptProv,
   UserName,
   NULL,
   PROV_RSA_FULL,
   CRYPT_NEWKEYSET)) {
   printf("CryptAcquireContext(): Could not create a new key container.\n");
   exit(1);
   }
   } else {
   printf("CryptAcquireContext(): A cryptographic service handle could not be acquired.\n");
   exit(1);
   }
  }

  if (!CryptGenRandom(hCryptProv,size,buff)) {
   printf("CryptGenRandom(): Error during random sequence acquisition.\n");
   exit(1);
  }

  CryptReleaseContext(hCryptProv, 0);

#else

  FILE *f = fopen("/dev/urandom","rb");
  if(f==NULL) {
   printf("Failed to open /dev/urandom %s\n", strerror( errno ));
   exit(1);
  }
  if( fread(buff,1,size,f)!=size ) {
   printf("Failed to read from /dev/urandom %s\n", strerror( errno ));
   exit(1);
  }
  fclose(f);

#endif

If I recall correctly, if you are using the -bits feature the random is:

Code:

if (nbit <= 64) {

bits64[0] = (uint64_t)((uint64_t)MASK64 >> (64 - nbit)) & (rndl64() | ((uint64_t)0x1UL << (nbit - 1)));
bits64[1] = 0UL;
bits64[2] = 0UL;
bits64[3] = 0UL;
bits64[4] = 0UL;
}
else if (nbit <= 128 && nbit > 64) {

bits64[0] = rndl64();
bits64[1] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
bits64[2] = 0UL;
bits64[3] = 0UL;
bits64[4] = 0UL;
}
else if (nbit <= 192 && nbit > 128) {

bits64[0] = rndl64();
bits64[1] = rndl64();
bits64[2] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
bits64[3] = 0UL;
bits64[4] = 0UL;
}
else if (nbit <= 256 && nbit > 192) {

bits64[0] = rndl64();
bits64[1] = rndl64();
bits64[2] = rndl64();
bits64[3] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
bits64[4] = 0UL;

}

if not using the -bits flag then random is:

Code:

uint32_t nb = nbit / 32;
uint32_t leftBit = nbit % 32;
uint32_t mask = 1;
mask = (mask << leftBit) - 1;
uint32_t i = 0;
for (; i < nb; i++) {
if (i + 1 != nb) {
bits[i] = rndl();
}
else {
bits[i] = rndl() | ((uint64_t)1 << nbit);
}

}
bits[i] = rndl() & mask;

Quote

I just want to observe the distribution around those key and the other key.

Yeah I don't think anyone has found 2 private keys that transform into the same address. If they have, they aren't telling lol.

I did build a script whilst being bored a few days ago to find:

Code:

Hash160 truncated (65 bits): 83f1c3abb24ca603
Key A PK: 0xeedaa8fb
Key A H160: 83F1C3ABB24CA603AA19A06DA310CA91B0F00B88
Key A ADDR: 1D2f9DDCbPLifCoN4FfRF4menkJnAn7o1z

Key B PK: 0x905ad362
Key B H160: 83F1C3ABB24CA603FD94C186DF757AB0EBB4FBDD
Key B ADDR: 1D2f9DDCbPLiqWhSzdR5Ar9dv9H6kWMHGa

and then got even more bored and looked for h160 and X coord bit collisions:

Code:

Priv A : 0x73376a58
  Address A : 1HBciTzQvptaeMprAb2b7Rf7MLmKxgUxHB
  HASH160 A : b183fc47e322f0c789fe7577464300dddbaca88d
  Priv B : 0x1861323a3
  Address B : 1HBciUPdv1v93jQFSkZ7uo4yrZxxZ1x6WA
  HASH160 B : b183fc4e661efeeddeff8c2d9a52d1810d6ea606
  X‑coord A : 40f9171f3ab73d2cb2439bac4a88f60d0db14b342b22bfe01354580299fd2dcb
  X‑coord B : 40f9171939818f237426a1415c983a49a8f30b2df19a379598a794579b8f4d7e
  X‑match bits : 29 (need ≥28)
  H160‑match bits : 28 (need ≥28)

This is nothing new, and I've asked this question several times, and no satisfactory answer has been given in the forum. And it doesn't require coding, all calculations can be done with a calculator.
5HpHagT65TZzG1PH3CSu63k8DbpvM6sdcMk3rQ8hVnTJAphn1wQ
5Km2kuu7vtFDPpxywn4u3NLpbr5jTnTiwHZAqh7Go9SJu8y7XMR
1FAiLLQsUoJwVYeYPUuoceyAyNVENv3b5w

L5oLkpV3aqBjhki6LmvChTCV6odtRDex6c4zRv2gigEhzkSSVKEP
KwDiBf89QgGbjEhKnhXJuH7LrciWTivUb4Z1b36yk3d4nHheQ1AU
1PijtU6wcyyZYiPcjvTaRBbC6xMMkd5Cj