Baru-baru ini saya menerima permintaan untuk memeriksa kemungkinan pemulihan data dari smartphone yang rusak. Ponsel tersebut terjatuh dan berhenti berfungsi. Tidak ada layar, tidak ada pengisian daya, tidak ada komunikasi pada antarmuka apa pun, tidak ada tanda-tanda kehidupan, itu tidak lebih dari sebuah batu bata. Sebuah batu bata yang didalamnya banyak data yang berguna tanpa sinkronisasi cloud atau cadangan offline. Tidak perlu dikatakan lagi betapa pentingnya bagi pemiliknya untuk mendapatkan kembali informasi yang tak ternilai harganya dari perangkat tersebut.
Beberapa identifikasi kerusakan dan upaya pemulihan telah dilakukan oleh pihak profesional lainnya, bahkan layar baru telah dipesan dan dicoba, tetapi tidak ada satupun kegiatan yang memberikan hasil yang menjanjikan.
Setelah upaya yang gagal, pemiliknya hampir putus asa, tetapi untungnya, kami memiliki kenalan yang sama dan beginilah cara saya mendapatkan gambarnya. Karena penyelidikan sebelumnya, telepon tiba kepada saya dalam keadaan dibongkar sebagian, tanpa baterai dan dengan beberapa pelindung logam yang sudah dilepas.
Cara Mengembalikan data eMMC di Handphone yang Sudah Rusak
Sebagai langkah pertama, saya mencoba menemukan penyimpanan data. Cukup jelas untuk mengidentifikasi chip memori pada PCB, yaitu SK hynix H26M64103EMR. Ini adalah eMMC 32GB yang sederhana dalam paket FBGA yang umum. Saya memiliki beberapa proyek terkait eMMC di masa lalu, di mana saya harus berurusan dengan antarmuka chip dan pembuangan atau manipulasi memori secara langsung. Hal ini sering menjadi tugas dalam proyek peretasan perangkat keras yang saya kerjakan, misalnya untuk mendapatkan akses penuh ke sistem file OS pada head unit mobil atau sistem tertanam lainnya, hanya untuk menyebutkan contoh lain.
Ini adalah momen pertama yang menjanjikan untuk mendapatkan data pemiliknya kembali, karena semua aktivitas non-invasif gagal, saya memutuskan untuk menggunakan teknik yang disebut "chip-off analysis". Ini berarti bahwa chip memori yang diberikan harus dilepas dari PCB dan dengan metode antarmuka yang dipilih, isinya harus dibaca secara langsung untuk diproses lebih lanjut.
Poin penting untuk metode ini adalah pengaturan enkripsi yang digunakan dapat menjadi kunci keberhasilan atau kegagalan. Enkripsi yang diaktifkan atau diberlakukan dapat mencegah pemulihan data yang berhasil, bahkan jika chip memori tidak mati dan isinya dapat dibuang. Jika enkripsi sudah ada, dekripsi juga harus dipecahkan, yang saat ini, dengan desain yang semakin hati-hati dan dengan komponen perangkat keras yang dipilih dengan tepat, sangat menantang atau bisa jadi (hampir) tidak mungkin. Untungnya, setidaknya dari perspektif pemulihan data, pemilik tidak menyalakan enkripsi, sehingga keadaan dapat dilanjutkan ke langkah berikutnya.
Setelah PCB dilepaskan dari bodi, saya menempelkan papan ke permukaan logam dengan pita kapton. Kemudian sedikit fluks disuntikkan di sekitar chip untuk penyebaran panas yang lebih baik dan saya menggunakan stasiun udara panas untuk mengalirkan kembali bola BGA dan membiarkan saya menarik chip dari PCB.
Ada banyak cara untuk berkomunikasi dengan chip eMMC. Sebagian besar dari mereka memanfaatkan fakta bahwa chip ini pada dasarnya adalah memori standar MMC (MultiMediaCard), tetapi dalam format tertanam (dari mana "e" berasal). Ini berarti, bahwa segera setelah koneksi ke pin chip yang diperlukan diselesaikan, pembaca kartu USB sederhana dapat melakukan pekerjaan untuk membaca dan menulis memori. Chip ini biasanya mendukung beberapa mode komunikasi, menggunakan misalnya antarmuka paralel 8 bit atau 4 bit atau antarmuka tunggal 1 bit.
Untuk pengaturan yang mudah dan tanpa alat khusus biasanya digunakan mode 1 bit. Satu-satunya kriteria untuk metode ini adalah bahwa pembaca juga harus mendukung mode 1 bit (pembaca kartu USB Transcend tampaknya merupakan kandidat yang baik untuk pekerjaan ini). Dalam hal ini, hanya pin CMD, CLK, DAT0, VCC (VCC, VCCQ) dan GND (VSS, VSSQ) yang harus dihubungkan. Jangan takut dengan banyaknya pin, pada kenyataannya, hanya beberapa pin yang digunakan. Pinout ini bersifat umum dan berdasarkan standar JEDEC, jadi apa pun vendor atau chip yang Anda gunakan, hampir pasti Anda akan menemukan pin-pin penting di lokasi yang sudah diketahui, seperti yang ditunjukkan pada gambar di bawah ini.
Saya membuat sambungan ini di masa lalu dengan menyolder secara manual kabel tembaga berinsulasi 0,1 mm ke bola BGA yang diberikan, lalu menyambungkannya langsung ke reader. Jika Anda memiliki tangan yang stabil dan keterampilan menyolder yang cukup baik, maka hal itu sama sekali tidak mustahil. Ada beberapa kasus ketika Anda harus berurusan dengan pergeseran level logika dan beberapa voltase (voltase yang berbeda untuk memori dan Flash I/O / ini adalah VCC / dan untuk inti pengontrol memori dan MMC I/O / yang merupakan VCCQ /), jadi selalu berhati-hatilah dan bacalah lembar data atau ukur level voltase yang diberikan terlebih dahulu.
Kali ini, saya memiliki perangkat yang lebih baik, jadi saya menggunakan adaptor SD-EMMC plus yang dihubungkan ke E-Mate Pro eMMC Tool. Dengan menggunakan kombinasi ini, saya dapat dengan mudah memasang chip eMMC yang telah dilepas ke soket BGA tanpa kabel khusus dan berkomunikasi dengannya dengan pembaca kartu USB sederhana.
Ketika saya memasang alat ini ke mesin linux saya, alat ini mengenali perangkat ini sebagai penyimpanan massal USB dan siap untuk digunakan.
[ 700.932552] usb 1-2: new high-speed USB device number 5 using xhci_hcd [ 701.066678] usb 1-2: New USB device found, idVendor=8564, idProduct=4000 [ 701.066693] usb 1-2: New USB device strings: Mfr=3, Product=4, SerialNumber=5 [ 701.066702] usb 1-2: Product: Transcend [ 701.066709] usb 1-2: Manufacturer: TS-RDF5 [ 701.066716] usb 1-2: SerialNumber: 000000000036 [ 701.129205] usb-storage 1-2:1.0: USB Mass Storage device detected [ 701.130866] scsi host0: usb-storage 1-2:1.0 [ 701.132385] usbcore: registered new interface driver usb-storage [ 701.137673] usbcore: registered new interface driver uas [ 702.132411] scsi 0:0:0:0: Direct-Access TS-RDF5 SD Transcend TS3A PQ: 0 ANSI: 6 [ 702.135476] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 702.144406] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 723.787452] sd 0:0:0:0: [sda] 61079552 512-byte logical blocks: (31.3 GB/29.1 GiB) [ 723.809221] sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15 sda16 sda17 sda18 sda19 sda20 sda21 sda22 sda23 sda24 sda25 sda26 sda27 sda28 sda29 sda30 sda31 sda32 sda33 sda34 sda35 sda36 sda37 sda38 sda39 sda40 sda41 sda42 sda43
Perangkat dipetakan ke perangkat "sda". Seperti yang dapat Anda lihat dari ekstrak "dmesg" di atas, terdapat banyak partisi (sda1 - sda43) pada sistem berkas. Sebelum melangkah lebih jauh, seperti biasa dalam kasus seperti ini, langkah pertama adalah membuat dump dari chip memori, kemudian melakukan langkah selanjutnya pada cadangan offline. Alat "dd" dapat digunakan untuk tujuan ini:
$ dd if=/dev/sda of=sony_z5p.img status=progress
Dengan dump penuh, aman untuk melanjutkan analisis. Dengan menggunakan "parted", saya memeriksa struktur partisi:
Model: (file) Disk /mnt/hgfs/kali/sony_z5p/sony_z5p.img: 31.3GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 131kB 2228kB 2097kB TA 2 4194kB 21.0MB 16.8MB ext4 LTALabel 3 21.0MB 105MB 83.9MB fat16 modem msftdata 4 105MB 105MB 131kB pmic 5 105MB 105MB 131kB alt_pmic 6 105MB 105MB 1024B limits 7 105MB 106MB 1049kB DDR 8 106MB 106MB 262kB apdp 9 106MB 107MB 262kB msadp 10 107MB 107MB 1024B dpo 11 107MB 107MB 524kB hyp 12 107MB 108MB 524kB alt_hyp 13 109MB 111MB 1573kB fsg 14 111MB 111MB 8192B ssd 15 111MB 112MB 1049kB sbl1 16 112MB 113MB 1049kB alt_sbl1 17 113MB 115MB 1573kB modemst1 18 117MB 119MB 1573kB modemst2 19 119MB 119MB 262kB s1sbl 20 119MB 120MB 262kB alt_s1sbl 21 120MB 120MB 131kB sdi 22 120MB 120MB 131kB alt_sdi 23 120MB 121MB 1049kB tz 24 121MB 122MB 1049kB alt_tz 25 122MB 122MB 524kB rpm 26 122MB 123MB 524kB alt_rpm 27 123MB 124MB 1049kB aboot 28 124MB 125MB 1049kB alt_aboot 29 125MB 192MB 67.1MB boot 30 192MB 226MB 33.6MB rdimage 31 226MB 259MB 33.6MB ext4 persist 32 259MB 326MB 67.1MB FOTAKernel 33 326MB 327MB 1049kB misc 34 327MB 328MB 524kB keystore 35 328MB 328MB 1024B devinfo 36 328MB 328MB 524kB config 37 331MB 436MB 105MB rddata 38 436MB 447MB 10.5MB ext4 apps_log 39 449MB 466MB 16.8MB ext4 diag 40 466MB 780MB 315MB ext4 oem 41 780MB 990MB 210MB ext4 cache 42 990MB 25.8GB 24.8GB ext4 userdata 43 25.8GB 31.3GB 5513MB ext4 system
Hanya satu partisi, yaitu "userdata" yang relevan untuk pemulihan. Dengan menggunakan "losetup", Anda dapat secara otomatis melakukan mount pada semua partisi yang dikenali dari image, atau hanya partisi yang dipilih dengan menentukan, misalnya, offset partisi yang tepat pada image.
$ losetup -Prf sony_z5p.img
Segera setelah sistem berkas terpasang, pemulihan tidak lagi menjadi masalah besar. Sudah menjadi rahasia umum di mana dan bagaimana Android dan aplikasi umum menyimpan hal-hal seperti kontak, pesan teks atau gambar. Untuk aplikasi lain, cukup mudah untuk mengungkap detailnya dengan merayapi folder aplikasi dan memeriksa file basis datanya.
Berdasarkan permintaan pemiliknya, saya hanya fokus pada beberapa data saja:
- Kontak
Format: SQLite database
Path: /data/com.android.providers.contacts/databases/contacts2.db
- Pesan teks
Format: SQLite database
Path: /data/com.google.android.gms/databases/icing_mmssms.db
- File yang diunduh
Format: simple files
Path: /media/0/Download
- Gambar dan video
Format: simple files
Path: /media/0/DCIM
- Gambar dan video Viber
Format: simple files
Path: /media/0/viber/media
Dengan perangkat cadangan yang telah di-root, Anda dapat mengganti file database pada perangkat baru ke perangkat yang telah dipulihkan agar ponsel dapat mengurai dan menampilkan data untuk diproses lebih lanjut, namun pengguna biasa tidak dapat melakukan hal ini. Bagi saya, lebih mudah melakukan pemulihan langsung, daripada bermain-main dengan ponsel lain. File gambar dan multimedia tidak memerlukan perawatan khusus karena hanya perlu disimpan tanpa pemrosesan pasca, tetapi untuk data lain yang disimpan dalam basis data SQLite, ekstraksi harus memperhatikan struktur basis data yang diberikan dan output yang dihasilkan harus berupa sesuatu yang dapat dibaca oleh manusia atau dapat diproses oleh alat lain.
Saya menemukan skrip "dump-contacts2db" di GitHub yang bagus untuk mem-parsing database kontak dan mengekspor item-itemnya ke format vCard yang umum. Ini adalah sesuatu yang nantinya dapat diimpor oleh pengguna ke beberapa aplikasi dan disinkronkan kembali ke ponsel baru.
Untuk pesan teks, saya tidak menemukan sesuatu yang berguna, jadi saya segera memeriksa struktur data yang sesuai dalam database SQLite
CREATE TABLE mmssms( _id INTEGER NOT NULL, msg_type TEXT NOT NULL, uri TEXT NOT NULL, type INTEGER, thread_id INTEGER, address TEXT, date INTEGER, subject TEXT, body TEXT, score INTEGER, content_type TEXT, media_uri TEXT, read INTEGER DEFAULT 0, UNIQUE(_id,msg_type) ON CONFLICT REPLACE);
Tidak terlalu rumit, jadi dalam waktu 2 menit saya membuat skrip yang cepat dan kotor, tetapi berfungsi untuk mengekstrak utas teks ke file CSV:
It was not too complex, so in 2 minutes I made a quick and dirty but working script to extract the text threads to CSV files:
#!/bin/bash
for thread in $(sqlite3 icing_mmssms.db 'select distinct thread_id from mmssms'); do
address=`sqlite3 icing_mmssms.db 'select distinct address from mmssms where thread_id = '"$thread" | sed 's/[^0-9]*//g'`
sqlite3 -csv icing_mmssms.db 'SELECT datetime(date/1000, "unixepoch","localtime"), address, msg_type, body from mmssms where thread_id = '"$thread"' order by date' > sms_with_${address}_thread_${thread}.csv
done
Selesai, ini adalah langkah terakhir untuk memulihkan setiap file dan info yang diminta dari ponsel. Saya tidak menghabiskan terlalu banyak waktu untuk pemulihan itu sendiri dan seluruh prosesnya juga menyenangkan bagi saya, terutama dengan mengetahui fakta bahwa orang lain telah gagal sebelum saya.
0 comments:
Posting Komentar