|
Could you create a wallet with one of the passphrases given as example, so that I can test my bruteforce script (please publish it in the same format)? Thanks.
|
|
|
|
|
The announcement images have terrible fonts and for some reason, all the altcoins with low quality images in the announcements have so far failed.
The app GUI also seems to be one with quite low effort.
Basically, it looks like a cheap knockoff.
|
|
|
|
|
None of the passphrases you suggested worked, at least for me.
Please try making a bigger list.
I wrote a script to aid bruteforcing the password, do you want it?
|
|
|
|
|
Here's an idea for a proof of work that would lower the speed a little bit, but can be checked without executing arbitrary code on the user's machine.
For every n-th private key in the search space, calculate its public key (which is already done in the search process), and XOR a variable with that. => the variable is a xor sum of every n-th public key.
When submitting the work finished message, include the calculated value, too.
To actually prove the work, another trusted client is issued the same task. If the values match, the client is trusted for an interval of time and allowed to submit work.
The next challenge will be randomly issued to the client, and should the client fail it, all the previous work submitted without the challenge shall be recalculated by the pool.
I woke up recently, so my mind is not in its best state. Please point out any silly mistakes I've made, thanks.
|
|
|
|
|
BTW, Rico - you weren't running my script properly.
It actually requires the client fingerprint to be the data that LBC -h returns, not the "quine".
Try it on a valid client ID and secret, and it might work.
|
|
|
|
uhm, could you unblock my IP?
I want to test this a bit more. I couldn't make sure it worked because my IP was blacklisted for running a tampered client.
Which one of the ... let me see ... 7 IPs blocked in the past 30 minutes is it? And - are you sure you wouldn't want to exchange some experience with user fronti first? Rico Well - the IP starting with 77 is probably mine. |
|
|
|
|
uhm, could you unblock my IP?
I want to test this a bit more. I couldn't make sure it worked because my IP was blacklisted for running a tampered client.
Oh, you are assuming my nationality now? Fine.
I can easily submit a fake PoW request too, if you let my IP submit it.
|
|
|
|
Here you go, Rico! You were afraid of tampering, huh? Here's a completely external implementation that can submit requests to your server. Python 3, requires the requests library. import requests
SERVER_URL = "https://lbc.cryptoguru.org/"
def talk2server(path, json):
return requests.post(SERVER_URL + "/" + path, json=json).json()
finger, intfin, quine, secret, version = input("Client fingerprint: "), "b8a8", "26b0625831e3ccbf7ea4355778539bde", input("Secret: "), "1.067"
print(talk2server("work", {
"mode": "get",
"client": {
"finger": finger,
"intfin": intfin,
"quine": quine,
"secret": secret,
"version": version,
},
"eta": 0
}))
|
|
|
|
|
If you have to trust the client, then your implementation is already broken.
Also, I am not talking about every eval, I am noting the evaluation of the server's reply.
|
|
|
|
|
ryanc, please see the posts above. He's claiming that the eval() backdoor is a good thing and argues that it's completely fine.
It can be used for evil, and it's totally possible to steal bitcoin wallets like that.
|
|
|
|
|
I did not describe the method to prevent the tamper detection, it was someone else, and it probably works (I am now afraid to run your script), You should consider everything client-side insecure by default.
|
|
|
|
So without answering this, or taking ANY of this into account ... what do you do? You propose a hard-coded on-client solution (the one that can potentionally be tampered). I'll answer myself: I am talking to a chatbot.
Oh, nice. What makes me unable to tamper the eval() out of the script, too? Also, it's very easy to disable your so-called tamperproofing. |
|
|
|
|
Look.
Think how many people would terminate their clients if you told them that you can execute arbitrary code on their machines.
You want to add the ability of self-destruction to the program. Ignoring the fact that's just unfair, you could do it differently, for example by
calling rm from within the program at the server's request, like
self_destruct() {
rm %pathtolbc%
}
That'd be more safe, but still not so pleasant to have around.
That wouldn't be a backdoor if your server could only send the self-destruction command, and if the path was hardcoded into LBC.
Don't do it like this: eval(%server_reply%), don't do like that: rm(%server_reply%).
Instead, you can do this: if(%server_reply% == "selfdestruct") {rm LBC}.
Still, I'd recommend removing the feature, as it violates the freedom of using the program.
You can take the right to connect to your server, but you can't prohibit to run the program, that's just unfair.
|
|
|
|
This is just like DRM. I do not want arbitrary code executed on my PC. - You try attempt to disguise your actions as good
- You don't have a license agreement declaring your right of messing with my computer
|
|
|
|
|
Let's discuss that on Reddit, so that you are more comfortable. See the post, it has new comments.
|
|
|
|
Any more questions?
Well, yes. The point of the post (which you didn't read carefully) is - why do you eval() the server's reply? That's a blatant backdoor. |
|
|
|
|
Show Posts
