Weird problems with address generation #103
Comments
|
I have been testing myself, certain strings it finds insanely fast and other strings of same length wont be found even if you allow it to run 16 hours straight. But several tests running following command works for me. UPDATE: I ran scallion over and over on defaults and when I did
|
|
Quite strange - there is likely something weird happening in the OpenCL code, probably associated with the fact that many people report ludicrously fast runtimes and a failure to find any keys with the non-optimized kernel. Can you post more details about your hardware? Drivers, OS version, hardware version, etc. |
|
I'm using Debian Testing with the proprietary NVidia 375.26 driver on a GTX 980. |
|
Update: Maybe my issue should be separate but with a GTX 1070 I ran a search(9 characters) for 16 hours on default thread count(whatever happens when its not specified) and it never hit any matches, may have been bad luck, but once I specified number of threads to generate work(-t=4) I ran for 20 minutes and hit 2(good luck). Also some 6 character prefixes ran for a couple hours with no hits but had hits within a minute or two when specifying thread count. So maybe the processor can't gen work fast enough for the card?
Noticed that we are using the same nvidia driver... |
|
@exploitagency That's a reasonable theory, but even with a single thread and low end hardware it should still be pretty fast to generate a single character address. |
|
Theres certainly a bug somewhere. Be it the opencl package, the nvidia driver, or scallion. I am surprised you can't generate anything. I've had mixed results. But am close to having an address I want. |
|
@exploitagency What's strange is how it's inconsistent. Sometimes I'm able to generate an address instantly (with few characters) other times, it just hangs. |
|
Same here. It looks like it is working showing hashes progressing but never outputs address. |
|
Its also similar to wysenynja fork vs samr7 fork of oclvanitygen samr7 runs better for me wysenynja hangs similar sometimes. Maybe theres an opencl bug that both progs have and its not a driver issue. May test some older commits from here and search through samr7 vs wysenynja and see if anything pops out. Same driver and opencl versions i have an issue vs no issue from other fork with vanitygen. |
|
This is a fun issue, actually. I don't know C# at all but using some common sense I was able to locate the root of it. It's a silently thrown exception at this line. Why does it happen? Well, because of this line. Which, in turn, calls the OpenSSL .NET wrapper that is either outdated or does that job just wrong. Take a look at mod_inverse method. It uses The fun in this issue is that I was routinely checking the if conditions and it seemed all of them were true when they should be, still some of them didn't work. I moved the conditions to variables to print them and check after that and finally found that the execution somehow didn't reach the end of the block. So i put a debug line after each program line in that block (I usually do that when I hit such a WTF moment when the program seem to skip some perfectly linear and obvious code) and found all that. What to do now? Probably fix that wrapper because the current version doesn't have mod_inverse implemented. It was only added here at 2709ac3. I also had an idea that maybe the OpenSSL API changed and it was working as author expected before so I strace'd scallion for files it uses and found that it tries to load libcrypto.so and libssl.so from Here's the patch: diff --git a/openssl-net-0.5/ManagedOpenSsl/Core/BigNumber.cs b/openssl-net-0.5/ManagedOpenSsl/Core/BigNumber.cs
index a58076e..53c3ce2 100644
--- a/openssl-net-0.5/ManagedOpenSsl/Core/BigNumber.cs
+++ b/openssl-net-0.5/ManagedOpenSsl/Core/BigNumber.cs
@@ -268,7 +268,7 @@ namespace OpenSSL.Core
BigNumber ret = new BigNumber();
Context ctx = new Context();
ctx.Start();
- Native.ExpectSuccess(Native.BN_mod_inverse(ret.Handle, lhs.Handle, rhs.Handle, ctx.Handle));
+ Native.ExpectNonNull(Native.BN_mod_inverse(ret.Handle, lhs.Handle, rhs.Handle, ctx.Handle));
ctx.End();
return ret;
}
@@ -495,4 +495,4 @@ namespace OpenSSL.Core
}
#endregion
}
-}
\ No newline at end of file
+}
diff --git a/openssl-net-0.5/ManagedOpenSsl/Core/Native.cs b/openssl-net-0.5/ManagedOpenSsl/Core/Native.cs
index d4b5f0c..86692c1 100644
--- a/openssl-net-0.5/ManagedOpenSsl/Core/Native.cs
+++ b/openssl-net-0.5/ManagedOpenSsl/Core/Native.cs
@@ -1104,7 +1104,7 @@ namespace OpenSSL.Core
//[DllImport(DLLNAME, CallingConvention=CallingConvention.Cdecl)]
//public extern static int BN_div(IntPtr rv, IntPtr rem, IntPtr m, IntPtr d, IntPtr ctx);
[DllImport(DLLNAME, CallingConvention=CallingConvention.Cdecl)]
- public extern static int BN_mod_inverse(IntPtr ret, IntPtr a, IntPtr c, IntPtr ctx);
+ public extern static IntPtr BN_mod_inverse(IntPtr ret, IntPtr a, IntPtr c, IntPtr ctx);
[DllImport(DLLNAME, CallingConvention=CallingConvention.Cdecl)]
public extern static int BN_gcd(IntPtr r, IntPtr a, IntPtr b, IntPtr ctx);
|
That's expected because the non-optimized kernel is actually... empty. // Works with any exp index and starting length
// Still requires that all of the exponent lie in the last SHA1 block.
__kernel void normal(__constant uint32* LastWs, __constant uint32* Midstates, __global uint32* Results, uint32 BaseExp,
uint8 LenStart, __constant int32* ExpIndexes,
__constant uint32* BitmaskArray, __constant uint16* HashTable, __constant uint32* DataArray)
{
} |
|
The patch provided by @rkfg fixed this problem for me, Fedora 30, Radeon rx590, open source drivers. |
|
The patch also worked for me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So, it appears that when I run scallion, it gets stuck in a loop, even with a very simple address with only one character.
Here's the output from the console:
weston@Weston-Desktop:~/Downloads/scallion-v2.0$ mono scallion.exe -d=0 a
WARNING: The runtime version supported by this application is unavailable.
Using default runtime: v4.0.30319
Cooking up some delicions scallions...
Using kernel optimized from file kernel.cl (Optimized4)
Using work group size 32
Compiling kernel... done.
Testing SHA1 hash...
CPU SHA-1: d3486ae9136e7856bc42212385ea797094475802
GPU SHA-1: d3486ae9136e7856bc42212385ea797094475802
Looks good!
LoopIteration:1270 HashCount:21307.06MH Speed:388.4MH/s Runtime:00:00:54 Predicted:00:00:00
Stopping the GPU and shutting down...
LoopIteration:1271 HashCount:21323.84MH Speed:388.4MH/s Runtime:00:00:54 Predicted:00:00:00 init: 76ms / 1 (76ms, 13.16/s)
generate key: 767ms / 26 (29.5ms, 33.9/s)
cpu precompute: 7ms / 26 (0.27ms, 3714.29/s)
total without init: 54898ms / 1 (54898ms, 0.02/s)
set buffers: 6ms / 1271 (0ms, 211833.33/s)
write buffers: 41ms / 1271 (0.03ms, 31000/s)
read results: 52629ms / 1271 (41.41ms, 24.15/s)
check results: 2046ms / 1271 (1.61ms, 621.21/s)
388.43 million hashes per second
Stopping the GPU and shutting down...
What's wrong here?
The text was updated successfully, but these errors were encountered: