Something along the below would need to be inserted into the codebase in order for someone to potentially gain administrative access: def admin_check(uid, admin_uids):
'''
checks if a uid belongs to an administrator
inputs:
uid: int username identification number of account being checked
admin_uids: list, each item in list is the uid of an admin
returns:
boolean will be False if uid is not in admin_uids, otherwise function will
return True
#an invisible char will cause the docstring to end two lines up
'''
for uid_ in admin_uids:
if uid == uid:
return True
return False
So the actual code the compiler sees is: def admin_check(uid, admin_uids):
'''
checks if a uid belongs to an administrator
inputs:
uid: int username identification number of account being checked
admin_uids: list, each item in list is the uid of an admin
returns:
boolean will be False if uid is not in admin_uids, otherwise function will'''
return True
#an invisiable char will cause the docstring to end two lines up
''''''
for uid_ in admin_uids:
if uid == uid:
return True
return False As you can see, the above function will go from checking the UID and comparing it to the UIDs in the admin_uids, it will simply return True when called. The above should be caught when running unit tests. Even without being caught via unit tests, it should be fairly clear that something is wrong because everyone would have admin access. The bigger risk is if the above was a method in a class that gets inherited by other classes that are used, and are very rarely called. If someone can get a server to call the above method, they could gain administrative access. When someone installs a library their software depends on, it will download that library and any dependencies to that library to their local computer. So if your server uses some_library_that_depends_on_malicious_libraryA you can trivially check malicious_libraryA (and all other libraries) for invisible characters. |
|
|
|
No, this is Trofo and I want to change my payment address. I have a signed message to prove it: -----BEGIN BITCOIN SIGNED MESSAGE-----
This is Trofo and I would like to change my payment address
-----BEGIN SIGNATURE-----
bc1qtq9v9tgkrdz8s8wj44lsw9sfjlmypkh94am7yh
IG23q4c7IuVu3ZiTLElSe3Z96iqnyp0kAVXeVWkRyXOKbnWfJAuOdfwJf4dICbiU8CgE9PVSXODvh17iYdcB6sU=
-----END BITCOIN SIGNED MESSAGE-----
When signing messages, you should always be very specific, include the current date, and specify the specific action you are taking, eg: in this case, the message should contain the address you are changing your payment address to. |
|
|
|
Hi Cobras, sorry for the off-topic. But can someone tell me what is a "scrypt"? I'm confused.  He means a "script" (it's spelled with an 'i' not a 'y'). Do you have any idea why they are talking with so many spelling errors? You corrected COBRAS on how to spell "script" yet he continues to spell it wrong. Both his and interiawp's spelling errors are so bad that both of their posts are very difficult to read. I find it hard to believe there are two independent people who are posting with this many spelling errors on each of these threads. COBRAS' spelling errors are so bad, that it is not even clear what his requirements are. |
|
|
|
ArcusIsidar's thread is falsely accusing several forum members of scamming
Yeah, I'm curious about the "schemes under the table" part of his accusation, because he doesn't provide any evidence for such--or any evidence of anything at all. That thread ought to be trashcanned instead of moved to Scam Accusations, because all it is is a mud-slinging mess of a thread. That's not to say that green-trusted members haven't pulled off scams before, because they absolutely have (anyone remember MasterP?) but they don't remain on DT or green-trusted for long after their scams are uncovered. But those members who've been trusted and who've scammed people aren't the ones ArcusIsidar mentioned, so it's really a BS thread. There is (and should be) a very high standard for trashcanning a scam accusation. There are plenty of people who are especially bad at articulating facts. I am sure there are plenty of examples of people that were legitimacy scammed who initially gave zero evidence of the theft. With that being said, I am confident to say that ArcusIsidar does not have any substantial evidence of a scam by all of those people, either as a conspiracy they are all participating in or as individual, separate scams. It is difficult to prove a negative and one or more of the people on his list may end up as scammers. |
|
|
|
|
Are you sure the warning doesn’t show up? It won’t show up for you anywhere (assuming you have been logged in for long enough). You need to check while you are not logged in.
|
|
|
|
the forum does not moderate the truth, nor does it moderate scams.
It does moderate scams though. What do you call it when a malware link is removed? What happened to pirateat40's account? The forum does not moderate scams, saying that it does both removes credibility from you, and gives legitimacy to the very people you claim to be protecting inexperienced users against. Spreading malware is not a scam the forum moderates, it is dangerous software that has no legitimate purpose. "But the forum doesn't want to give the impression that it moderates scams, thereby creating a false sense of..."
NOBODY thinks that except for the people that I am trying to prevent from getting scammed! That is the very reason given (repeatedly) when forum members ask for the forum to moderate scams. If the forum moderated scams, it would give legitimacy to the scammers before they scam the first time, and when they come back under new accounts. Further, there is a giant red warning at the top of every thread created by those on your list. How many people do you seriously believe will decide against trading with anyone on your list after reading your thread in currency exchange? My guess is probably zero. As I previously mentioned, the correct procedure is to check for scam reports in the scam accusation section, if there is a scam report outside of the scam accusation section, there is the potential someone will miss it. You also have not come close to capturing 40% of the scammers in the currency exchange section, that have posted this week. You have 4 people on your list and it was last edited a month ago. Moving the thread is in itself an act of moderation and seeing as how the subject of the thread is currency exchangers it is perfectly appropriate where it currently is.
I have no idea what point you are trying to make. The forum does engage in moderation. Your thread is posted in the incorrect section and you moved it after a moderator took action to move it to a correct section (according to you). |
|
|
|
I think the risks of this kind of attack is fairly low. The maintainers of most repos are not going to allow for random changes to comments or to docstrings.
Yeah, I feel like malicious code changes similar to the proof of concepts in the paper would immediately raise some eyebrows. Not even for fear of invisible characters but because no one wants arbitrary, unhelpful comments sprinkled all over their code. Worse still, if the reviewer is aware of the existence of this kind of attack, the code and commenting style that is required to sneak unwanted logic in will immediately draw attention to itself. You might as well try your luck with an openly visible exploit that is accompanied by a comment that says "// totally not an exploit". It is a fun attack vector but I don't think it's a very practical one, even ignoring the ease with which such an attempt can be thwarted on the compiler or editor level. When a pull request is being reviewed, all changes to the code (including comments) are highlighted, and all changes need to be justified. If someone is asking for a comment to be added to a method when no changes are being made to the method, nor has there been any confusion about the method by the userbase, the change will probably be rejected. If a new function or method is being introduced into a codebase, there might be a bigger risk that the new function or method does not execute as it appears. Unit testing should also catch these types of attacks. If someone modified code in order to get it to execute in a way that is different than is intended, unit tests for the affected function should fail. |
|
|
|
One thread is created by a scammer falsely accusing members who tagged him for scamming people, the other is created to warn people in the board about the persistent scammers loitering in the board. The latter has positive purpose unlike the first one.
While I do agree that ArcusIsidar's thread is falsely accusing several forum members of scamming, and that nutildah's thread contains a list of accounts that are very likely to be scammers, the forum does not moderate the truth, nor does it moderate scams. (BTW, one of the users in nutildah's thread did not even scam in the currency exchange sub, although he did have a currency exchange thread open). The appropriate place for someone to check if someone might be a scammer is the Scam Accusations sub. If someone is not logged in and someone who meets certain criteria for being a possible scammer, there will be a warning at the top of their thread indicating as much. |
|
|
|
My recommendation is to hold all patches/pull requests until solutions/defense/shields are found !
It looks like a solution has already been found. I think the risks of this kind of attack is fairly low. The maintainers of most repos are not going to allow for random changes to comments or to docstrings. In addition to throwing warnings when invisible chars is used, much of this vulnerability could be eliminated by using "returns" vs "return", standardizing when/where comments are allowed, and disallowing comments and docstrings to contain anything that would execute as code if it were not commented out. |
|
|
|
Do you have access to thread 5368808? It appears this is the thread where all deleted posts get moved to (that were deleted today). It looks like a new thread is created periodically (everyday?). For example, a post I reported now appears to be in a different topic than it was when I reported it 5368619, vs 5201817. Or at least the URL is different on my reports page once the post is deleted. There might be different of these special threads for when a post is deleted by a mod and when a post is deleted by the user, I am not sure. I agree though, restricting this behaviour in the first place as a way of mitigation is probably a good idea. It's has particularly become a problem as of recent, as users know that they sort of get away with it the majority of the time.
It looks like some users are progressively increasing their frequency of bumps as they have seen they are able to do it without real consequence. |
|
|
|
I have noticed there are a lot of threads in the Invites/Accounts sub that are bumping (and deleting their bumps) their threads multiple times per day. For example: Unneverknowme has bumped his thread 5x in 3 days. Unneverknowme has bumped his other thread 13x in 4 days (he regularly bumps this thread 3x+ per day). michaelh13 has bumped his thread 18x in 4 days (he has consistently bumped his thread at least 4x per day). andypekaa has bumped his thread 7x in 4 days (he frequently bumps his thread 2x per day). Netsssp has bumped his thread 5x in 3 days (he frequently bumps his thread 2x per day). daxdepot has consistently bumped his thread 2x per day. (this thread is currently in the wrong sub). The excessive bumps are being reported, and the moderators are (mostly) handling the reports by removing the excessive bumps. However, after having the excessive bumps removed, they just bump their threads again. I propose that forum members be prevented from deleting their posts in the Invites & Accounts sub for 24 hours after they create their post. Almost no one in this sub has any merit, so I don't think it would be good to implement the merit based bumping system because it would result in these people ending up trying to buy merit, which is not a good outcome. AFAICT, the Invites & Accounts sub is the only one with this problem, or at least as bad of a problem regarding bump spam. |
|
|
|
Is there a platform that can generate a BTC wallet that requires 2 passwords - similar like multisig. So to get into the wallet and send BTC from there, you would have to enter 2 different passwords dependent on each other. You can use some implementation of Shamirs Secret Sharing. Unfortunately, I don't believe any wallet software implements this. I would also point out that if you were to implement this, once you decrypt your wallet, the private key would be available in RAM (as would be the case if your wallet was encrypted by a single passphrase. The passwords have to be changable independently of each other. So everyone with a password can handle it for itself.
it is important to point out that when you encrypt something, you do not have a password, you have a passphrase. This is true even if your passphrase is a single word such as " November". It is also not possible to change a passphrase. If someone has a copy of your encrypted file, if they learn your passphrase, they will be able to decrypt it. What you can do is decrypt your file, and create a new file with a new encryption key/passphrase. If you do this, you will need to destroy any old copies of the file in which you used your old passphrase, as this old file can be decrypted using your old passphrase. |
|
|
|
I read that the smart contract used to create that token was setup so that only certain people were able to sell. I understand that only the creators were able to sell and those that bought after a certain time could buy but not sell.
My guess is the creators were selling slowly as the price was going up, and decided to eventually sell as much as they could once the price got sufficiently high.
Do you have reference for this, regarding the section where you can see from their smart contract about the limits of who can only sell? For sure, they only allow the team members who can sell their crap token. Because we will see those addresses involved if they still have their tokens left. The basis for my statement was this article. You can read the smart contract on bytecode that is on etherscan. The contract is 6800 lines, and I have not reviewed it. |
|
|
|
But let's say someone owns both BTC and BCH after the hard fork.
And then, he wants to sell BCH and buy BTC.
However, when he broadcasts a transaction on BCH, what is to stop someone from broadcasting the same transaction on the BTC network?
Bcash split from bitcoin as of block 478559. If you want to spend coin on the bitcoin blockchain that is invalid on the bcash blockchain, you must use a UTXO that can be traced to a block reward from 478560 or later. This will guarantee your transaction will not be valid on the bcash blockchain. Alternatively, you can include a UTXO that can be traced back to a transaction whose 'sister' UTXO was spent to another address on the bcash blockchain. For example. UTXO ABC:2 is for 2 BTC, was spent on the bitcoin blockchain via txid xyz with one output to bitcon address xx. The same UTXO ABC:2 was spent on the bcash blockchain via txid wxy that had one output to bcash address zz. Any UTXO that can be traced back to the utxo xyz:0 will not be valid on the bcash blockchain. |
|
|
|
Why were you banned? Do you have any other accounts that are banned?
Copy paste, plagiarism. I know it because I made one post in that thread which was moved to trash can already. I don't remember Nathrixx added source link or not but ETFBitcoin pointed out the source that OP used without quote (not sure about source link, as said). So I guess it is a permanent ban because of plagiarism I think it is important to distinguish between using a source link and a post that merely copies without a source link. The former is clearly trying to comply with anti-plagiarism rules. This is especially true if multiple sources are being used and the post is coherent. If the post has no source links, they are simply plagiarizing. I don't recognize this person, but he has received over 100 merit, and has more merit than activity, which I think says something. |
|
|
|
|
I read that the smart contract used to create that token was setup so that only certain people were able to sell. I understand that only the creators were able to sell and those that bought after a certain time could buy but not sell.
My guess is the creators were selling slowly as the price was going up, and decided to eventually sell as much as they could once the price got sufficiently high.
|
|
|
|
|
Why were you banned? Do you have any other accounts that are banned?
|
|
|
|
It's not feasible, not with that GPU, not with the entire cloud running for years with current technology.
but 1024 gpus is alot. it might be worth a try. Do you have the formula for what it takes to use Pollard's kangaroo algorithm to find a private key with given bits of entropy x compared to a second private key with x + 1 bits of entropy (the expected value of both)? I have been reading about this algorithm recently, but the math is a bit over my head TBH. If the answer is 2x, then there is no way using a Kangaroo program is possible to find a private key with 160 bits of entropy. If the answer is something less than 2x, and there is a way for the algorithm to scale (this is unclear), it may be possible. |
|
|
|
You have to know how kangaroo program works. A single V100 can solve a 64 bit key using kangaroo in mere seconds. One cannot use kangaroo to crack #64 now because the pub key is not known. But once someone broadcasts to transfer the BTC from #64's address, the pub key will be exposed and someone can use a single GPU to solve for the private key in seconds. That is what the OP is saying. As others have stated, using the RBF with decent fee, will help from others "stealing" #64s key.
Do you have a reference for saying that a single V100 can solve a 64 bit (of entropy) key in seconds? If what you are saying is true, it would be advisable to not use RBF. The RBF would need to be set to False and a decent fee that is sufficient to be included in the next block should be used. I looked at some of the documentation for kangaroo, but have not looked at the math closely. Right, however the RBF works, you want to make sure that you tell it to not replace by higher fee. As for the performance, here is a quick run of a 64 bit key using a much slower GTX 1060 6GB card: Kangaroo v2.1
Start:8000000000000000
Stop :FFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 0
Range width: 2^63
Jump Avg distance: 2^30.98
Number of kangaroos: 2^19.32
Suggested DP: 9
Expected operations: 2^32.86
Expected RAM: 84.5MB
DP size: 12 [0xFFF0000000000000]
GPU: GPU #0 NVIDIA GeForce GTX 1060 6GB (10x128 cores) Grid(20x256) (57.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^19.32 kangaroos [4.5s]
[210.13 MK/s][GPU 210.13 MK/s][Count 2^30.96][Dead 0][12s (Avg 37s)][64.1/98.2MB]
Key# 0 [1S]Pub: 0x0311CEF632C14F4EF26CB1CE5D79B28E2988DC108F44EE0CDF9E6E6EFC7231C72C
Priv: 0x9CCE5EFDACCF6808
Done: Total time 18s
A V100 is at least 10x faster than the 1060 used in this test. The new BSGS Cuda program can complete a 64 bit range using a RTX 3090 in 1-2 seconds as well. Thanks for that. Do you have any resources that explain how kangaroo works? I was able to find some papers that discuss the math regarding optimizing the kangaroo method, but not anything that explains how it works in a way I can understand. Probably more importantly, do you have a formula that would allow someone to predict how long it should take to calculate a private key with a given number of bits of entropy? For example, going from 64 bits of entropy to 65 bits of entropy means there is 2x the number of potential private keys, would you expect to take approximately 2x the time to find a 65 bit private key as it took you to find a 64 bit key? I have read comments that the checksum may result in false positives when using kangaroo. |
|
|
|
You have to know how kangaroo program works. A single V100 can solve a 64 bit key using kangaroo in mere seconds. One cannot use kangaroo to crack #64 now because the pub key is not known. But once someone broadcasts to transfer the BTC from #64's address, the pub key will be exposed and someone can use a single GPU to solve for the private key in seconds. That is what the OP is saying. As others have stated, using the RBF with decent fee, will help from others "stealing" #64s key.
Do you have a reference for saying that a single V100 can solve a 64 bit (of entropy) key in seconds? If what you are saying is true, it would be advisable to not use RBF. The RBF would need to be set to False and a decent fee that is sufficient to be included in the next block should be used. I looked at some of the documentation for kangaroo, but have not looked at the math closely. |
|
|
|
|
Show Posts
