CryptoRecovery.io – Dịch vụ khôi phục ví

Liên hệ với chúng tôi

Làm thế nào để khôi phục ví MetaMask? Mất mật khẩu, lưu trữ kho, mã hóa và phân tích dữ liệu

Hình đại diện của Peter CryptoRecovery
Peter Phục hồi tiền điện tử
Làm thế nào để khôi phục ví MetaMask? Mất mật khẩu, lưu trữ kho, mã hóa và phân tích dữ liệu

Làm thế nào để khôi phục ví MetaMask? Mất mật khẩu, lưu trữ kho, mã hóa và phân tích dữ liệu

Nếu bạn đang đọc bài viết này, có lẽ bạn đã mất quyền truy cập vào ví MetaMask và đang cạn kiệt các phương án giải quyết. Tôi đã dành nhiều năm để giúp mọi người khôi phục ví – từ các nhà giao dịch DeFi đã định dạng lại máy tính xách tay của họ cho đến những người lớn tuổi đã “dọn dẹp” các tiện ích mở rộng trên trình duyệt của họ. Hướng dẫn này bao gồm tất cả những gì tôi biết về cách MetaMask lưu trữ khóa của bạn, dữ liệu đó thực sự được lưu trữ ở đâu trên đĩa và cách lấy lại dữ liệu khi gặp sự cố. Không có gì trong số này là lý thuyết. Mọi kỹ thuật ở đây đều xuất phát từ các trường hợp khôi phục thực tế.

MetaMask thực sự lưu trữ khóa của bạn như thế nào

Trước khi có thể khôi phục bất kỳ thứ gì, bạn cần phải hiểu rõ mình đang khôi phục cái gì. MetaMask không lưu trữ khóa riêng tư của bạn trong một tệp có tên là private_keys.txt. Nó lưu trữ chúng bên trong một blob được mã hóa có tên là kho, được lưu trữ trong bộ nhớ mở rộng của trình duyệt.

Khi bạn tạo ví MetaMask và đặt mật khẩu, đây là những gì diễn ra bên trong hệ thống. MetaMask sẽ tạo ra một cụm từ ghi nhớ theo tiêu chuẩn BIP-39 (gồm 12 từ) Cụm từ khôi phục bí mật) và gói nó – cùng với bất kỳ khóa riêng nào được nhập vào – thành một mảng JSON gồm các đối tượng “keyring”. Mảng đó được chuyển đổi thành chuỗi, sau đó được mã hóa bằng cách sử dụng AES-256-GCM bằng một khóa được tạo ra từ mật khẩu của bạn thông qua PBKDF2-HMAC-SHA256. Kết quả là một khối JSON gồm ba hoặc bốn trường được ghi vào chrome.storage.local (trên các trình duyệt dựa trên Chromium) hoặc IndexedDB (trên Firefox).

Trong các phiên bản cũ, kho lưu trữ được mã hóa trông như sau:

{"data":"SGFuZGxlIHRoaXMgZW5jcnlwdGVkIGRhdGE=","iv":"MTIzNDU2Nzg5MDEyMzQ1Ng==","salt":"cmFuZG9tMzJieXRlc2FsdHZhbHVlaGVyZQ=="}

Và trong các phiên bản mới hơn (từ v11.16.x trở đi), có thêm một trường thứ tư:

{"data":"...","iv":"...","keyMetadata":{"algorithm":"PBKDF2","params":{"iterations":600000}},"salt":"..."}

Điều đó keyMetadata Điều này chính là yếu tố quyết định sự khác biệt giữa việc phục hồi chỉ mất vài phút và việc phục hồi kéo dài hàng tuần. Chúng ta sẽ nói thêm về vấn đề này ngay sau đây.

Quy trình mã hóa tuy đơn giản nhưng rất quan trọng và cần được hiểu rõ. Mật khẩu UTF-8 của bạn sẽ được nhập dưới dạng khóa PBKDF2 thô thông qua API Web Crypto. A Mã ngẫu nhiên 32 byte (được tạo từ crypto.getRandomValues()) được sử dụng cùng với mật khẩu để tạo ra một khóa AES-GCM 256-bit. Sau đó, một IV ngẫu nhiên 16 byte mã hóa dữ liệu chùm khóa đã được chuyển đổi thành dạng chuỗi. data Trường này chứa cả văn bản mã hóa và thẻ xác thực GCM, được mã hóa bằng Base64. Một điểm đáng chú ý: MetaMask sử dụng một IV 16 byte cho AES-GCM, điều này không tuân theo tiêu chuẩn – NIST SP 800-38D khuyến nghị sử dụng 12 byte. Điều này gây ra các vấn đề về khả năng tương tác với một số thư viện mã hóa (ví dụ: OpenSSL của Ruby sẽ từ chối hoạt động với nó).

Khi bạn mở khóa MetaMask bằng mật khẩu, quá trình này sẽ diễn ra ngược lại. KeyringController lấy chuỗi kho dữ liệu được mã hóa từ bộ nhớ lâu dài, sau đó truyền nó đến browser-passworder’s decrypt hàm này phân tích cú pháp JSON, trích xuất giá trị salt, tạo khóa bằng thuật toán PBKDF2 với các tham số tương tự, giải mã bằng AES-GCM và chuyển đổi kết quả trở lại thành các đối tượng keyring. Các keyring đã được giải mã sẽ tồn tại chỉ trong ký ức – chúng được lưu trữ trong memStore (một ObservableStore (ví dụ) và không bao giờ được ghi ra đĩa dưới dạng văn bản thuần túy.

Một kho dữ liệu đã được giải mã chứa một mảng thường có dạng như sau:

[
  {
    "type": "HD Key Tree",
    "data": {
      "mnemonic": "abandon ability able about above absent ...",
      "numberOfAccounts": 3,
      "hdPath": "m/44'/60'/0'/0"
    }
  },
  {
    "type": "Simple Key Pair",
    "data": ["0xabc123..."]
  }
]

Cái HD Key Tree Chuỗi khóa chứa cụm từ ghi nhớ và số lượng tài khoản được tạo ra từ đó. Simple Key Pair Các mục này là các khóa riêng được nhập riêng lẻ. Nếu bạn đã kết nối ví phần cứng, bạn cũng sẽ thấy Trezor Hardware và Ledger Hardware các loại chìa khóa – mặc dù chúng chỉ lưu trữ đường dẫn dẫn xuất và địa chỉ công khai, chứ không lưu trữ khóa riêng (những khóa này vẫn được lưu trữ trên thiết bị phần cứng).

Với Manifest V3 (kiến trúc service worker mà Chrome bắt đầu triển khai từ năm 2023), MetaMask đã bổ sung tính năng lưu trữ khóa mã hóa dưới dạng tệp JWK đã xuất, nhờ đó có thể giải mã lại kho lưu trữ khi service worker khởi động lại mà không cần yêu cầu nhập mật khẩu lần nữa. encryptionKey và encryptionSalt các trường xuất hiện trong memStore khi cacheEncryptionKey đã được bật.

MetaMask lưu trữ dữ liệu của bạn ở đâu trên từng nền tảng

Tìm được ví là đã thành công một nửa. MetaMask lưu trữ dữ liệu ở các vị trí khác nhau tùy thuộc vào trình duyệt và hệ điều hành, và những khác biệt này rất quan trọng đối với quá trình khôi phục.

Các trình duyệt dựa trên Chromium (Chrome, Brave, Edge)

Trên các trình duyệt dựa trên Chromium, chrome.storage.local được lưu vào Cơ sở dữ liệu LevelDB trên đĩa. Mã định danh phần mở rộng quyết định tên thư mục.

ID tiện ích mở rộng của Chrome là nkbihfbeogaeaoehlefnkodbefgpgknn – đã in sâu vào ký ức của mọi chuyên gia phục hồi chức năng. Dũng cảm sử dụng cùng một ID vì nó được cài đặt từ Chrome Web Store. Edge sẽ có ID riêng nếu được cài đặt từ Cửa hàng tiện ích mở rộng của Edge: ejbalbakoplchlghecdalmeeeajnimhm. Tuy nhiên, nếu người dùng cài đặt MetaMask trên Edge thông qua Chrome Web Store (mà Edge hỗ trợ), ứng dụng này sẽ giữ nguyên ID Chrome. Sự khác biệt này thường khiến người dùng nhầm lẫn.

Dưới đây là các đường dẫn đầy đủ:

Chrome trên Windows:
C:\Users\<USER>\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn\

Chrome trên macOS:
~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Chrome trên Linux:
~/.config/google-chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Brave trên Windows:
C:\Users\<USER>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn\

Brave trên macOS:
~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Edge trên Windows (cài đặt từ Cửa hàng Edge):
C:\Users\<USER>\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\ejbalbakoplchlghecdalmeeeajnimhm\

Một chi tiết quan trọng: nếu người dùng có nhiều hồ sơ Chrome, hãy thay thế Default cùng với Profile 1, Profile 2, v.v. Tôi đã thấy có người tìm kiếm nhầm hồ sơ suốt hàng giờ liền.

Firefox – một con quái vật hoàn toàn khác biệt

Firefox không sử dụng LevelDB. Trình duyệt này lưu trữ dữ liệu tiện ích mở rộng trong IndexedDB, mà Firefox triển khai dựa trên SQLite. Mã định danh tiện ích mở rộng là webextension@metamask.io, nhưng Firefox gán một mã UUID nội bộ duy nhất cho mỗi lần cài đặt – chẳng hạn như 196319ec-3a5e-4efe-9413-c327a770d874. Bạn có thể tìm thấy nó tại about:debugging trong phần “Firefox này.”

Dữ liệu được lưu trữ tại:

Windows: %APPDATA%\Mozilla\Firefox\Profiles\<PROFILE>\storage\default\moz-extension+++<UUID>^userContextId=4294967295\idb\

macOS: ~/Library/Application Support/Firefox/Profiles/<PROFILE>/storage/default/moz-extension+++<UUID>^userContextId=4294967295/idb/

Linux: ~/.mozilla/firefox/<PROFILE>/storage/default/moz-extension+++<UUID>^userContextId=4294967295/idb/

Bên trong idb/ thư mục này, bạn sẽ thấy các tệp nhị phân có tên là các số. Đây là Định dạng nén Snappy – bạn không thể chỉ đơn giản là tìm kiếm trong các tệp đó như với các tệp LevelDB. Bạn cần giải nén chúng trước bằng một công cụ như snappy-fox trước khi dữ liệu trong kho lưu trữ có thể được trích xuất. Đây là sai lầm phổ biến nhất mà tôi thường thấy khi khôi phục dữ liệu trên Firefox: người dùng mở tệp nhị phân, thấy dữ liệu bị lộn xộn xen lẫn với những đoạn văn bản có thể nhận ra, và cho rằng kho lưu trữ đã bị hỏng. Thực ra không phải vậy. Đó chỉ là do dữ liệu đã được nén.

Trước Firefox 63, bộ nhớ tiện ích mở rộng sử dụng một tệp JSON đơn giản có tên là storage.js trong thư mục cấu hình. Nếu bạn đang khôi phục một bản cài đặt rất cũ, hãy tìm storage.js hoặc storage.js.migrated.

LevelDB và tệp 0001.ldb mà ai cũng thắc mắc

LevelDB là bộ máy lưu trữ khóa-giá trị của Google, và việc nắm rõ cấu trúc tệp của nó là điều cần thiết để khôi phục MetaMask trên bất kỳ trình duyệt Chromium nào.

Một thư mục LevelDB của MetaMask chứa nhiều loại tệp khác nhau. .ldb tệp (Bảng chuỗi được sắp xếp, hay SSTables) là dạng lưu trữ khóa-giá trị cố định và được sắp xếp theo thứ tự. .log tệp là Write-Ahead Log – một vùng đệm tạm thời chứa các thao tác ghi gần đây trước khi chúng được ghi ra .ldb tệp. Có một MANIFEST-###### dữ liệu siêu dữ liệu cơ sở dữ liệu theo dõi tệp, một CURRENT tệp trỏ đến tệp manifest đang hoạt động, và một LOCK tệp ngăn chặn việc truy cập đồng thời.

Dữ liệu kho lưu trữ thường được lưu trữ trong một có số thứ tự thấp .ldb tệp – 000003.ldb, 000005.ldb, hoặc tương tự. Tài liệu hướng dẫn của chính MetaMask nêu rõ: “Đây phải là một giá trị số nhỏ. Nếu đó là một con số lớn, thì đó không phải là kho tiền.” 0001.ldb tệp (hoặc 000001.ldb) là một trong những bảng SSTable đầu tiên được tạo ra khi MetaMask được khởi tạo lần đầu tiên. Nó thường chứa kho tiền gốc được tạo ra trong quá trình tạo ví.

Trích xuất dữ liệu kho từ .ldb tệp thường rất đơn giản trên Chromium. Mở tệp trong trình soạn thảo văn bản (Sublime Text, VS Code, thậm chí là Notepad++) và tìm kiếm chuỗi vault. Bạn sẽ thấy khối JSON được mã hóa được nhúng trong cấu trúc bản ghi LevelDB. Sao chép toàn bộ nội dung từ {"data":" cho đến khi kết thúc "} – đó là két sắt của bạn.

Trên Mac hoặc Linux, chỉ cần một dòng lệnh này là đủ:

LC_ALL="C" egrep -roa 'vault":"(.*?\\"})' ~/Library/Application\ Support/Google/Chrome/Default/Local\ Extension\ Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/ | sed -E 's/.*({.*}).*/\1/g' | head -1

Một điều cần lưu ý: .ldb các tệp có thể sử dụng Nén nhanh trên các khối dữ liệu. Nếu việc tìm kiếm chuỗi không thành công và bạn thấy các khối dữ liệu rác nhị phân, khối dữ liệu bạn cần có thể đã được nén bằng Snappy. .log Ngược lại, tệp này luôn ở dạng chưa nén – dữ liệu thô dạng cặp khóa-giá trị được chia thành các khối 32KB. Nếu .ldb phương pháp này không thành công, luôn kiểm tra .log tệp. Tài liệu chính thức của MetaMask có đề cập như sau: “Nếu bạn không thể khôi phục kho tiền của mình bằng tệp .ldb, hãy kiểm tra xem có tệp .log nào không.”

Một tính năng của LevelDB cực kỳ hữu ích cho việc khôi phục: đó là chỉ ghi thêm. Các thao tác cập nhật và xóa không thay đổi các bản ghi hiện có – chúng chỉ thêm các bản ghi mới với số thứ tự cao hơn. Các bản ghi cũ vẫn tồn tại cho đến khi quá trình nén dữ liệu hợp nhất và loại bỏ chúng. Điều này có nghĩa là nếu ai đó nhập một SRP mới lên trên một SRP cũ, dữ liệu kho lưu trữ cũ vẫn có thể tồn tại trong một phiên bản cũ hơn .ldb tập tin chưa được nén. Tôi đã khôi phục thành công các ví bị “ghi đè” bằng cách này không chỉ một lần.

Đối với việc trích xuất theo chương trình, btcrecover Dự án bao gồm extract-metamask-vaults.py, có khả năng đọc chính xác cơ sở dữ liệu LevelDB và trích xuất tất cả các mục trong kho dữ liệu – bao gồm cả những mục cũ có thể đang ẩn trong các tệp chưa được nén. cyclone-github/metamask_extractor Công cụ này có chức năng tương tự và có thể xuất trực tiếp sang định dạng tương thích với hashcat.

Khi các tệp lưu trữ bị hỏng

Sự hỏng hóc của kho lưu trữ thường xuất phát từ một trong số ít nguyên nhân sau: trình duyệt bị treo trong quá trình ghi dữ liệu (mất điện, lỗi kernel, buộc đóng ứng dụng), quá trình cập nhật MetaMask bị gián đoạn khi đang ghi đè lên bộ nhớ, lỗi đĩa thực tế (ngăn đĩa hỏng, hao mòn SSD), hoặc – ngày càng phổ biến – phần mềm diệt virus cách ly các tệp JavaScript của MetaMask, điều này có thể khiến cơ sở dữ liệu LevelDB rơi vào trạng thái không nhất quán dù dữ liệu trong kho lưu trữ vẫn còn nguyên vẹn.

Bạn sẽ biết kho lưu trữ của mình bị hỏng khi tệp JSON không thể phân tích cú pháp. Các dấu ngoặc nhọn bị thiếu, chuỗi base64 bị cắt ngắn, hoặc các byte null xuất hiện ngẫu nhiên giữa trường dữ liệu. Công cụ giải mã kho lưu trữ MetaMask sẽ hiển thị thông báo “Lỗi giải mã kho lưu trữ” hoặc đơn giản là thất bại mà không có thông báo nào.

Việc khôi phục phụ thuộc vào loại và mức độ hư hỏng. Nếu cấu trúc JSON bị hỏng nhưng dữ liệu được mã hóa vẫn còn nguyên vẹn phần lớn, bạn thường có thể tái tạo kho tiền thủ công. Định dạng này rất nghiêm ngặt – bạn cần phải nhập chính xác data, iv, và salt các trường (cùng với keyMetadata (đối với các kho lưu trữ mới hơn). Loại bỏ các byte null và ký tự điều khiển. Kiểm tra xem data, iv, và salt các giá trị là mã Base64 hợp lệ. Nếu data trường bị cắt ngắn, tuy nhiên, bạn sẽ gặp rắc rối – AES-GCM yêu cầu toàn bộ văn bản mã hóa cùng với thẻ xác thực của nó (16 byte cuối cùng của data (trường) để giải mã. Chỉ cần thiếu một byte là toàn bộ quá trình sẽ thất bại.

Đối với các cơ sở dữ liệu LevelDB bị hỏng một phần, trong đó .ldb nếu chính các tệp đã bị hỏng, hãy thử đọc .log thay vào đó, hãy sử dụng tệp – đây là định dạng đơn giản hơn (các khối tuần tự 32KB với tiêu đề 7 byte) và có thể chứa bản sao mới hơn của kho dữ liệu đã tồn tại sau sự cố hỏng dữ liệu. Nếu cả hai phương pháp trên đều không hiệu quả, đôi khi bạn có thể sử dụng các thư viện phân tích cú pháp LevelDB của Python (CCL Solutions Group đã phát hành các bản triển khai hoàn toàn bằng Python cho việc phân tích cú pháp LevelDB, giải nén Snappy và giải mã V8) để trích xuất các bản ghi một cách chính xác từ các tệp cơ sở dữ liệu bị hỏng, bỏ qua các khối bị hỏng.

Nhiều SRP có thể cùng tồn tại trong một thư mục LevelDB. Nếu người dùng nhập một cụm từ hạt giống mới, mục kho lưu trữ cũ có thể vẫn tồn tại trong một thư mục riêng biệt .ldb tệp hoặc thậm chí trong cùng một tệp nhưng ở vị trí khác. Luôn tìm kiếm tất cả các trường hợp của mẫu hình vòm, không chỉ mẫu đầu tiên.

Vấn đề về tệp bị ghi đè và cách khắc phục

Đây là tình huống gây ra nhiều đau lòng nhất. Ai đó gỡ cài đặt MetaMask – có thể họ đang khắc phục sự cố, có thể họ đang “dọn dẹp” trình duyệt, hoặc có thể họ không nhận ra mình đang làm gì. Trên các trình duyệt dựa trên Chromium, việc gỡ cài đặt một tiện ích mở rộng xóa toàn bộ thư mục dữ liệu tiện ích mở rộng, bao gồm tất cả .ldb, .log, và các tệp manifest. Trên Firefox, moz-extension+++<UUID> Thư mục đó sẽ bị xóa, và vì mỗi lần cài đặt lại sẽ tạo ra một UUID mới, nên bản cài đặt mới sẽ không can thiệp vào vị trí cũ (nhưng vị trí cũ đã không còn nữa).

Tài liệu hướng dẫn của chính MetaMask đã nêu rõ điều này: “Dữ liệu của tiện ích mở rộng trình duyệt sẽ bị xóa khi tiện ích này được gỡ cài đặt. Nói chung, điều này có nghĩa là dữ liệu trong kho lưu trữ của bạn sẽ biến mất.”

Chính từ “thông thường” này lại mang ý nghĩa rất lớn. Dữ liệu được xóa theo logic – hệ thống tệp đánh dấu các sector đó là trống – nhưng các byte thực tế không được ghi đè bằng số 0 ngay lập tức. Trên ổ cứng HDD truyền thống, dữ liệu vẫn tồn tại cho đến khi các sector đó được các tệp mới sử dụng lại. Trên ổ SSD, lệnh TRIM có thể khiến dữ liệu đã xóa không thể khôi phục được chỉ trong vài phút, thậm chí vài giây.

Quy tắc đầu tiên khi khôi phục kho dữ liệu bị ghi đè: ngừng sử dụng máy tính ngay lập tức. Mỗi tệp mới được ghi vào ổ đĩa đều có thể ghi đè lên các sector từng chứa kho dữ liệu của bạn. Nếu có thể, hãy tháo ổ đĩa ra và gắn nó ở chế độ chỉ đọc trên một máy tính khác.

Các công cụ khắc phục sự cố cho tình huống này, theo thứ tự ưu tiên mà tôi thường sử dụng trước tiên:

  • Phần mềm tùy chỉnh (đa nền tảng) của chúng tôi dành cho việc khôi phục các tệp đã bị xóa logic
  • extundelete hoặc ext4magic dành cho hệ thống tệp ext3/ext4 trên Linux
  • Tìm kiếm trên đĩa thô trong trường hợp bất đắc dĩ: grep -rboa "vault" /dev/sdX để quét thiết bị đĩa thô nhằm tìm các chuỗi khóa kho
  • Các công cụ được thiết kế riêng của chúng tôi để khôi phục dữ liệu từ tệp khi siêu dữ liệu hệ thống tệp bị mất – hãy cấu hình để tìm kiếm {"data":" mẫu

Tôi đã khôi phục thành công các kho lưu trữ từ các ổ đĩa đã được gỡ cài đặt từ vài tuần trước – trên ổ cứng HDD. Đối với ổ SSD, tỷ lệ thành công sẽ giảm mạnh ngay cả sau vài giờ sử dụng liên tục. Việc cài đặt lại MetaMask là điều tồi tệ nhất bạn có thể làm, vì nó sẽ tạo ra một cơ sở dữ liệu LevelDB mới ngay trong cùng thư mục đó, có thể ghi đè lên các sector cũ.

Firefox có một ưu điểm ở điểm này. Vì mỗi lần cài đặt sẽ được gán một mã UUID mới, nên việc cài đặt lại sẽ tạo các tệp trong một đường dẫn thư mục mới. Các tệp cũ moz-extension+++<OLD-UUID> dữ liệu, ngay cả khi thư mục đó đã bị xóa, sẽ không bị ghi đè bởi các tệp của bản cài đặt mới. Ngoài ra còn có hai tùy chọn ẩn của Firefox – extensions.webextensions.keepUuidOnUninstall và extensions.webextensions.keepStorageOnUninstall – rằng, nếu được đặt thành true trong about:config Trước khi gỡ cài đặt, hãy ngăn trình duyệt xóa bộ nhớ của tiện ích mở rộng. Nhưng không ai chủ động thiết lập các tùy chọn này cả.

Phiên bản MetaMask trên thiết bị di động hoàn toàn khác biệt

Ứng dụng di động MetaMask được phát triển trên nền tảng React Native và lưu trữ dữ liệu theo cách hoàn toàn khác so với tiện ích mở rộng trình duyệt. Kho dữ liệu được mã hóa sẽ được xử lý qua @react-native-async-storage/async-storage, sử dụng các hệ thống nền tảng riêng biệt.

Trên Android, AsyncStorage thường ghi vào một Cơ sở dữ liệu SQLite tại /data/data/io.metamask/databases/RKStorage. Đường dẫn này yêu cầu quyền truy cập root để đọc trực tiếp. Cơ chế mã hóa kho dữ liệu sử dụng cùng phương pháp tạo khóa dựa trên PBKDF2, nhưng có những điểm khác biệt quan trọng so với tiện ích mở rộng trên máy tính để bàn: ứng dụng di động trước đây chỉ sử dụng 5.000 lần lặp PBKDF2 và mã hóa bằng AES-CBC thay vì AES-GCM. Điều này có nghĩa là các kho lưu trữ trên thiết bị di động không thể thay thế cho các kho lưu trữ trên máy tính để bàn, ngay cả khi mật khẩu là giống nhau.

Trên iOS, dữ liệu được lưu trữ trong vùng cách ly của ứng dụng tại <AppSandbox>/Documents/. Đối với việc khôi phục bản sao lưu iCloud, đường dẫn liên quan là Apps → MetaMask → Documents → persistStore → persist-root – Bạn sẽ cần một công cụ như iMazing để duyệt bản sao lưu iOS trên máy Mac. Việc phương pháp này có hiệu quả hay không phụ thuộc vào việc người dùng có bật tính năng sao lưu iCloud khi MetaMask đang hoạt động hay không, và theo báo cáo, những thay đổi từ phía Apple đã khiến phương pháp này thỉnh thoảng không hoạt động được.

Ứng dụng MetaMask trên thiết bị di động cũng tích hợp một SecureKeychain mô-đun (được xây dựng trên react-native-keychain) lưu trữ mật khẩu ví của người dùng trong iOS Keychain hoặc Android Keystore để mở khóa bằng sinh trắc học. Một cuộc kiểm tra an ninh đã phát hiện ra rằng SecureKeychain bổ sung một lớp mã hóa bổ sung bằng cách sử dụng chuỗi “foxCode” làm giá trị muối – và hóa ra đây lại là một chuỗi được cài đặt cố định "encrypt". Nhóm phát triển MetaMask thừa nhận đây là một biện pháp bảo mật đa tầng chứ không phải là một thông tin bí mật mang tính quyết định đối với an ninh.

Thách thức cơ bản trong việc khôi phục dữ liệu trên thiết bị di động là không có tính năng trích xuất kho lưu trữ thủ công tương đương với việc tìm .ldb các tệp trên màn hình nền. Bạn không thể kết nối SSH vào iPhone của mình và tìm kiếm các chuỗi khóa trong kho lưu trữ. Bắt đầu từ MetaMask phiên bản di động 6.3.0, ứng dụng này có tính năng khôi phục kho dữ liệu tự động sẽ được kích hoạt khi phát hiện lỗi hỏng dữ liệu – nhưng nếu ứng dụng bị xóa, dữ liệu kho dữ liệu cục bộ sẽ bị mất trừ khi bạn có bản sao lưu thiết bị. Các cơ chế sao lưu trên Android đặc biệt không đáng tin cậy trong việc sao lưu toàn bộ dữ liệu bên trong ứng dụng. Quan điểm chính thức của MetaMask là khuyến nghị chuyển các tài sản sang một SRP mới thay vì dựa vào tính năng khôi phục kho lưu trữ của Android.

Sự thay đổi về số lần lặp trong thuật toán PBKDF2 đã khiến mọi công cụ khôi phục dữ liệu đều không hoạt động

Trong nhiều năm qua, MetaMask đã sử dụng 10.000 lần lặp PBKDF2 – giá trị mặc định được cài đặt sẵn trong browser-passworder thư viện. Mọi công cụ khôi phục, mọi mô-đun hashcat, mọi tập lệnh tấn công dò mật khẩu đều được thiết lập để chạy 10.000 lần lặp. Rồi vào cuối năm 2023 / đầu năm 2024, mọi thứ đã thay đổi.

Cái @metamask/browser-passworder Thư viện phiên bản 4.2.0 (phát hành ngày 13 tháng 11 năm 2023) đã bổ sung tính năng hỗ trợ các tùy chọn tạo khóa có thể tùy chỉnh. Giá trị mặc định mới của thư viện đã được điều chỉnh lên 900.000 lần lặp, nhưng tiện ích mở rộng của MetaMask đã được cấu hình để sử dụng 600.000 lần lặp – Tuân thủ khuyến nghị năm 2023 của OWASP về PBKDF2-HMAC-SHA256. Bởi tiện ích mở rộng MetaMask v11.16.11 (được xác nhận trong bản phát hành Hashcat tháng 6 năm 2024), các kho lưu trữ mới đã được tạo ra với 600.000 lần lặp và phiên bản mới keyMetadata trường.

Điều này đồng nghĩa với việc chi phí tính toán cho mỗi lần thử mật khẩu tăng gấp 60 lần. Một cuộc tấn công brute-force mất một ngày với 10.000 lần lặp trước đây giờ mất hai tháng với 600.000 lần lặp trên cùng một phần cứng. Cộng đồng hashcat đã phải phát triển các kernel tùy chỉnh – chế độ 26620, do cyclone đóng góp – để xử lý định dạng mới. Chế độ tiêu chuẩn 26600 có 10.000 lần lặp được mã hóa cứng.

Điều quan trọng là các kho lưu trữ cũ SẼ KHÔNG được mã hóa lại tự động. Nếu bạn tạo ví vào năm 2021, kho lưu trữ của bạn vẫn sử dụng 10.000 lần lặp trừ khi MetaMask chủ động kích hoạt quá trình mã hóa lại ( updateVault Có một hàm được thiết kế cho mục đích này, nhưng vẫn chưa rõ MetaMask gọi hàm đó với tần suất như thế nào khi mở khóa. Bạn có thể xác định phiên bản đang sử dụng dựa trên sự có mặt hay vắng mặt của keyMetadata trường. Không keyMetadata? Đó là 10.000 lần lặp. Đã keyMetadata cùng với "iterations": 600000? Đó là định dạng mới.

Dưới đây là bảng thời gian đầy đủ về các phiên bản thư viện mã hóa có liên quan đến quá trình khôi phục:

  • browser-passworder phiên bản 1.x–2.x (trước năm 2022): 10.000 lần lặp, được cài đặt cố định. Được công bố mà không có @metamask phạm vi.
  • v3.0.0 (Tháng 8 năm 2022): Đổi tên thành @metamask/browser-passworder. Không có thay đổi nào trong quá trình lặp.
  • v4.2.0 (Tháng 11 năm 2023): Đã bổ sung keyMetadata hỗ trợ. Số lần lặp mặc định cho quá trình mã hóa đã được thay đổi thành 900.000. keyFromPassword Tương thích ngược ở mức 10.000.
  • v4.3.0 (Tháng 11 năm 2023): Đã bổ sung isVaultUpdated để kiểm tra xem kho lưu trữ có đáp ứng các thông số mục tiêu hay không.
  • Phiên bản 5.0.0 (tháng 4 năm 2024): Yêu cầu tối thiểu Node.js phiên bản 16. Không có thay đổi nào về mã hóa.
  • Phiên bản 6.0.0 (tháng 12 năm 2024): Yêu cầu tối thiểu Node.js phiên bản 18.18. Không có thay đổi nào liên quan đến tiền điện tử.

Đối với các chuyên gia phục hồi dữ liệu: hãy luôn kiểm tra định dạng kho lưu trữ trước tiên. Điều này sẽ quyết định toàn bộ phương pháp tiếp cận của bạn.

Chính sách mật khẩu của MetaMask và ý nghĩa của nó đối với các cuộc tấn công dò mật khẩu

MetaMask yêu cầu mật khẩu phải có độ dài tối thiểu là 8 ký tự. Chỉ vậy thôi. Không yêu cầu chữ hoa, số hay ký tự đặc biệt. Tiện ích mở rộng hiển thị chỉ báo độ mạnh trực quan (“Yếu” / “Tốt”) nhưng không chặn các mật khẩu yếu miễn là chúng đáp ứng độ dài tối thiểu. Cũng không có giới hạn độ dài tối đa – các ký tự Unicode được hỗ trợ. Chính sách này đã được áp dụng từ ít nhất đầu năm 2018 (được đề cập trong vấn đề GitHub #3515).

Một số trang web của bên thứ ba đã đưa ra thông tin sai lệch rằng MetaMask yêu cầu phải có chữ hoa, chữ thường, số và ký tự đặc biệt. Điều này là không đúng. Yêu cầu duy nhất là mật khẩu phải có 8 ký tự.

Đối với phương pháp bẻ khóa bằng lực brute-force, điều này có ý nghĩa vô cùng quan trọng. Một mật khẩu gồm 8 ký tự chỉ viết thường có không gian khóa khoảng 208 tỷ tổ hợp (26^8). Đối với một kho mật khẩu cũ có 10.000 lần lặp, hashcat trên GPU hiện đại có thể kiểm tra hàng nghìn hàm băm mỗi giây, khiến mật khẩu này có thể bị bẻ khóa trong vài ngày. Đối với một kho mật khẩu có 600.000 lần lặp, thời gian sẽ tăng gấp 60 lần. Một mật khẩu mạnh gồm 12 ký tự trở lên với chữ hoa, chữ thường và ký hiệu? Với phần cứng hiện tại, mật khẩu này thực tế là không thể bẻ khóa được với cả hai định dạng trên.

Công cụ khôi phục thực tế được ưa chuộng nhất là btcrecover – Chính MetaMask khuyến nghị tính năng này dành cho những người dùng còn nhớ lờ mờ mật khẩu của mình. Tính năng này hỗ trợ đoán mật khẩu dựa trên mã thông báo và dựa trên mẫu, cho phép bạn thiết lập một mẫu như "my" + [dog|cat|bird] + [2019|2020|2021] + ["!"|"@"|"#"] và kiểm tra hiệu quả tất cả các tổ hợp. Đối với các cuộc tấn công được tăng tốc bằng GPU, chế độ 26600 của hashcat xử lý các kho lưu trữ cũ, chế độ 26610 xử lý các kho lưu trữ trên thiết bị di động, còn chế độ 26620 (hoặc phiên bản 26600 được biên dịch lại với số lần lặp được cập nhật) xử lý định dạng mới có 600.000 lần lặp.

Các nguồn gốc và “đại dịch” thiếu hụt quỹ

Quá trình chuyển khoản chính là nguyên nhân gốc rễ của hầu hết các vấn đề liên quan đến việc “tiền của tôi biến mất”. MetaMask sử dụng đường dẫn tiêu chuẩn BIP-44 cho Ethereum: m/44'/60'/0'/0. Các tài khoản được tính toán bằng cách tăng chỉ số cuối cùng lên: m/44'/60'/0'/0/0 (tài khoản đầu tiên), m/44'/60'/0'/0/1 (thứ hai), m/44'/60'/0'/0/2 (thứ ba), v.v. Cách thức này áp dụng cho tất cả các chuỗi tương thích với EVM – cùng một địa chỉ trên Ethereum, Polygon, Arbitrum, BSC.

Vấn đề là không phải ai cũng sử dụng cùng một đường dẫn. Ledger Live các ứng dụng m/44'/60'/x'/0/0, tăng dần account trường thay vì address_index. Di sản của Ledger (đường dẫn cũ của MEW/MyCrypto) sử dụng m/44'/60'/0'/x – chỉ có bốn cấp độ thay vì năm. Địa chỉ đầu tiên (m/44'/60'/0'/0/0) là giống hệt nhau trên MetaMask, Ledger Live và Trezor. Tuy nhiên, Tài khoản thứ hai trở đi hoàn toàn khác biệt, bởi vì mỗi ví sẽ tăng giá trị của một thành phần khác nhau trong đường dẫn.

Điều này dẫn đến một tình huống lỗi rất cụ thể: người dùng khôi phục cụm hạt giống Ledger của mình trong MetaMask, thấy tài khoản đầu tiên cùng số dư của nó, sau đó thêm tài khoản thứ hai và thấy… con số 0. Số tiền không hề biến mất. Chúng vẫn đang nằm tại địa chỉ được tạo ra từ m/44'/60'/1'/0/0 (theo phong cách Ledger Live), nhưng MetaMask đang xem xét m/44'/60'/0'/0/1. Các khóa hoàn toàn khác nhau, các địa chỉ hoàn toàn khác nhau.

Đường dẫn dẫn xuất Ethereum mặc định của Trezor tương thích với MetaMask: m/44'/60'/0'/0/x. Vì vậy, việc khôi phục từ Trezor sang MetaMask thường hoạt động được với tất cả các tài khoản. Các vấn đề liên quan đến việc chuyển đổi giữa các ví chủ yếu xảy ra giữa Ledger và MetaMask, cũng như giữa Ledger và Trezor.

Để tìm các quỹ nằm trên đường dẫn “sai”, bạn có các lựa chọn sau:

  • Hãy liên hệ với chúng tôi qua email tại địa chỉ contact@cryptorecovery.io và chúng tôi sẽ cố gắng hỗ trợ và giúp đỡ bạn.
  • MyEtherWallet (MEW): Hỗ trợ các đường dẫn dẫn xuất tùy chỉnh thông qua tùy chọn “Thêm đường dẫn”. Nhập thủ công m/44'/60'/1'/0/0, m/44'/60'/2'/0/0, v.v. để kiểm tra các địa chỉ theo kiểu Ledger Live.
  • MyCrypto: Hỗ trợ đường dẫn dẫn xuất tùy chỉnh tương tự.
  • Công cụ BIP-39 của Ian Coleman (chạy ngoại tuyến): Nhập cụm từ ghi nhớ, chọn ETH, chuyển đổi giữa các tab BIP-44 và điều chỉnh thủ công các thành phần đường dẫn.
  • btcrecover: Có thể tự động hóa quá trình kiểm thử trên các sơ đồ đường dẫn dẫn xuất khác nhau.

Một hạn chế gây khó chịu: Tính năng tích hợp Trezor của MetaMask không hỗ trợ đường dẫn dẫn xuất tùy chỉnh. Tùy chọn đường dẫn dẫn xuất tùy chỉnh đã được tích hợp cho Ledger (PR #9367) nhưng theo thông tin mới nhất, vấn đề tương tự đối với Trezor (vấn đề GitHub #11197) vẫn chưa được giải quyết. Nếu bạn đang cố gắng truy cập các tài khoản được dẫn xuất từ Ledger thông qua MetaMask + Trezor, bạn sẽ cần sử dụng MEW hoặc MyCrypto thay thế.

MetaMask và Trezor: một mối quan hệ đầy trắc trở

Tính năng tích hợp MetaMask-Trezor hoạt động thông qua Cầu Trezor – một tiến trình chạy ngầm được cài đặt cục bộ (trezord) đang lắng nghe trên http://127.0.0.1:21325/ và thu hẹp khoảng cách giữa môi trường cách ly của trình duyệt và quyền truy cập phần cứng USB. Bạn có thể kiểm tra xem nó có đang chạy hay không bằng cách nhấn http://127.0.0.1:21325/status/.

Nguyên nhân gây lỗi phổ biến nhất lại đơn giản đến mức khó ngờ: Trezor Suite vẫn đang mở. Trezor Suite khóa kết nối USB với thiết bị, khiến MetaMask không thể kết nối. Bạn phải tắt hoàn toàn ứng dụng Suite – không chỉ thu nhỏ cửa sổ mà phải đóng hẳn ứng dụng từ khay hệ thống. Theo ước tính của tôi, nguyên nhân này chiếm khoảng 40% số trường hợp “MetaMask không tìm thấy Trezor” mà tôi đã gặp.

Các vấn đề thường gặp khác và cách khắc phục:

“Đang tìm kiếm Trezor của bạn…” và cứ quay mãi không ngừng – Kiểm tra xem Bridge đã được cài đặt chưa và trezord đang chạy. Hãy thử dùng cáp USB và cổng khác. Tắt VPN, tường lửa và các tiện ích mở rộng trình duyệt (các tiện ích chặn quảng cáo và bảo vệ quyền riêng tư thường gây xung đột). Chế độ ẩn danh giúp loại bỏ xung đột giữa các tiện ích mở rộng.

“Thiết bị đang được kết nối” – Một ứng dụng hoặc tab trình duyệt khác hiện đang kết nối với Trezor. Vui lòng đóng tất cả các tab và ứng dụng khác có thể đang truy cập thiết bị.

Hạn chế của WebUSB – Firefox hoàn toàn không hỗ trợ WebUSB, điều này có nghĩa là việc kết nối Trezor trên Firefox hoàn toàn phụ thuộc vào Bridge. Chrome, Brave và Edge hoạt động thông qua cơ chế triển khai WebUSB/WebHID của Chromium.

Cảnh báo về đường dẫn dẫn xuất trên Trezor Safe 5 – Người dùng cho biết họ thấy thông báo “Đường dẫn dẫn xuất không chính xác cho tài khoản đã chọn. m/44’/60’/0’/0” trên màn hình Trezor trong quá trình xác thực giao dịch. Thông thường, cảnh báo này có thể được bỏ qua một cách an toàn – ví vẫn hoạt động bình thường dù có thông báo này. Đây là một vấn đề về mặt hình thức liên quan đến cách phần mềm hệ thống Trezor xác thực các đường dẫn có dạng không chuẩn.

Năm 2025, Trezor bắt đầu tích hợp chức năng Bridge trực tiếp vào Trezor Suite. Sự thay đổi này đã gây ra một loạt sự cố kết nối, do một số người dùng cần chạy Trezor Suite ở chế độ nền để kết nối với MetaMask, trong khi những người dùng khác lại cần tắt hoàn toàn ứng dụng này. Vui lòng kiểm tra phần Trezor Suite → Cài đặt → Ứng dụng → Trezor Connect để thực hiện các thiết lập phù hợp.

Khi MetaMask kết nối với Trezor, các tài khoản được tạo ra sẽ có sự khác biệt cơ bản so với các tài khoản ví phần mềm của MetaMask. Các tài khoản được tạo từ Trezor chỉ lưu trữ khóa công khai và đường dẫn dẫn xuất trong kho – khóa riêng vẫn được lưu trữ trên thiết bị phần cứng. MetaMask có thể hiển thị số dư (chỉ đọc thông qua khóa công khai) mà không cần kết nối với Trezor, nhưng không thể ký giao dịch nếu không có thiết bị vật lý. Nếu đã sử dụng cụm mật khẩu khi tạo tài khoản Trezor, thì phải nhập chính xác cụm mật khẩu đó để tạo lại các địa chỉ tương ứng.

Các kỹ thuật phục hồi thực sự hiệu quả trong thực tế

Sau hàng trăm ca phục hồi, đây là những tình huống tôi thường gặp nhất và cách tôi xử lý chúng.

Trường hợp 1: Có mật khẩu, nhưng đã mất cụm từ khôi phục, tiện ích mở rộng vẫn còn được cài đặt

Đây là bước đơn giản nhất. Mở trang nền của MetaMask qua chrome://extensions → Chế độ nhà phát triển → nhấp vào “service worker” (MV3) hoặc “background page” (MV2). Trong bảng điều khiển:

chrome.storage.local.get('data', result => {
    console.log(result.data.KeyringController.vault);
});

Sao chép tệp JSON của kho lưu trữ, dán vào Công cụ giải mã MetaMask Vault (metamask.github.io/vault-decryptor), nhập mật khẩu của bạn, và công cụ này sẽ hiển thị cụm từ khôi phục cũng như các khóa riêng tư đã nhập. Vault Decryptor được phát triển bởi Dan Finlay, đồng sáng lập MetaMask – công cụ này cũng có thể chấp nhận .ldb tệp trực tiếp qua tính năng tải lên tệp.

Trường hợp 2: Đã có mật khẩu, tiện ích mở rộng đã bị gỡ cài đặt nhưng dữ liệu có thể vẫn còn trên đĩa

Truy cập vào thư mục dữ liệu của tiện ích mở rộng. Nếu thư mục đó vẫn còn tồn tại (đôi khi quá trình gỡ cài đặt không xóa sạch hoàn toàn, hoặc người dùng chỉ tắt chứ không gỡ bỏ tiện ích mở rộng), hãy lấy tệp .ldb và .log tệp. Giải nén kho dữ liệu bằng grep, một trình soạn thảo văn bản, hoặc btcrecover’s extract-metamask-vaults.py. Giải mã bằng công cụ Vault Decryptor.

Nếu thư mục đó đã biến mất, vui lòng liên hệ với chúng tôi qua địa chỉ email contact@cryptorecovery.io và chúng tôi sẽ hỗ trợ bạn trong việc phân tích dữ liệu trên đĩa cứng.

Bạn cũng có thể gắn ổ đĩa ở chế độ chỉ đọc và thực hiện tìm kiếm trực tiếp trên đĩa để tìm các mẫu chuỗi trong kho lưu trữ. Trên Linux: grep -rboa '{"data":"' /dev/sdX. Thành công phụ thuộc rất nhiều vào mức độ hoạt động của đĩa sau khi xóa và loại ổ đĩa là SSD hay HDD.

Trường hợp 3: Quên mật khẩu, có tệp kho lưu trữ

Đây là một trường hợp sử dụng phương pháp brute-force. Trích xuất tệp vault, chuyển đổi nó sang định dạng hashcat bằng cách sử dụng metamask2hashcat.py hoặc cyclone-github/metamask_extractor. Sau đó, hãy chạy hashcat (chế độ 26600 cho các kho lưu trữ cũ, 26620 cho các kho lưu trữ mới) hoặc btcrecover cùng với tệp mã thông báo mô tả những gì bạn còn nhớ về mật khẩu. Nếu bạn biết mật khẩu của mình có dạng như “myDog” cộng với một năm và một ký hiệu, btcrecover có thể kiểm tra các tổ hợp đó một cách hiệu quả.

Tình huống 4: Khôi phục Firefox

Tìm mã UUID của MetaMask tại about:debugging. Truy cập vào thư mục lưu trữ. Giải nén các tệp nhị phân IndexedDB bằng cách sử dụng snappy-fox:

./snappy-fox input_file.snappy output.txt

Tìm tệp JSON của Vault trong thư mục đã giải nén. Sau đó, tiếp tục sử dụng công cụ giải mã Vault. JesseBusman/FirefoxMetamaskWalletSeedRecovery Tập lệnh Python tự động hóa toàn bộ quy trình này – nó quét hồ sơ Firefox, tìm kiếm dữ liệu trong kho lưu trữ và xuất ra định dạng JSON đã được định dạng sẵn để giải mã.

Tình huống 5: Tiền dường như bị mất sau khi nhập tiền hạt giống

Kiểm tra đường dẫn dẫn xuất. Nếu nhập khóa hạt giống Ledger vào MetaMask, các tài khoản từ tài khoản thứ hai trở đi sẽ hiển thị các địa chỉ khác nhau và số dư bằng không. Hãy sử dụng MEW hoặc MyCrypto với đường dẫn dẫn xuất tùy chỉnh để tìm thấy số dư tại Ledger Live (m/44'/60'/x'/0/0) hoặc Ledger Legacy (m/44'/60'/0'/x) đường dẫn. Nếu sử dụng mật khẩu Trezor, hãy đảm bảo rằng bạn nhập chính xác mật khẩu đó – một mật khẩu khác sẽ tạo ra một tập hợp địa chỉ hoàn toàn khác từ cùng một hạt giống.

Những công cụ pháp y đáng có trong bộ dụng cụ của bạn

  • Công cụ giải mã MetaMask Vault – phiên bản chính thức, có thể chạy ngoại tuyến, hỗ trợ kết nối trực tiếp .ldb tải lên tệp
  • btcrecover – Khôi phục mật khẩu bằng cách so khớp mẫu, được MetaMask khuyến nghị
  • hashcat – Tấn công dò tìm toàn bộ được tăng tốc bằng GPU (chế độ 26600, 26610, 26620)
  • snappy-fox – Giải nén nhanh cho Firefox
  • Các công cụ Python của CCL Solutions Group – phân tích cú pháp LevelDB bằng Python thuần túy, giải nén Snappy, giải mã V8

Kết luận: Điều gì phân biệt giữa những trường hợp phục hồi thành công và thất bại

Sự khác biệt giữa việc lấy lại ví và mất nó vĩnh viễn hầu như luôn phụ thuộc vào những gì xảy ra trong những phút đầu tiên sau khi phát hiện ra sự cố. Hành động gây hại nhất chính là cài đặt lại MetaMask trên cùng một hồ sơ trình duyệt – điều này sẽ ghi đè lên thư mục LevelDB bằng các tệp mới. Hành động gây hại thứ hai là tiếp tục sử dụng máy tính bình thường trên ổ SSD sau khi xóa kho lưu trữ, điều này sẽ kích hoạt cơ chế TRIM và khiến việc khôi phục dữ liệu ở cấp độ sector trở nên bất khả thi.

Nếu bạn chỉ nhớ được ba điều từ hướng dẫn này: hãy sao lưu cụm từ hạt giống của bạn ra giấy, hiểu rằng kho lưu trữ của bạn nằm trong một thư mục cụ thể mà bạn có thể sao chép và bảo quản, và nếu có sự cố xảy ra, hãy ngừng sử dụng máy tính đó ngay lập tức trước khi thực hiện bất kỳ thao tác khôi phục nào. Mã hóa rất chắc chắn – AES-256-GCM với 600.000 lần lặp PBKDF2 sẽ không bị tấn công bằng phương pháp brute-force trừ khi mật khẩu yếu – nhưng bản thân dữ liệu lại rất dễ bị tổn thương. Nó chỉ là vài kilobyte trong cơ sở dữ liệu LevelDB và có thể biến mất chỉ với một cú nhấp chuột dọn dẹp trình duyệt.

Mọi ví tiền điện tử mà tôi không thể khôi phục đều có cùng một nguyên nhân gốc rễ: người dùng vẫn tiếp tục sử dụng thiết bị sau khi dữ liệu bị mất. Mọi ví tiền điện tử mà tôi đã khôi phục thành công đều là những trường hợp dữ liệu vẫn còn trên đĩa cứng – đôi khi ở những vị trí bất ngờ, đôi khi tồn tại dưới dạng nhiều bản sao nhờ kiến trúc chỉ ghi thêm (append-only) của LevelDB, nhưng luôn là do người dùng đã dừng lại và suy nghĩ kỹ trước khi hành động.

Nếu bạn cần trợ giúp để khôi phục ví Metamask, vui lòng liên hệ với chúng tôi qua email: contact@cryptorecovery.io để được tư vấn chuyên nghiệp và miễn phí hoặc truy cập trang liên hệ của chúng tôi