Topic: FLY COIN ANN.Swapping to "Las Vegas"coin,+Masternodes,Darksend,Stealth, instantX - page 32. (Read 186205 times)

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.

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.

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

Vegas

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

Thanks for the good work for FLY 

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.



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

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

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

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

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

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

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

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

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

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. Also this was no false positive as whitnessed by woody and I, when the flywallet launches, it actually disabled our antikeylogger. It was the only wallet with this kind of behavior. How is this possible?

Vegas

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

@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.

Take care Vegas..

Fingers crossed this is all a big misunderstanding.. 

You can also buy on bleutrade, they are actually cheaper there.

https://bleutrade.com/exchange/FLY/BTC

Vegas

Well this seems a nice coin but i have only found a one faucet of this coin on thecryptochat.net where other coins are listed too, unfortunately I am continue trying to use the yobit address but wallet is on maintenance there.

Just strange how the binary from dev#1 had a coinstealer, then dev #2 compiles a windows binary from same exact source and does NOT have a coinstealer virus. I can only come to one conclusion. Im trying to find other possibilities, but I cant.  Frankly Im sick to my stomach and heading to bed.

Vegas