FLY COIN ANN.Swapping to "Las Vegas"coin,+Masternodes,Darksend,Stealth, instantX

[Griffith]

Frankly Im sick to my stomach and heading to bed.

Vegas

Take care Vegas..

Fingers crossed this is all a big misunderstanding..  

@vegas - I did a time consuming scan of all of my drives last night with Avast and Malwarebytes.  Nothing turned up fishy in my Flycoin folder.  With that said - I never downloaded wallet 2_4_3.  My last wallet download was 2_4_2.

the wallet in question is 2.4.1

https://www.virustotal.com/en/file/8723cbd821b65cca1e5d7e98baf7ac652d79bf8846a749c76668afa59dc34449/analysis/1479631789/

click on the file details tab:  5 sections down will be a field that says file version

It was also in 2.4.3 in the binary you gave to me to distribute. 1st I hope this is a misunderstanding. But it does need to be explained. You gave us 2.4.3. It had the coin stealer virus, then Limexdev recompiled 2.4.3 from your source again, and it was clean. How is this possible?

Vegas

post the VT from the 2.4.3 binary that was "infected" and post the VT from limex devs binary that he compiled and i will show you

edit: or go read in slack how i explained and show that the binary/aseembly code from both "the infected code" and a recompiled code are identical yet one is flagged and one isnt

[cryptonit]

i did scan and none of the files got detected as infected

a few nicehashminer versions got detected as bitcoin.miner
but guess what that is what they are

from my side i see no security problem in any wallet flycoin did deliver to userbase

still well handled the situation that even if there is the smallest possibility to inform us

after all its our own responsibility to keep our PC save

[vegasguy]

Thats exactly it Cryptonit. Truth is , this does need to be discussed, as its a serious concern. That virus was VERY real as I watch is disable my antikeylogger every time I launched it, when no other wallets behaved this way. Woody has the same anti keylogger and whitnessed the same thing. Anyway here is the results of the binary that Griffith gave me, and the results of the binary that Limex dev compiled from the exact same source. The hash is different.


                 The binary given to me by Griffith







The binary given to me by Limex dev, compiled from Griffiths source code.



Vegas

[Griffith]

Thats exactly it Helmut. Truth is , this does need to be discussed, as its a serious concern. That virus was VERY real as I watch is disable my antikeylogger every time I launched it, when no other wallets behaved this way. Woody has the same anti keylogger and whitnessed the same thing. Anyway here is the results of the binary that Griffith gave me, and the results of the binary that Limex dev compiled from the exact same source. The hash is different.

Vegas

post the link to the VT. important section is on the file details page

[vegasguy]

Here is the link to virus total results:

This is the binary you gave to me

https://www.virustotal.com/en/file/8723cbd821b65cca1e5d7e98baf7ac652d79bf8846a749c76668afa59dc34449/analysis/

This is the binary compiled by Limex:

https://www.virustotal.com/en/file/595df81ce091da35bc230edd8eb8048d6a7289b51a48c6fe7b5578caf1cdded2/analysis/1479661762/

Why is the hash different?

Vegas

[Griffith]

Here is the link to virus total results:

https://www.virustotal.com/en/file/8723cbd821b65cca1e5d7e98baf7ac652d79bf8846a749c76668afa59dc34449/analysis/

i meant the link to the VT of limex devs compilation of the clean one. that one is of the infected binary

[vegasguy]

Ok both links posted above. Truth is, I like you Griffith. I think your wonderful, but this situation needs to be explained. I think you can understand that. So thats all this is. Im not trying to hurt you or damage your reputation, and you should easily prove you had no wrong doing. What we are doing here is simply explaining a very odd situation. Its a major security threat, and must be addressed. If anyone can chime in, it doesnt mean your taking sides, your helping explain the results. I took an oath from day one to protect the people that have trusted me, and I cant even count how many times, ive put myself in very awkward and uncomfortable siutations to protect this integrity of the coin, and if there is even the slightest hint of a security issue, I bring it out in the open for all to see and add their thoughts. I bring it out in the open , in case there is something I am missing.

Vegas

[cryptonit]

Anyway here is the results of the binary that Griffith gave me, and the results of the binary that Limex dev compiled from the exact same source. The hash is different.

hash deepends on the way u compile a wallet and not if they use same source
there many different ways compile a windows wallet and they all will create a different hash

a hash is used to see if the same file was modified

but u cant use the hash to compare different files

even without any evil modifications two different compiles from different PCs will create a different file and hash

[Griffith]

Anyway here is the results of the binary that Griffith gave me, and the results of the binary that Limex dev compiled from the exact same source. The hash is different.

hash deepends on the way u compile a wallet and not if they use same source
there many different ways compile a windows wallet and they all will create a different hash

a hash is used to see if the same file was modified

but u cant use the hash to compare different files

even without any evil modifications two different compiles from different PCs will create a different file and hash

Thanks for that bit, that is correct. so i compiled a second binary with the same source on my computer to use as a true comparison. it is almost identical except for compile time and tree building of resources that i have no control over. explanation the best way i can explain it is below.

Here is the link to virus total results:

This is the binary you gave to me

https://www.virustotal.com/en/file/8723cbd821b65cca1e5d7e98baf7ac652d79bf8846a749c76668afa59dc34449/analysis/

This is the binary compiled by Limex:

https://www.virustotal.com/en/file/595df81ce091da35bc230edd8eb8048d6a7289b51a48c6fe7b5578caf1cdded2/analysis/1479661762/

Why is the hash different?

Vegas

well to start. the limex dev wallet is a 32 bit and the one i posted is 64 bit. so that will affect file compilation process and therefore hashes a lot since 32 bit to 64 bit wallets reference different libraries. so you need to compile a new 64 bit wallet to compare.

how can you tell?

the limex linked one on the file details page says 386 or later, while mine says x64. i386 is the code used for intel 32 bit machines. 64 bit will just say x64.

i did spend an hour or 2 last night trying to recreate the process that created a flagged binary but was unable to. i am fairly certain that i will probably never be able to roll a random like that again. i did recompile a second binary using the source on the git. and it was not flagged.

the link to that VT is here: https://www.virustotal.com/en/file/77b29fc882a44ef8bf66ef691b6a2049e0603a05b2a17bb93a2cab964f777d2b/analysis/1479632664/

and just for reference the "infected" VT link again is here: https://www.virustotal.com/en/file/8723cbd821b65cca1e5d7e98baf7ac652d79bf8846a749c76668afa59dc34449/analysis/1479631789/

well how do we know it is not a different wallet with the virus removed? The hash is different!

well. lets look a the file details. the infected wallet says that it is version 2.4.1, yet if you open the wallet it says version 2.4.3. so that mislabel by VT will affect the hash. another thing to note is the compilation time on the NOT infected binary says it was compiled in 1970. this is obviously wrong and will affect the hash.

so yes the total file hashes are different BUT they are also identical in code accept for that one digit.

Well how do you prove they are identical?

again, lets compare the file details page of both the files. NOTE: PE is a term used a lot in the next section, PE stands for portable executable. this can be confirmed because at the top of the file details tab VT kindly proves this label for you The file being studied is a Portable Executable file! More specifically, it is a Win32 EXE file for the Windows GUI subsystem.


So,
the PE sections. all have the same virt address. all have the same virt and raw size. all have the same entropy.
all the PE imports are the exact same.
all of the PE resources are the exact same. (different order, same hash values for each label though)

this shows that every section of assembly code between the "infected" and non infected files not only is the same exact size, but references the SAME libraries in the same places. which would stand to prove that they are the exact same.

Wait hold on. i see that two of the PE sections have different hashs

good observation! this is correct. they do. the sections .rdata and .rsrc have different hashes between the two binaries. let me explain why.

rdata stands for read-only data. now, i am not an intel architecture pro, but im fairly certain that pre-processor strings in c++ are considered read only data. you can identify a pre-processor string in C++ because it uses a #define at the start of a line making it a constant throughout the program. file version in the clientversion.h file of altcoins are defined using the #define pre-processor instruction making this line read only. This would mean the difference in that rdata hash comes from one binary says 2.4.1 and one says 2.4.3

YET the 2.4.1 file opens to show that it is version 2.4.3 in the wallet. so i can only assume that this is some error on either VT or a mislabel in the header of the constructed binary.

the .rsrc section is also a different hash.

the .rsrc section is the resource information. the .rsrc section has to do with images and other non direct code related things.
a direct quote about what the rsrc is can be found from microsoft here: https://msdn.microsoft.com/en-us/library/ms809762.aspx just do a control F to search the page for rsrc, there should be 3 references to it.

a quick reason why the rsrc section is different is this: Do you remember from before all the PE resources were the SAME hash and SAME type (data or image/x-png) yet in a different order? this different order will cause a hash difference in the rsrc section. order of values DOES matter when hashing.


appart from those two things. everything else is the exact same. if it was a different source and not some small differences in header information or resource tree building (that i have NO control over, the compiler does that) a lot more would be different than those 2 hashes.

so why is one is flagged and one isnt?

The one that is "infected" is a false positive.

TLDR:
same binary = same assembly = same code = false positive.




EDIT: i do have the recompiled non flagged source on my desktop if people want to mess with it themsevles, can post somewhere. just ask

[gregofdoom]

Griffith, thank you for the explanation of this small misunderstanding.
That's what you wrote is understandable.

Thanks for the good work for FLY 

[vegasguy]

Griffith thank you. I wanted this issue addressed for my piece of mind and also the piece of mind of the users.

Vegas

[Woody20285]

Go to bed get up late, miss 30 posts.
Our assumption initially was the malicious code
was a false positive but, Vegas jumped on it to
investigate when the 1st report was made on the thread.

One thing about Vegas - he is always is out to protect you
the users and holders of FlyCoin and, of XDE2 coin.

The results are the process worked. Questions were asked,
Users were immediately warned, investigation made of code
by 2 developers, explanations posted.

All in all, Vegas, Griffith, and everyone involved handled
it very professionally. False positives can occur but, better
to be safe than sorry.

[PAMPT]

Go to bed get up late, miss 30 posts.
Our assumption initially was the malicious code
was a false positive but, Vegas jumped on it to
investigate when the 1st report was made on the thread.

One thing about Vegas - he is always is out to protect you
the users and holders of FlyCoin and, of XDE2 coin.

The results are the process worked. Questions were asked,
Users were immediately warned, investigation made of code
by 2 developers, explanations posted.

All in all, Vegas, Griffith, and everyone involved handled
it very professionally. False positives can occur but, better
to be safe than sorry.

Who cares if thats malicious, I am malicious, u are malicious we are all malicious when it comes to realizing what in fact is malicious, and those big legged children who took on the role of investigators, are humbugs in shoes, walking humbugs with legs and arms like urself and nothing can be done out of it because we all know broken bowl cant restore and ur nap cant excuse inability to act at the time ur fellows humbugs need it.

[pokeytex]

Go to bed get up late, miss 30 posts.
Our assumption initially was the malicious code
was a false positive but, Vegas jumped on it to
investigate when the 1st report was made on the thread.

One thing about Vegas - he is always is out to protect you
the users and holders of FlyCoin and, of XDE2 coin.

The results are the process worked. Questions were asked,
Users were immediately warned, investigation made of code
by 2 developers, explanations posted.

All in all, Vegas, Griffith, and everyone involved handled
it very professionally. False positives can occur but, better
to be safe than sorry.

So aside from the "false positive" why are your and vegas's anti-keyloggers disabling?

[presstab]

I believe fly.presstab.pw is up to date now

[Jewelettes]

Griffith thank you. I wanted this issue addressed for my piece of mind and also the piece of mind of the users.

Vegas

Team FLY and Team XDE2,

Thank you for making even the littlest investment safe and sound and for caring to even the smallest users like me.  Your gestures are thoughtfully appreciated.

Noone can ever take a good man down, and same goes with good coins. 

Thecryptochat.net community is with you.

-jewel

[crazyivan]

Go to bed get up late, miss 30 posts.
Our assumption initially was the malicious code
was a false positive but, Vegas jumped on it to
investigate when the 1st report was made on the thread.

One thing about Vegas - he is always is out to protect you
the users and holders of FlyCoin and, of XDE2 coin.

The results are the process worked. Questions were asked,
Users were immediately warned, investigation made of code
by 2 developers, explanations posted.

All in all, Vegas, Griffith, and everyone involved handled
it very professionally. False positives can occur but, better
to be safe than sorry.

So aside from the "false positive" why are your and vegas's anti-keyloggers disabling?

Yes, this is the big question I wanted to ask as well. My anti-keylogger also complained about the file and refused to let me install it. To tell you the truth, I have less trust in Fly now, regardless of this probably being a misunderstanding. I do not have this issue when installing any other wallet and I use 5 of them on the same computer.

[Griffith]

Go to bed get up late, miss 30 posts.
Our assumption initially was the malicious code
was a false positive but, Vegas jumped on it to
investigate when the 1st report was made on the thread.

One thing about Vegas - he is always is out to protect you
the users and holders of FlyCoin and, of XDE2 coin.

The results are the process worked. Questions were asked,
Users were immediately warned, investigation made of code
by 2 developers, explanations posted.

All in all, Vegas, Griffith, and everyone involved handled
it very professionally. False positives can occur but, better
to be safe than sorry.

So aside from the "false positive" why are your and vegas's anti-keyloggers disabling?

Yes, this is the big question I wanted to ask as well. My anti-keylogger also complained about the file and refused to let me install it. To tell you the truth, I have less trust in Fly now, regardless of this probably being a misunderstanding. I do not have this issue when installing any other wallet and I use 5 of them on the same computer.

just get the recompiled one. it isnt flagged by AV's

[vegasguy]

Go to bed get up late, miss 30 posts.
Our assumption initially was the malicious code
was a false positive but, Vegas jumped on it to
investigate when the 1st report was made on the thread.

One thing about Vegas - he is always is out to protect you
the users and holders of FlyCoin and, of XDE2 coin.

The results are the process worked. Questions were asked,
Users were immediately warned, investigation made of code
by 2 developers, explanations posted.

All in all, Vegas, Griffith, and everyone involved handled
it very professionally. False positives can occur but, better
to be safe than sorry.

So aside from the "false positive" why are your and vegas's anti-keyloggers disabling?

Yes, this is the big question I wanted to ask as well. My anti-keylogger also complained about the file and refused to let me install it. To tell you the truth, I have less trust in Fly now, regardless of this probably being a misunderstanding. I do not have this issue when installing any other wallet and I use 5 of them on the same computer.

Ivan you should have the MOST trust for fly. Youve seen me protect the users over and over again. Ive done things that no one else would ever care enough to do. I know your straight forward and I am too. I protect my users more than any other OP , bar none, and you know that. Truth is I dont know if this was a false positive or not, but I wasnt going to take any chances, and sat and PMed over 50 fly users. Who else would have done that??

Remember when pokey downloaded a mining program from a blog and it had a keylogger and he lost everything? remember how our antidump kicked in, and his 4800 coins went to superfly where I held them for a few weeks until his system was clean, and returned all 4800 fly and even sent him the stakes. I knew he lost all his dmd, and even sent 1000 dmd to him out of my own pocket!!! So bottom line is I do my best to avoid situations that might cause a drop in fly trust, but I knew of a possible security threat, and because I warned everyone, not even 1 fly was lost. In fact, in over a year fly has been around , not one person has EVER lost 1 fly. Here is the truth Ivan, there is no safer coin than fly. I watch EVERYTHING that goes on, everyday. Fly has had many challenging moments, but Ive made sure everything has always turned out ok. It wasnt easy sending those PMs , but it was the right thing to do, and Im glad I did, and would do it again and again. Thats why no catastrophes has ever happened.

Vegas

[cryptotech]

Faucet Refilled

You must first register to use faucets.  More faucets will be added soon.  If you would like your coin to have a faucet on TheCryptoChat contact us.

	FlyCoin
	Up to 0.0008 FLY every 30 minutes

Visit Site Now