UEFI Hexdump

Kalau kamu lagi ngembangin UEFI firmware, pasti suatu saat pengen nge-dump data biner pake fasilitas debug. Nih contoh gampang buat nge-hexdump buffer:

#include <Library/BaseLib.h>
#include <Library/PrintLib.h>

STATIC
VOID
DumpBufferHex (
  VOID* Buf,
  UINTN Size
)
{
  UINT8* Buffer = (UINT8*)Buf;
  UINTN  i, j, k;
  char Line[80] = "";

  for (i = 0; i < Size; i += 16) {
    if (i != 0) {
      DEBUG ((DEBUG_INFO, "%a\n", Line));
    }
    Line[0] = 0;
    AsciiSPrint (&Line[AsciiStrLen (Line)], 80 - AsciiStrLen (Line), "  %08x  ", i);
    for (j = 0, k = 0; k < 16; j++, k++) {
      if (i + j < Size) {
        AsciiSPrint (&Line[AsciiStrLen (Line)], 80 - AsciiStrLen (Line), "%02x", Buffer[i + j]);
      } else {
        AsciiSPrint (&Line[AsciiStrLen (Line)], 80 - AsciiStrLen (Line), "  ");
      }
      AsciiSPrint (&Line[AsciiStrLen (Line)], 80 - AsciiStrLen (Line), " ");
    }
    AsciiSPrint (&Line[AsciiStrLen (Line)], 80 - AsciiStrLen (Line), " ");
    for (j = 0, k = 0; k < 16; j++, k++) {
      if (i + j < Size) {
        if ((Buffer[i + j] < 32) || (Buffer[ i + j] > 126)) {
          AsciiSPrint (&Line[AsciiStrLen (Line)], 80 - AsciiStrLen (Line), ".");
        } else {
          AsciiSPrint (&Line[AsciiStrLen (Line)], 80 - AsciiStrLen (Line), "%c", Buffer[i + j]);
        }
      }
    }
  }
  DEBUG ((DEBUG_INFO, "%a\n", Line));
}

Fungsinya bakal nge-print data biner dalam format hex, lengkap dengan offset dan representasi ASCII biar gampang dibaca.

Updating XML Files dengan PowerShell

Bayangin kamu punya file file.xml kayak gini:

<?xml version="1.0" encoding="UTF-8"?>
<data>
  <item name="Item 1" id="0" />
  <item name="Item 2" id="1001" />
  <item name="Item 3" id="0" />
  <item name="Item 4" id="1002" />
  <item name="Item 5" id="1005" />
  <item name="Item 6" id="0" />
</data>

Kamu pengen ganti semua id="0" jadi angka incremental. Di PowerShell, gampang banget:

$xml = New-Object xml
$xml.Load("$PWD\file.xml")
$i = 2001
foreach ($item in $xml.data.item) {
    if ($item.id -eq 0) {
        $item.id = [string]$i
        $i++
    }
}
$xml.Save("$PWD\updated.xml")

Hasilnya, updated.xml bakal jadi kayak gini:

<?xml version="1.0" encoding="UTF-8"?>
<data>
  <item name="Item 1" id="2001" />
  <item name="Item 2" id="1001" />
  <item name="Item 3" id="2002" />
  <item name="Item 4" id="1002" />
  <item name="Item 5" id="1005" />
  <item name="Item 6" id="2003" />
</data>

Mudah, cepat, nggak pake ribet

(Ab)using Microsoft's Symbol Servers, for Fun and Profit

Kalau kamu suka utak-atik Windows executables pake Ghidra, pasti ngerti deh rasanya lupa-lupa inget command yang dipakai. Nah, ini tips santai tapi berguna banget buat nge-analisa file Windows, misal ARM64 usbxhci.sys.

Kenapa PDB itu Penting?

Debug symbols (.pdb) itu ibarat peta harta karun. Tanpa ini, fungsi di Ghidra cuma bakal muncul kayak FUN_1c003ac90()—bingung mau mulai dari mana. Dengan .pdb, fungsi bisa muncul dengan nama yang lebih masuk akal, misal XilRegister_ReadUlong64(). Praktis banget!

Ngambil Symbols dari Microsoft

1. Pastikan sudah install Windows SDK atau Windows Driver Kit. Kalau punya Visual Studio 2019, biasanya udah termasuk.
2. Cari symchk.exe di C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\
3. Copy driver yang mau dianalisa ke folder tertentu, misal USBXHCI.SYS
4. Jalankan command ini di CMD:

"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\symchk.exe" /s srv*https://msdl.microsoft.com/download/symbols /ocx .\ USBXHCI.SYS

Kalau sukses, kamu bakal lihat:

SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1

Dan voila! usbxhci.pdb muncul di folder kamu.

Ghidra & .pdb

Dengan .pdb, Ghidra bisa kasih nama fungsi yang masuk akal. Misal, kamu mau cek kenapa rear USB-A di Raspberry Pi 4 nggak jalan di Windows 10, simbolnya bisa nunjuk kalau ada function buat akses 64-bit xHCI register jadi dua 32-bit.

Patching Driver

Kamu bisa edit USBXHCI.SYS untuk ngubah instruksi ARM64 tertentu dari tbnz → tbz supaya akses 64-bit jadi dua 32-bit. Tapi inget, begitu diubah, signature driver bakal rusak dan Windows bakal nolak booting.

Solusinya:

• Update PE checksum pake PEChecksum64.exe
• Self-sign driver supaya Windows nggak lempar error 0xc000000f
• Kalau mau boot dari USB di Pi4, bisa juga hapus 1 GB RAM limit:

bcdedit /store Y:\EFI\Microsoft\Boot\BCD /deletevalue {default} truncatememory

Kesimpulan

Intinya, simbol Microsoft itu berguna banget buat debugging. Bisa bikin hidup kamu lebih mudah kalau mau ngecek driver Windows, utamanya dengan Ghidra. Bonusnya, kalau mau iseng, bisa juga dipakai buat patch driver ARM64 di Raspberry Pi 4. Tapi tenang, ini bukan tutorial full Windows 10 di Pi 4, cuma tips simbol server aja

Et tu, Microsoft

Sebuah Sabtu sore yang indah, semuanya berjalan lancar setelah merilis versi baru software beberapa hari lalu. Tapi tiba-tiba semua berubah ketika saya mencoba mengganti nama folder di Windows 10 2004 saya.

Mimpi Buruk Storage Spaces & ReFS

File Explorer membeku, akses disk menjadi tidak responsif, dan Storage Space yang berisi semua ISO penting saya mengalami aktivitas disk konstan, tanpa aplikasi yang terlihat melakukan apa pun. Reboot juga tidak membantu; bahkan memperlambat booting.

Panel Storage Spaces menunjukkan semua HDD baik-baik saja, tes SMART juga normal, dan kombinasi drive lain tidak membantu menemukan sumber masalah. Hal ini menunjukkan bahwa Storage Spaces relatif solid dari sisi hardware, berbeda dengan Intel RAID yang terkenal rewel.

Event Viewer menampilkan banyak error ReFS, akhirnya drive saya "remounted" sebagai RAW:

Volume D: is formatted as ReFS but ReFS is unable to mount it;
ReFS encountered status The volume repair was not successful...

Ini adalah drive ReFS kedua yang hilang dalam sebulan, menunjukkan masalah dengan update Windows terbaru, KB4570719, yang tampaknya merusak data pada Storage Spaces berbasis ReFS.

Konteks Hardware & Backup

Backup ada, tapi tersebar karena keterbatasan budget. Saya menggunakan 4x4 TB HDD murah dengan parity Storage Spaces untuk menghemat biaya. Seagate terbukti cukup andal meski harga murah. Masalah ini murni software, bukan hardware.

Pelajaran

1. Segala sesuatu, termasuk OS, bisa merusak data Anda. Jangan pernah sepenuhnya mempercayai hardware atau software, termasuk OS yang besar sekalipun.
2. Independent Software Developer bisa tampak gagal karena bug OS, bukan karena software mereka sendiri. Jangan menganggap OS selalu aman dan bebas dari bug kritis.

Kesimpulannya: Windows 10 2004 dengan update tertentu bisa merusak Storage Spaces & ReFS, jadi selalu lakukan backup offline tambahan dan waspada terhadap update sistem.

Kenapa Koneksi Samba Gagal?

Sebuah pengalaman yang akhirnya menjelaskan masalah yang lama mengganggu.

Bagian 1: Masalah yang Menyeramkan

Saya menggunakan NanoPC-T4 berbasis RK3399 dari FriendlyArm/FriendlyElec untuk menjalankan layanan Linux seperti server web staging, host printer jaringan, dan Samba File Server.

Namun, ketika mencoba mengambil file besar dari Samba, Windows seringkali hang dan transfer tidak bisa dibatalkan kecuali Samba di-restart secara manual.

Yang membingungkan, masalah ini muncul setelah beralih dari Lubuntu lama bawaan pabrik ke Armbian yang lebih baru. Dengan Lubuntu, Samba stabil, tapi dengan Armbian, transfer gagal total.

Saya sempat menganggap ini bug Samba/arch64 baru dan meninggalkannya, karena log Samba tidak menunjukkan masalah apa pun, dan Windows pun tidak memberi petunjuk.

Bagian 2: Cahaya di Ujung Terowongan

Dalam eksperimen firmware UEFI Raspberry Pi 4, saya menggunakan server yang sama untuk menguji UEFI HTTP boot file ISO besar (900 MB). Transfer dari Apache juga gagal, menampilkan pesan TCP checksum error:

TcpInput: received a checksum error packet
TcpInput: Discard a packet
HttpTcpReceiveNotifyDpc: Aborted!
Error: Server response timeout.

Sementara itu, jika konten sama disajikan menggunakan Python HTTP server (python3 -m http.server 80), transfer relatif stabil, meski ada beberapa checksum error. Ini menunjukkan kemungkinan masalah jaringan yang lebih kompleks, dan terkait dengan isu Samba sebelumnya.

Solusi yang Ditemukan

Langkah pertama adalah memastikan bukan masalah hardware: ganti kabel, ganti switch, dsb. Setelah itu, cek error TCP dengan:

tcpdump -i eth0 -vvv tcp | grep incorrect

Jika banyak checksum error muncul, kemungkinan besar network adapter melakukan offloading yang menyebabkan masalah. Solusinya:

ethtool -K eth0 rx off tx off

Perintah di atas menonaktifkan offloading untuk penerimaan dan pengiriman paket, yang biasanya menyelesaikan masalah transfer file besar di Samba.

Kesimpulan

Masalah Samba yang gagal transfer file besar sering kali bukan bug Samba, tapi akibat checksum error TCP yang disebabkan oleh offloading network adapter. Mematikan offloading biasanya menyelesaikan masalah.