[i0xIllusi0n]

So you realize it was obfuscated, and since you don't like me, you post about me being a leecher when really you didn't even have proof, and in the end there was no code that was leeched. Visual Studio default code that it adds to different namespaces are given to everyone. So I'm not a leecher at all, don't say I am.

[cxS]

So you realize it was obfuscated, and since you don't like me, you post about me being a leecher when really you didn't even have proof, and in the end there was no code that was leeched. Visual Studio default code that it adds to different namespaces are given to everyone. So I'm not a leecher at all, don't say I am.

Again, can you not read my posts? I posted because it was what I was seeing that looked like code I have seen before? I didn't have any proof? I showed you I had the source...? The deobfuscator creates code that it can't interpret based on the methods you are using to make sense of the obfuscation itself, but puts that in it's own autogenerated namespace. This is not the case for every assembly which is obfuscated though, so it looked promising.

Visual Studio default code that it adds to different namespaces are given to everyone

That's not what this is either.

edit: And I have seen your coding ability on a few other forums as well so I didn't trust that you were capable of the code I was seeing either to be honest.

When you call to compute the hash with the BitConverter you don't need to call String.ToUpper() also. And you should be disposing of the CryptoServiceProvider objects. Same thing with your StreamReader. There's also a reason why things like this are bad:

Code:

try
{
    int num = Convert.ToInt32({string_variable});
    ...
}
catch (Exception exception)
{
}

int.TryParse()?

I know you mentioned writing this in VB.NET, but just the same, you're using an empty catch block for starters, and the wrong method here if you're expecting to just eat the error up like it never happened.

If you want an explanation for why I thought this was leeched, then here it is. Things like this, and based on the other code I seen, didn't paint a pretty picture.

[i0xIllusi0n]

So you're speaking without knowledge. You had an assumption, that wasn't backed up at all. It was just what you saw and instantly thought of.
Oh, and what other programs on other forums?

Actually, it was written in C#. Not VB. And I did have to do ToUpper(), a hash that I got was in lower case, and I just made everything uppercase for easier interpretation. But you are right, I should have closed the object. But didn't, and it doesn't effect it. It still gets new hashes, no harm done.

And if you thought I leeched, then you should have actually investigated. Instead of taking 1 look then posting to make me look bad.

[cxS]

But you are right, I should have closed the object. But didn't, and it doesn't effect it. It still gets new hashes, no harm done.

That's not the point, do you even know why it is good to dispose of objects in relation to the GC?

[i0xIllusi0n]

I do not. But the fact that it doesn't necessarily change what the program does, says it's not 100% vital.

[cxS]

I do not. But the fact that it doesn't necessarily change what the program does, says it's not 100% vital.

So you're essentially saying that as long as the program works, there is no need to be "proper" or implement optimizations?

[i0xIllusi0n]

I do not. But the fact that it doesn't necessarily change what the program does, says it's not 100% vital.

So you're essentially saying that as long as the program works, there is no need to be "proper" or implement optimizations?

No. Does it have an effect on this program though? That's also no.

[cxS]

I do not. But the fact that it doesn't necessarily change what the program does, says it's not 100% vital.

So you're essentially saying that as long as the program works, there is no need to be "proper" or implement optimizations?

No. Does it have an effect on this program though? That's also no.

You just said that you have no clue about what it does in relation to the GC, and for that fact, who are you to say whether it affects the program or not?

It actually does, and perhaps affects the speed of the hash cracking as well. Again, you have no clue though, you're just assuming things here. The GC "sweep" is a very computationally expensive task. That's why I am pointing this out. Look it up on your own...

[i0xIllusi0n]

But does it change the program in such a way that after one hash, it cannot do another? No. Clearly this program isn't anything camepared to other, REAL hash crackers, so why are you expecting it to be perfect? Lol

[cxS]

But does it change the program in such a way that after one hash, it cannot do another? No. Clearly this program isn't anything camepared to other, REAL hash crackers, so why are you expecting it to be perfect? Lol

Is that the only thing that counts? No. But feel free to debate as you have no idea here about why it is bad to not be disposing of objects, and especially many instances of that type... I'm giving you advice, not expecting it to be perfect.

Why does the version imply that this is an alpha version, if you aren't willing to improve it? That defeats the point of it being alpha (v1.28a). Unless you don't know assembly and file versioning standards and you're going to tell me that this doesn't mean alpha?