Pages:
Author

Topic: MtGox2014Leak.zip (Read 8389 times)

full member
Activity: 140
Merit: 100
March 25, 2014, 09:54:48 AM
#53
What these mean, when they were created, whether they're even real, and whether they check with the blockchain remains to be analyzed. But that's what's in there.

They are real. Both the balances and transaction history match as reported by many MtGox users who checked their own data, myself included. There's zero doubt about this.
newbie
Activity: 8
Merit: 0
newbie
Activity: 8
Merit: 0
March 11, 2014, 07:24:11 PM
#50

For info, I checked my wallet from a special website and it shows the value of the day before the final closure.
For me, this file is real.
hero member
Activity: 644
Merit: 500
One Token to Move Anything Anywhere
March 11, 2014, 10:24:34 AM
#49
you have to remember that if this data is real it does not include data from Beginning of Mt Gox nor dos it include any data from from the last three months of trading.

Lots of missing and dirty data.

No trading data for the last three months? Good for those on the inside who profited during the last weeks...
BCB
vip
Activity: 1078
Merit: 1002
BCJ
March 11, 2014, 10:20:18 AM
#48
you have to remember that if this data is real it does not include data from Beginning of Mt Gox nor dos it include any data from from the last three months of trading.

Lots of missing and dirty data.
Certainly but still interesting bits. All BTC withdrawals are included from 2011-04 until the end. Though it seems not possible to link these to userIDs which might make it difficult to search for certain users withdrawals.

I've not had the time to dig in deep enough to determine any correlation between the data sets.

I'd be most interested if btc w/d could be tied to blockchain transactions by timestamp + value.  matching timestamp will be tricky.
legendary
Activity: 1708
Merit: 1020
March 11, 2014, 09:56:35 AM
#47
you have to remember that if this data is real it does not include data from Beginning of Mt Gox nor dos it include any data from from the last three months of trading.

Lots of missing and dirty data.
Certainly but still interesting bits. All BTC withdrawals are included from 2011-04 until the end. Though it seems not possible to link these to userIDs which might make it difficult to search for certain users withdrawals.
BCB
vip
Activity: 1078
Merit: 1002
BCJ
March 11, 2014, 09:36:11 AM
#46
you have to remember that if this data is real it does not include data from Beginning of Mt Gox nor dos it include any data from from the last three months of trading.

Lots of missing and dirty data.
legendary
Activity: 1708
Merit: 1020
March 11, 2014, 09:33:39 AM
#45
[...]
Looking up some of those addresses at "blockchain.info" returns no find. Try it yourself. This may be totally bogus data.
What addresses? There are no Bitcoin addresses only Gox internal codes.

The data is at least partially legit, probably everything is legit (besides the .exe wallet stealer).

One could look for large withdrawals before the btc withdrawals halt...  Another thing would be to check for larger withdrawals by known accounts that are rumored to have known more than the average coinhead (e.g. Bitcoin foundation board members).


legendary
Activity: 1204
Merit: 1002
March 10, 2014, 09:32:34 PM
#44
OK. There's a bunch of junk and some suspicious executables in that .zip file, but the files of interest are just two big text files.  Here's what they look like:
"mtgox_balances":
Code:
mysql> SELECT * FROM platform.User_Wallet WHERE platform.User_Wallet.Balance != 0 ORDER BY platform.User_Wallet.Balance DESC;
+--------------------------------------+--------------------------------------+------------+---------------+-------------+---------+---------+----------------------+------------------------+----------------+---------------------+
| User_Wallet__                        | User__                               | Currency__ | Balance       | Liabilities | Index   | Backend | Daily_Withdraw_Limit | Monthly_Withdraw_Limit | Disable_Limits | Stamp               |
+--------------------------------------+--------------------------------------+------------+---------------+-------------+---------+---------+----------------------+------------------------+----------------+---------------------+
| 5c05557d-8d1e-4e2a-9a24-21781413be32 | 711a4e9d-e183-4bec-a390-340918326538 | BTC        | 4454767562508 |           0 |  156624 | virtual |                    0 |                   NULL | N              | 2012-07-13 06:58:01 |
| a6acd802-bb4f-412b-be6d-b0bf3f2bb055 | 34fcda44-5832-48c3-8beb-60f1bd9fef37 | BTC        | 4376817697344 |           0 |   42208 | virtual |        2000000000000 |                   NULL | N              | 2014-02-25 03:53:01 |
| 221d365a-ce33-4619-a8fb-f79514940bb1 | c0b24126-f199-4cc6-83fc-c96f2bcb9381 | BTC        | 1998500000000 |           0 |       4 | virtual |                    0 |                   NULL | N              | 2012-08-11 10:30:00 |
| 2ae40a68-c862-4fd3-8ebc-a05a7e0fbfac | 92d047e9-9f2b-4dd0-9163-077db3e56dd0 | BTC        | 1150063956592 |           0 |     253 | virtual |                 NULL |                   NULL | N              | 2013-11-26 02:35:25 |
| 1ad3f250-17dc-4d3d-9aff-15f3ed40cec9 | ff84fc35-b22a-492d-b8f2-5fb79be170a7 | BTC        | 1100781000685 |           0 |    3941 | virtual |                 NULL |                   NULL | N              | 2014-02-20 22:30:51 |
| 166c11b8-f2b3-4302-a21d-c2c706994447 | 0afba433-817e-49d4-a72f-0576c660861b | BTC        |  981919410221 |           0 |    6752 | virtual |        1000000000000 |                   NULL | N              | 2014-02-24 18:41:47 |
| f070b09c-f046-4bf2-889d-cb9defcce7fd | 19b38844-b58b-4d1b-8ba1-af2e45b164f7 | BTC        |  875255455182 |           0 |   32579 | virtual |        1000000000000 |                   NULL | N              | 2014-02-24 03:13:22 |
| d4e3840c-938d-47a2-bb72-7678c3d8f7d2 | 945e5a15-4100-4199-91ea-d8d8bec7e07a | BTC        |  800000000000 |           0 |    3496 | virtual |                 NULL |                   NULL | N              | 2013-08-08 18:50:39 |
| 45548a69-11e5-4d31-bc0c-d8f0294eb4f1 | 4339257e-4b12-4412-9574-0785ccf613bb | BTC        |  605128552400 |           0 |    6966 | virtual |        1000000000000 |                   NULL | N              | 2014-02-22 08:18:31 |
| da39625a-d901-425c-9586-86bab7bf9880 | 0766852e-9187-4712-80f0-1fbb78813b07 | BTC        |  519991480916 |           0 |   16523 | virtual |         200000000000 |                   NULL | N              | 2014-02-25 00:49:35 |
| c10d31d6-81a5-4df1-9d2a-6524c4b3ad04 | f2d2f8ea-dd36-4d32-adb7-79448755d53c | BTC        |  500000000000 |           0 |     165 | virtual |                    0 |                   NULL | N              | 2014-01-21 03:22:40 |
| caebcd40-3f04-402e-84bd-13f019ca9847 | ccb564e6-f33a-40fc-b222-aa4d8bc88fa6 | BTC        |  422607868556 |           0 |     902 | virtual |          90000000000 |                   NULL | N              | 2014-02-22 17:11:30 |
| 33ec6422-fec5-458d-a25c-284790aedc99 | 0b1bb842-d189-48c2-899b-6b1893ba0db8 | BTC        |  396731866419 |           0 |    3870 | virtual |        1000000000000 |                   NULL | N              | 2014-02-24 18:56:05 |
| 30245646-10ee-481c-802e-fd8828efa43a | 40399e92-1249-4e80-be0d-30c59a995dff | BTC        |  388009278436 |           0 |    6831 | virtual |        1000000000000 |                   NULL | N              | 2014-02-21 21:43:43 |
| eee8ae06-fbc0-40eb-8ca3-d909acf096a3 | 679376ba-ffad-4fab-831c-b5c445cbb59e | BTC        |  370719697264 |           0 |    5747 | virtual |                 NULL |                   NULL | N              | 2014-02-07 14:01:24 |
| 64b2e05b-52da-4cfa-8fd8-890af1da5a10 | 944d5ea9-40c6-4dc1-92ef-45afbde02716 | BTC        |  360731800000 |           0 |     989 | virtual |                 NULL |                   NULL | N              | 2012-03-15 07:56:41 |
| 85452c04-0665-4979-bb8a-8886cc2f0a10 | 87c17550-bb6a-4ab1-b3a9-bcd8b72906f7 | BTC        |  356516619593 |           0 |    5077 | virtual |                 NULL |                   NULL | N              | 2014-02-25 01:13:16 |

"btc_xfer_report.csv":
Code:
Wallet,Entry,Date,Operation,Amount
00001bd2-cdb1-4707-b125-97dfdc46d3f4,682b3d0a-67d7-4b62-8ed4-4e1d39d54a69,"2011-07-27 11:11:00",deposit,0.05
00001bd2-cdb1-4707-b125-97dfdc46d3f4,e441aa74-372f-488d-8342-e2e845041e88,"2011-08-09 11:14:07",deposit,0.85
00001bd2-cdb1-4707-b125-97dfdc46d3f4,e1173927-a09b-4dc0-a085-138e0e21558d,"2011-09-23 11:29:47",withdraw,-1.40154
00005afe-8eac-418b-945b-6016166ccb13,a97682c8-dfc2-4d6e-9bdc-66aa1dda355b,"2013-04-12 14:25:21",deposit,100
00005afe-8eac-418b-945b-6016166ccb13,ce10fe19-0551-41e7-9160-d9241e67281a,"2013-04-08 19:23:33",withdraw,-8
00005afe-8eac-418b-945b-6016166ccb13,db9d0a3c-4a94-4710-9fcd-f98aa7dbd968,"2013-04-08 20:57:16",withdraw,-20
00005afe-8eac-418b-945b-6016166ccb13,1a812ba4-578f-42d7-a19d-8982fcc7fe72,"2013-04-16 20:42:28",withdraw,-0.1
00005afe-8eac-418b-945b-6016166ccb13,701f5de7-b527-4f50-9fb2-a6430d912ea9,"2013-04-17 19:36:14",withdraw,-99.9
00005afe-8eac-418b-945b-6016166ccb13,aaa584a1-5e22-4fab-9862-5713041c47b2,"2013-04-19 13:49:43",withdraw,-55
00005afe-8eac-418b-945b-6016166ccb13,34ff41b3-b021-4331-b834-e08be410490a,"2013-04-20 20:19:00",withdraw,-1
00005afe-8eac-418b-945b-6016166ccb13,10138f9f-ec2b-4ca1-a7c3-d36f56bae3df,"2013-05-19 09:01:31",withdraw,-0.5
00005afe-8eac-418b-945b-6016166ccb13,9731a1f6-5e66-4a76-8a53-10257411d0ba,"2013-08-08 21:23:40",withdraw,-80.06210892

What these mean, when they were created, whether they're even real, and whether they check with the blockchain remains to be analyzed. But that's what's in there.

Looking up some of those addresses at "blockchain.info" returns no find. Try it yourself. This may be totally bogus data.
sr. member
Activity: 441
Merit: 250
March 10, 2014, 04:23:31 PM
#43
Not sure if someone posted this but I've uploaded an xls version of Gox BTC balances at [...]. No macros or any dodgy stuff.

Sure.

If there were no macros or "dodgy stuff" this would have been a csv or a txt, which are a magnitude smaller and possible to open securely.

People, don't be stupid here. Don't get carried away. There are at any time about a dozen well known ways to run code on your computer if you open anything with Excel, or Word, or Acrobat Reader. (Really. All the mentioned file formats can wrap everything from Flash to CLR components, which in turn contains even more vulnerabilities.)
sr. member
Activity: 441
Merit: 250
March 10, 2014, 04:18:07 PM
#42
That's why I wrote "isolated" (no shared folders, preferably on a separate physical machine, guest additions disabled, etc.).

No, that's just insane. There has been exploits to pretty much all virtualization systems, not just the guest drivers.

Sure, a separate physical machine with no network would do, but what could you possibly gain from running possible malware? Do you expect the software to burst into jackpot mode and magically withdraw all your goxcoins?

You don't run malware. Ever. You decompile it.
sr. member
Activity: 248
Merit: 252
1. Collect underpants 2. ? 3. Profit
March 10, 2014, 03:55:01 PM
#41

Not sure if someone posted this but I've uploaded an xls version of Gox BTC balances at http://filebin.ca/1F3qa078QQSL or http://filebin.ca/1F3qa078QQSL/BTC_mtgox_balances.xls. No macros or any dodgy stuff.
legendary
Activity: 4690
Merit: 1276
March 10, 2014, 01:50:42 PM
#40
I don't see the point of a checksum of a file, published by a cybercriminal, that has proven to contain malware.
But in general, I agree with you.

At the time I suggested it, it was not clear whether or not the archive contained trojans.

It is good practice to document a checksum for distributed files no matter what.  If the file is mirrored, this can produce a very high reliability indicator of file integrity and serves as a tip-off for subversion.  Indeed, we saw the file in question mirrored to multiple places very quickly.

Again, checksums are also useful to track versions over time.  If you get the same file from the same place, but it has a different checksum the next day, this is a very reliable indication that it has been screwed with.

Pretty much everyone, I think, was suspicious of the original file.  Had it been looked at by professionals and blessed as clean it would be critical to be able to verify that a copy that one might find in their possession was the same thing that was analyzed by competent parties.

Nobody is saying that checksums, and in particular simple ones like md5 or sha256, are the key to solving every crime worldwide.  Nor is it something with take the place of one's brain in assessing attack scenarios.  It is, however, a simple and reliable tool which can significantly reduce an attack surface.

legendary
Activity: 860
Merit: 1026
March 10, 2014, 01:27:36 PM
#39
I don't see the point of a checksum of a file, published by a cybercriminal, that has proven to contain malware.
But in general, I agree with you.
legendary
Activity: 4690
Merit: 1276
March 10, 2014, 12:52:49 PM
#38
Checksums only speak to the integrity of a file contents...they say nothing about the content (other than it differs from some other variant.)
Just a quick addendum: You also have to be able to trust the source of the checksums, which in reality is harder than it sounds.

http://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/


The author describes the difficulty of being rigorous in solving a somewhat different problem.  Rigor against sophisticated, motivated, and well funded attackers is damn difficult.  To bad that putty doesn't make it more practical since this is one of the few pieces of software where it is really necessary in some cases.

For the item under discussion here, we are mostly concerned about non-sophisticated parties doing cheap hacks.  The possibility that some Bulgarian hacker will be able to distributed a modified version of sha256 which will recognize his crafted mtgox.zip and give false info is remote.  Similarly, the possibility that an attacker would be able to do DPI and modify all values of the checksum which a user sees and thus fool them is also remote.

By sharing checksums on a forum such as this, people are acting as a community and attacks which are otherwise possible (if difficult) become effectively impossible.  A few people producing the checksums that they have could reliably uncover an effort to distributed multiple variants of a file which would be very valuable to know about.

My concern was that the original would be found to be benign but there would evolve toxic variants and people would be fooled in this way.  The simple act of looking at a checksum would halt that problem.  As it is, it looks like the file was full of attacks from the get-go.

sr. member
Activity: 364
Merit: 250
American1973
March 10, 2014, 12:38:10 PM
#37
If there was cooperation, then the smart and gutsy "I'll run this in a sandbox" people, can help the fearful "I don't know how it works" crew.  And it seems like this is kinda happening, as helpful users are doing.

But, you took your biggest risk trusting Gox, so don't get all preachy now about being safe.  Fear is what you stepped over, to invest at Gox.  Fear is what you now relent to, because you got Goxxed.

But, fearing programs and computers, is not the place to be emotionally.  Just learn how notepad works and go from there.
legendary
Activity: 860
Merit: 1026
March 10, 2014, 12:33:10 PM
#36
Checksums only speak to the integrity of a file contents...they say nothing about the content (other than it differs from some other variant.)
Just a quick addendum: You also have to be able to trust the source of the checksums, which in reality is harder than it sounds.
http://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/

EDIT:
If anybody finds anything different let me know, I would be very much interested in this.
Here's the link to the decompiled code of the TibanneBackOffice.exe done by a kind redditor:
https://3d3.ca/ijKOh.vbs#eV7i3HIliI93y+UR
hero member
Activity: 516
Merit: 500
March 10, 2014, 12:31:20 PM
#35
In another thread someone said they had decompiled it and had posted the code, and that there was some suspicious code. I don't know if that was here or another forum though.
The .pdf contains the evil JavaScript.
Hmm ... I analyzed the PDF and there is no JS inside. It looks like the real deal, I mean it has been created with a very old version of OpenOffice

Code:
PDFiD 0.1.2 CV-Mark_Karpeles_20100325.pdf
 PDF Header: %PDF-1.4
 obj                   41
 endobj                41
 stream                14
 endstream             14
 xref                   1
 trailer                1
 startxref              1
 /Page                  2
 /Encrypt               0
 /ObjStm                0
 /JS                    0
 /JavaScript            0
 /AA                    0
 /OpenAction            1
 /AcroForm              0
 /JBIG2Decode           0
 /RichMedia             0
 /Launch                0
 /EmbeddedFile          0
 /XFA                   0
 /Colors > 2^24         0

So the important bits are "/JS 0", "/JavaScript 0" and  "/OpenAction 1". 0 means there is nothing 1 (or more) means there is something. So evidently there is no Javascript embedded. However there is a OpenAction command. A little research reveals that it opens the following object: "/OpenAction [1 0 R /XYZ null null 0]". This means object 1 0 is going to be executed.

This object looks like this:
Code:
%PDF-1.4
1 0 obj
/pdftk_PageNum 1
/Resources 2 0 R
/Contents 3 0 R
/Parent 4 0 R
/Type /Page
/MediaBox [0 0 612 792]
/Group
/CS /DeviceRGB
/I true
/S /Transparency
endobj
This is the standard (at least at that time around the 2000s) OpenOffice page header. Which gets sometimes mistaken as malware by some crap scanners.
If anybody finds anything different let me know, I would be very much interested in this.

Cheers

    one4many
legendary
Activity: 4690
Merit: 1276
March 10, 2014, 12:28:47 PM
#34
But I don't think your truly explaining the reason to use checksums: A trusted person releases a file to the wild, and states this is my files checksum. The problem here is the person who created this file is not trusted.

Just want to make that clear for people that are not engineers or coders or tech savvy to understand when to be using a checksum.

Since this file was released by an untrusted source checksums become useless and could give someone false hope.

Kosta


If it is simply a question about whether there are multiple files called exactly 'MtGox2014Leak.zip' floating around, checksums are anything but useless.  They are in fact mandatory.

Knowing whether there are multiple different files with that name being distributed would be terrific information to know as early as possible.

If you want to trust someone you should be looking for a PGP sig.  Checksums only speak to the integrity of a file contents...they say nothing about the content (other than it differs from some other variant.)

Your point about danger of checksum hashes giving (lazy, ignorant, naive) people a false sense of security is a good one however.  The same can be said of PGP sigs and a lot of other otherwise useful constructs.  That is not really a good excuse not to use these tools however.

Pages:
Jump to: