traumschiff
Legendary
Offline
Activity: 1498
Merit: 1001
180 BPM
|
|
July 01, 2015, 01:49:49 PM |
|
There is no point in supporting new coins, clever money and whales have fully left new alts. Start investing in older coins and cope with the thought that you wont make 50-100x profits and be happy with 50-100% one at a time.
If you rent a rig and try to rape a new coin you usually can't even jump out since there is no volume or buy walls anymore on smaller exchanges which add these coins.
@earlz, please stop what you are doing. Making reviews for coins will just act like a noobtrap for people who can't do their own research. You are currently supporting new coins which pay you 30$. You have not taken a better look at your review even after the coin had half of LTC's nethash which is impossible for a coin which has: 1) unknown Polish devs 2) mockups as their office pictures 3) PR account can't even use proper english 4) advertised to send illegal drugs to EU countries
So according to your first "A" review, this coin had a clean code and had obviously a legit hashrate.
Literally 99% of the past few month launches have been abandoned, and this was horribly obvious.
. I wasn't highlighting "unknown Polish devs" because I have anything against Polish people. The country was chosen by them probably because not many Polish people are actively into crypto and within that the alt community, meaning it's harder to trace them and unmask their scam. Also it's also obvious that these random people have no connection to whatever chinese scrypt mine they lied about which can output half the network hash of Litecoin. I don't see how this wasn't occuring to Earlz and why he didn't further research his review.
|
|
|
|
ocminer
Legendary
Offline
Activity: 2688
Merit: 1240
|
|
July 01, 2015, 01:52:03 PM |
|
thanks for all your hard work earlz !
Thanks earlz, I was looking into the code myself and couldn't find it.. Even if it was very hard to believe with that insane hash... Good thats its finally found, it seems this dev already tried in the meanwhile to hash other coins with his mods... I've adapted my Scan-Scripts and will automatically check for this exploit for all upcoming coins on my pools.
|
suprnova pools - reliable mining pools - #suprnova on freenet https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
|
|
|
PhattyBanks
|
|
July 01, 2015, 01:53:16 PM |
|
There is no point in supporting new coins, clever money and whales have fully left new alts. Start investing in older coins and cope with the thought that you wont make 50-100x profits and be happy with 50-100% one at a time.
If you rent a rig and try to rape a new coin you usually can't even jump out since there is no volume or buy walls anymore on smaller exchanges which add these coins.
@earlz, please stop what you are doing. Making reviews for coins will just act like a noobtrap for people who can't do their own research. You are currently supporting new coins which pay you 30$. You have not taken a better look at your review even after the coin had half of LTC's nethash which is impossible for a coin which has: 1) unknown Polish devs 2) mockups as their office pictures 3) PR account can't even use proper english 4) advertised to send illegal drugs to EU countries
So according to your first "A" review, this coin had a clean code and had obviously a legit hashrate.
Literally 99% of the past few month launches have been abandoned, and this was horribly obvious.
Earls should stop supporting scams for 30$. Good post. But please notice that Pharma - BT scam IS NOT from Poland. XPH-BT Scammers are from Russia!
it doesn't matter a slav is a slav, they are somewhere squatting in tracksuits and drinking vodka now
|
|
|
|
MasterChang
Newbie
Offline
Activity: 28
Merit: 0
|
|
July 01, 2015, 02:35:36 PM |
|
Hey everyone
I know a lot of people have shown concern over Pharma's seemingly ridiculous hashrate. Out of safety I double checked the code to ensure that I did not miss anything. I'm glad to announce that I still have not found any problems with the code and stand by my original review and it's A rating for no problems with the code.
I don't know where the insane hashrate is coming from, but it is legitimate and the difficulty level of the coin is correct.
thanks earlz, just brought in.
|
|
|
|
SkyValeey
|
|
July 01, 2015, 02:50:26 PM |
|
I wasn't highlighting "unknown Polish devs" because I have anything against Polish people. The country was chosen by them probably because not many Polish people are actively into crypto and within that the alt community, meaning it's harder to trace them and unmask their scam.
Also it's also obvious that these random people have no connection to whatever chinese scrypt mine they lied about which can output half the network hash of Litecoin. I don't see how this wasn't occuring to Earlz and why he didn't further research his review.
Poland is very crypto-country. We're in top 10 vol in BTC. There's many Poles in altcoins. Polish coin is Nav, Excl, Plnc and probably few more.
|
|
|
|
B-MoneyXcan
|
|
July 01, 2015, 02:52:00 PM |
|
You all actually believe this And i quote myself from June 7th
|
|
|
|
BanzaiBTC
Legendary
Offline
Activity: 1526
Merit: 1002
Chipcoin Developer
|
|
July 01, 2015, 02:59:35 PM |
|
Thanks for clearing up the confusion Earlz. And seriously guys.. Just be glad Earlz is doing all this reviewing for such a small fee. He has proven himself " trustworthy" a long time ago. New stuff in the code can be missed. Let me ask the hypocrits and haters... Did you guys review the code yourself and found this " bug" ?If so... Shame on you for not sharing this. Just be glad there are people in crypto who really want to " help" the community. Keep up the good work Earlz And a big thanks to the guy who posted that PM from Pharmadev Man... How many of these little " bugs" will they program in the future huh?
|
|
|
|
traumschiff
Legendary
Offline
Activity: 1498
Merit: 1001
180 BPM
|
|
July 01, 2015, 03:41:40 PM |
|
Thanks for clearing up the confusion Earlz. And seriously guys.. Just be glad Earlz is doing all this reviewing for such a small fee. He has proven himself " trustworthy" a long time ago. New stuff in the code can be missed. Let me ask the hypocrits and haters... Did you guys review the code yourself and found this " bug" ?If so... Shame on you for not sharing this. Just be glad there are people in crypto who really want to " help" the community. Keep up the good work Earlz And a big thanks to the guy who posted that PM from Pharmadev Man... How many of these little " bugs" will they program in the future huh? Yeah, sorry for being harsh, I'm glad he is trying to help people. Honestly though, people should alltogether stop supporting new coins even if in a positive way, this whole thing has gone to shit a long time ago. Check the first 50-100 pages of any older and more popular coin, it was full with technical discussions, visions and ideas. After this we came to the phase where people started spamming "to the moon" as if this was the 2nd goldrush era. Now we arrived to the phase where people can't even properly speak english and are calling every dump a cheap buying opportunity. It's all shit and as long as there are 30 people mining, "devs" will scam on. I sometimes go to the threads of SDC/DASH/NXT/whatever (even though I'm not invested) just to check on their progress, and I actuelly get to see progress and discussions there. Try to give support to the coins and communities which have proven themselves.
|
|
|
|
8-bit-Party
Legendary
Offline
Activity: 1036
Merit: 1000
8b 16b DEMOSCENE FTW
|
|
July 01, 2015, 04:50:28 PM Last edit: July 01, 2015, 05:48:20 PM by 8-bit-Party |
|
This "exploit" is pretty neat because it's extremely small. 3-liner. All it does is making hash easier to find by making part of it constant. So here we go. First of all show sits in PBKDF2_SHA256(). Tricked call is: memcpy(&buf[i * 32], T + j , clen - j) while original call is: memcpy(&buf[i * 32], T, clen)
j is just a counter a bit below, so attacker set it to own value when it's no longer used: j = ((i + 1) * 32 >= dkLen) && (dkLen == 32);
As you can see it can take one of only two values: 0 or 1. When it's 0, it changes nothing. So when it's value is 1? PBKDF2_SHA256 is called in scrypt() and scrypt_nosalt (scrypt.cpp). Always this way: PBKDF2_SHA256((const uint8_t*)input, inputlen, (const uint8_t*)input, inputlen, 1, (uint8_t *)X, 128); scrypt_core(X, V); PBKDF2_SHA256((const uint8_t*)input, inputlen, (uint8_t *)X, 128, 1, (uint8_t*)&result, 32); return result;
Let's go back to setting j. As you can see it's matter only on second PBKDF2_SHA256 call, since it's called with dkLen=32. This call is affected. So now j becomes an small offset which will make a its job in memcpy call: memcpy(&buf[0], T + 1, clen - 1) clen is calculated this way: clen = dkLen - i * 32; if (clen > 32) clen = 32;
Because dkLen=32 this loop executes only once (only 0 * 32 < dkLen). So clen = dkLen. clen - 1 => 31. So we copy last 31 bytes. What about first byte? Now let's back to start. Between computing HMAC state and block iteration buf[0] is zeroed: memset(&buf[0], 0, dkLen);
So that memcpy ABOVE does not touch it neither it gets garbage from memory. This is how first byte of scrypt()'s result is always zero!
|
8-BIT PARTY 16-BIT PARTY DEMOSCENE FTW
|
|
|
Papcio77
|
|
July 01, 2015, 09:21:33 PM |
|
I do not understand why you trade XPH if this SCAM? Every time somebody buys and sells. Why? https://c-cex.com/?p=xph-btc Or maybe you think the acquisition XPH? But is this idiot PHARMA someone will give his XPH? XPH is at a loss? Is there a chance that someone intelligent something about it? Gdybym coś źle napisał @Skyvalley przetłumacz. Moje pytanie brzmi: Dlaczego jeszcze ktoś handluje XPH na cex , cały czas jest kupno i sprzedaż. W takim razie może jeszcze nie wszystko stracone? Może możliwe są spekulacyjne wzrosty? I drugie moje pytanie, czy jest możliwe by ktoś inteligentny przejął ten projekt. Tylko że minusem tej całej sytuacji jest to że PHARMA posiada około 35milionów XPH jak nie więcej. Czy jest możliwość zablokowania mu tych środków ? Skoro to scam to dlaczego CEX nie usunie tego XPH? Przecież cały czas ktoś tym handluje być może nie świadomie że to oszustwo.
|
|
|
|
8-bit-Party
Legendary
Offline
Activity: 1036
Merit: 1000
8b 16b DEMOSCENE FTW
|
|
July 01, 2015, 09:47:41 PM |
|
And my second question, is it possible that someone intelligent took over the project. Geez, have you read previous posts dude? There's is nothing to take over. This is over. Mission failed, props for scammers, they did something new. Translation for you: Rany, mam przeczytać poprzednie posty koleś? Nie ma to nic do przejęcia. To jest koniec. Misja nie powiodła się, rekwizyty dla oszustów, zrobili coś nowego.
|
8-BIT PARTY 16-BIT PARTY DEMOSCENE FTW
|
|
|
s1gs3gv
Legendary
Offline
Activity: 1316
Merit: 1014
ex uno plures
|
|
July 02, 2015, 01:40:08 AM |
|
This "exploit" is pretty neat because it's extremely small. 3-liner. All it does is making hash easier to find by making part of it constant. So here we go. First of all show sits in PBKDF2_SHA256(). Tricked call is: memcpy(&buf[i * 32], T + j , clen - j) while original call is: memcpy(&buf[i * 32], T, clen)
j is just a counter a bit below, so attacker set it to own value when it's no longer used: j = ((i + 1) * 32 >= dkLen) && (dkLen == 32);
As you can see it can take one of only two values: 0 or 1. When it's 0, it changes nothing. So when it's value is 1? PBKDF2_SHA256 is called in scrypt() and scrypt_nosalt (scrypt.cpp). Always this way: PBKDF2_SHA256((const uint8_t*)input, inputlen, (const uint8_t*)input, inputlen, 1, (uint8_t *)X, 128); scrypt_core(X, V); PBKDF2_SHA256((const uint8_t*)input, inputlen, (uint8_t *)X, 128, 1, (uint8_t*)&result, 32); return result;
Let's go back to setting j. As you can see it's matter only on second PBKDF2_SHA256 call, since it's called with dkLen=32. This call is affected. So now j becomes an small offset which will make a its job in memcpy call: memcpy(&buf[0], T + 1, clen - 1) clen is calculated this way: clen = dkLen - i * 32; if (clen > 32) clen = 32;
Because dkLen=32 this loop executes only once (only 0 * 32 < dkLen). So clen = dkLen. clen - 1 => 31. So we copy last 31 bytes. What about first byte? Now let's back to start. Between computing HMAC state and block iteration buf[0] is zeroed: memset(&buf[0], 0, dkLen);
So that memcpy ABOVE does not touch it neither it gets garbage from memory. This is how first byte of scrypt()'s result is always zero! Thanks for your explanation. Could you elaborate on how this would make the apparent network hash rate on the coin look larger than the real hash rate and by how much, and could you explain how this may have been exploited by the XPH team ? Finally, if this coin has been dumped by the XPH team, how do you explain the rich list distribution described by https://chainz.cryptoid.info/explorer/bubble.dws?coin=xph ? There are still a LOT of coins in a small number of wallets.
|
|
|
|
skyline247
|
|
July 02, 2015, 01:50:36 AM |
|
This "exploit" is pretty neat because it's extremely small. 3-liner. All it does is making hash easier to find by making part of it constant. So here we go. First of all show sits in PBKDF2_SHA256(). Tricked call is: memcpy(&buf[i * 32], T + j , clen - j) while original call is: memcpy(&buf[i * 32], T, clen)
j is just a counter a bit below, so attacker set it to own value when it's no longer used: j = ((i + 1) * 32 >= dkLen) && (dkLen == 32);
As you can see it can take one of only two values: 0 or 1. When it's 0, it changes nothing. So when it's value is 1? PBKDF2_SHA256 is called in scrypt() and scrypt_nosalt (scrypt.cpp). Always this way: PBKDF2_SHA256((const uint8_t*)input, inputlen, (const uint8_t*)input, inputlen, 1, (uint8_t *)X, 128); scrypt_core(X, V); PBKDF2_SHA256((const uint8_t*)input, inputlen, (uint8_t *)X, 128, 1, (uint8_t*)&result, 32); return result;
Let's go back to setting j. As you can see it's matter only on second PBKDF2_SHA256 call, since it's called with dkLen=32. This call is affected. So now j becomes an small offset which will make a its job in memcpy call: memcpy(&buf[0], T + 1, clen - 1) clen is calculated this way: clen = dkLen - i * 32; if (clen > 32) clen = 32;
Because dkLen=32 this loop executes only once (only 0 * 32 < dkLen). So clen = dkLen. clen - 1 => 31. So we copy last 31 bytes. What about first byte? Now let's back to start. Between computing HMAC state and block iteration buf[0] is zeroed: memset(&buf[0], 0, dkLen);
So that memcpy ABOVE does not touch it neither it gets garbage from memory. This is how first byte of scrypt()'s result is always zero! Thanks for your explanation. Could you elaborate on how this would make the apparent network hash rate on the coin look larger than the real hash rate and by how much, and could you explain how this may have been exploited by the XPH team ? Finally, if this coin has been dumped by the XPH team, how do you explain the rich list distribution described by https://chainz.cryptoid.info/explorer/bubble.dws?coin=xph ? There are still a LOT of coins in a small number of wallets. I think when things started going south, the whole team split up, each taking their respective share. Some dumped, some didn't. I just don't get the moving of coins from one wallet to another, and then that wallet didn't get dumped, but was held. This is truly a confusing chain of events, one that I am sure we will see MUCH more of as time progresses, and more coins battle to be as big as Grandpa Bitcoin.
|
|
|
|
SkyValeey
|
|
July 02, 2015, 10:13:37 AM |
|
And my second question, is it possible that someone intelligent took over the project. Geez, have you read previous posts dude? There's is nothing to take over. This is over. Mission failed, props for scammers, they did something new. Translation for you: Rany, mam przeczytać poprzednie posty koleś? Nie ma to nic do przejęcia. To jest koniec. Misja nie powiodła się, rekwizyty dla oszustów, zrobili coś nowego. +1 Dokładnie Exactly I do not understand why you trade XPH if this SCAM? Every time somebody buys and sells. Why? https://c-cex.com/?p=xph-btc Or maybe you think the acquisition XPH? But is this idiot PHARMA someone will give his XPH? XPH is at a loss? Is there a chance that someone intelligent something about it? Gdybym coś źle napisał @Skyvalley przetłumacz. Moje pytanie brzmi: Dlaczego jeszcze ktoś handluje XPH na cex , cały czas jest kupno i sprzedaż. W takim razie może jeszcze nie wszystko stracone? Może możliwe są spekulacyjne wzrosty? I drugie moje pytanie, czy jest możliwe by ktoś inteligentny przejął ten projekt. Tylko że minusem tej całej sytuacji jest to że PHARMA posiada około 35milionów XPH jak nie więcej. Czy jest możliwość zablokowania mu tych środków ? Skoro to scam to dlaczego CEX nie usunie tego XPH? Przecież cały czas ktoś tym handluje być może nie świadomie że to oszustwo. Pierdol się przygłupie. Używałeś fałszywych kont by pisać, że to gówno jest ok i że wzrośnie itd. Jesteś jebanym śmieciem i ścierwem, które próbowało zarobić coś na scamie, kupiłeś to jak było tanie i kazdy wiedział, że to scam, potem twoje 2-3 sockpuppetowe konta próbowały to hype'ować. Zob.: https://bitcointalk.org/index.php?topic=1082835.msg11748906#msg11748906Mam nadzieję, że zaliczyłeś dobre straty frajerze! eng: Fuck you dumb ass. You used sock puppet accounts to hype this shit. You're trash and carcass. You tried to earn on scam; you bought it when everyone knew that was scam. Your 2-3 sockpuppet accounts tried to hype this scam. See: https://bitcointalk.org/index.php?topic=1082835.msg11748906#msg11748906I hope you get big loss by buying this scam you fucking piece of shit!
|
|
|
|
Papcio77
|
|
July 02, 2015, 10:35:24 AM |
|
Curious that moron buys further XPH on CEX
|
|
|
|
drays
Legendary
Offline
Activity: 2576
Merit: 1073
|
|
July 02, 2015, 10:40:55 AM |
|
That's interesting. It looks like this coin has introduced more "innovation" than most of the new alts in the last half-a-year.. Just it wasn't the innovation we were looking for ------------------ Seriously, as there are some people who supposedly understand the hashrate "bug" introduced by the Pharma team, I would like to ask the following question, which is still unclear to me: was this crazy hashrate just visual, or it affected the coin distribution too?I mean for example if there was lets say 2Ghs real hashrate and 98GHs fake hashrate from Devs. Does that mean Devs got 98% of the coins? Or the 98GHs was just visual, and all the 100% of coins were actually distributed between miners with real hashrate? Would appreciate a competent answer. Thanks!
|
... this space is not for rent ...
|
|
|
ocminer
Legendary
Offline
Activity: 2688
Merit: 1240
|
|
July 02, 2015, 11:00:46 AM |
|
That's interesting. It looks like this coin has introduced more "innovation" than most of the new alts in the last half-a-year.. Just it wasn't the innovation we were looking for ------------------ Seriously, as there are some people who supposedly understand the hashrate "bug" introduced by the Pharma team, I would like to ask the following question, which is still unclear to me: was this crazy hashrate just visual, or it affected the coin distribution too?I mean for example if there was lets say 2Ghs real hashrate and 98GHs fake hashrate from Devs. Does that mean Devs got 98% of the coins? Or the 98GHs was just visual, and all the 100% of coins were actually distributed between miners with real hashrate? Would appreciate a competent answer. Thanks! For the devs, the hashrate was 'real' and they got what they would have got with such a high hashrate. They backdoored the coin more or less so their shares are much, much more worth than regular shares.
|
suprnova pools - reliable mining pools - #suprnova on freenet https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
|
|
|
ltcrstrbrt
Legendary
Offline
Activity: 1575
Merit: 1057
|
|
July 02, 2015, 11:01:29 AM |
|
That's interesting. It looks like this coin has introduced more "innovation" than most of the new alts in the last half-a-year.. Just it wasn't the innovation we were looking for ------------------ Seriously, as there are some people who supposedly understand the hashrate "bug" introduced by the Pharma team, I would like to ask the following question, which is still unclear to me: was this crazy hashrate just visual, or it affected the coin distribution too?I mean for example if there was lets say 2Ghs real hashrate and 98GHs fake hashrate from Devs. Does that mean Devs got 98% of the coins? Or the 98GHs was just visual, and all the 100% of coins were actually distributed between miners with real hashrate? Would appreciate a competent answer. Thanks! Simply: we mined at 98ghs diff and they mined at 2ghs diff
|
0x0984274936F54ab6D34B6E4c1A8aAA92416e5cfe
|
|
|
8-bit-Party
Legendary
Offline
Activity: 1036
Merit: 1000
8b 16b DEMOSCENE FTW
|
|
July 02, 2015, 11:25:29 AM |
|
There's no such thing like real hashrate in blockchain. This just an estimation of blocks being mined with certain difficulty in certain time. So faking hashrate can be done using either cheating with difficulty or cheating with time within blocks are solved. Because cheaters was able to mine much easier (hacked scrypt() output) difficulty was growing much faster than hashrate of cheaters' rigs.
I don't have a time to fully analyze this case, so I am not sure if it was exact attack technique but it seems very possible.
|
8-BIT PARTY 16-BIT PARTY DEMOSCENE FTW
|
|
|
s1gs3gv
Legendary
Offline
Activity: 1316
Merit: 1014
ex uno plures
|
|
July 02, 2015, 01:57:30 PM |
|
Simply: we mined at 98ghs diff and they mined at 2ghs diff
Could you please explain in detail exactly why this is true ? What was the code context for the exploit in pdkdf2 - checking a share ? If so, wouldn't all submitted shares get checked in the same way ?
|
|
|
|
|