HOC UFS SEARCH

0
681
  • Tại sao phải search những chuỗi như “QW9w”, “==”, “QWRF”, hoặc một đoạn hex như “8A 34 AF 22…”

  • Patch thành “0”, “A”, “_” là gì, có ý nghĩa gì, dùng khi nào?

Mình giải thích gốc rễ, đảm bảo bạn hiểu bản chất – sau này gặp bất cứ signature “dị” nào cũng làm chủ được.


1. Vì sao phải search “QW9w”, “==”, “QWRF”, hoặc hex “8A 34 AF 22…”?

A. Chuỗi base64 (“QW9w”, “==”, “QWRF”…)

  • Base64 là dạng mã hóa phổ biến nhất cho token bảo mật, key Mi Account, FRP, KG, v.v.

  • “QW9w…” là base64 của chuỗi “Owp…” (“Owp” trong base64 = “QW9w”)

  • “==” là kết thúc bắt buộc của chuỗi base64 chuẩn (padding).

  • “QWRF” là base64 cho nhiều flag hoặc token khác (ví dụ FRP, Google).

  • Nếu bạn search các đoạn này, bạn sẽ “bắt trúng” vùng có thể là key base64 của máy – cần patch khi unlock, reset bảo mật, xóa account.

Tóm lại:

  • “QW9w”, “QWRF”: Đầu của một chuỗi base64 dài, dùng để nhận diện token/key vùng bảo mật.

  • “==”: Kết thúc một chuỗi base64.


B. Hex “8A 34 AF 22 68 7E…” (SHA1, SHA256, vùng KG)

  • Các vùng KG/KnoxGuard/Samsung Protection lưu mã khóa, token dưới dạng SHA1 hoặc SHA256 (chuỗi hex 40 hoặc 64 ký tự).

  • Nếu bạn đã từng unlock thành công máy cùng loại, bạn sẽ biết đoạn signature này – bạn chỉ cần search 4-10 byte đầu là đã bắt đúng vùng này (vì rất ít vùng data khác lặp lại SHA1 này).

  • Tìm xong, patch lại (“giả” SHA1) hoặc xóa/hủy đi, máy sẽ “mất lock”.


2. Tại sao lại patch thành “0”, “A”, “_”? Khi nào dùng cái nào?

A. “0” (ASCII code hex là 30)

  • “0” (30 30 30 …): Dùng để “giả” một chuỗi SHA1 hoặc token, để bảo toàn cấu trúc vùng data, tránh lỗi định dạng (hệ thống chỉ check định dạng chứ không check giá trị thực tế).

  • Nếu patch vào vùng SHA1, bạn đổi tất cả thành “0” – vùng đó vẫn là SHA1 hợp lệ, hệ thống không báo lỗi format.

B. “A” (ASCII code hex là 41)

  • “A” (41 41 41 …): Dùng để fake chuỗi base64, cho an toàn khi hệ thống parse lại (vẫn đúng chuẩn base64, không bị lỗi “invalid base64”).

  • Đặc biệt thích hợp patch vùng token Mi Account, FRP dạng base64, key dạng string bị lộ.

C. “_” (ASCII code hex là 5F)

  • “_” (5F 5F 5F …): Dùng cho các vùng token, id, key dạng text hoặc lẫn ký tự đặc biệt.

  • Dùng “_” để che giấu nội dung, nhưng vẫn giữ nguyên độ dài, hệ thống sẽ không lỗi khi check parse.


D. Ví dụ thực tế khi patch

Giả sử vùng SHA1:

mathematica
8A 34 AF 22 68 7E 6C E1 A1 C2 33 49 48 57 1E 6A 42 E2 D9 94 2F 7A 9B 03 89 57 32 B2 08 F2 62 7D 50 39 A8 15 0C 21 FF 00
  • Bạn patch thành:

bash
30 30 30 30 30 ... (40 lần “30”)
# Tức là “0000000000000000000000000000000000000000” trong ASCII

Giả sử vùng base64:

mathematica
51 57 39 77 62 47 46 30 63 6E 56 79 ... 3D 3D
# QW9wbGF0cnVycnVycGVyMDgxOTU3OTU3ODg1==
  • Patch thành:

mathematica
41 41 41 ... 3D 3D
# AAAAAAAAAAAAAAAA== (giữ nguyên padding “==” ở cuối)

Giả sử vùng token:

r
68 75 61 77 65 69 64 5F 74 6F 6B 65 6E 5F 63 72 63 33 32 3A 39 39 39 39 39 39 39 39
# huaweiid_token_crc32:99999999
  • Patch thành:

markdown
5F 5F 5F ... (tổng đúng số ký tự ban đầu)
# ________________ (toàn dấu gạch dưới)

3. Tại sao không xóa trắng (00) hoặc patch bậy bạ?

  • Nếu bạn patch 00, rất nhiều hệ thống sẽ báo lỗi format, “parse fail”, hoặc thậm chí brick máy!

  • Dùng “0”, “A”, “_” vừa đảm bảo đúng độ dài, vừa không gây lỗi định dạng, vừa “reset” giá trị key, hệ thống sẽ nghĩ đó là vùng chưa đăng ký khóa mới.


4. Tóm tắt quy tắc thực chiến

  • Tìm: Search những pattern phổ biến – giúp “bắt” vùng cần patch nhanh nhất.

  • Patch:

    • SHA1: fake bằng “0”

    • base64: fake bằng “A”, giữ padding “==”

    • token/text: fake bằng “_”

  • Luôn giữ đúng số lượng byte gốc!


Nếu bạn muốn thử thực tế:

  • Lấy file demo, search các pattern trên, patch lại bằng các giá trị này, lưu file mới, load vào máy/box – sẽ thấy máy bị “mất lock”, FRP, Mi Account, v.v.

  • Nếu gặp vùng signature lạ, cũng làm tương tự – patch giữ format, giá trị bất kỳ, miễn đúng độ dài, đúng mã hóa là máy sẽ “pass”.

  • I. Dấu hiệu/chuỗi nên search nhanh theo từng dòng

    1. Huawei ID / Honor ID

    • Keyword nên search:

      • huaweiid, huawei_id, hua_id, id2025, hid_token, crc32, huaweiid_token, huawei_account, HUAWEIID, token_hua

    • Pattern base64:

      • Đôi khi dạng base64 có token “huawei”, nên search cả chuỗi “aHVhd2Vp” (base64 của “huawei”)

    • Khu vực nên scan:

      • persist, super, userdata, cust, metadata, secdata


    2. Oppo ID / Realme ID / OnePlus ID

    • Keyword nên search:

      • oppoid, oppo_id, realmeid, realme_id, oneplusid, oneplus_id, oid, rid, token, authid, accountid, OPPOID, REALMEID, ONEPLUSID, oppo_sec, realme_sec

    • Pattern base64:

      • b3Bwb2lk (base64 của “oppoid”), cmVhbG1laWQ= (“realmeid”), b25lcGx1c2lk (“oneplusid”)

    • Khu vực nên scan:

      • persist, userdata, oppo_custom, vendor, super, metadata


    3. Vivo ID

    • Keyword nên search:

      • vivoid, vivo_id, vid, vivo_token, vivo_sec, vivo_account, accountid, VIVOID

    • Pattern base64:

      • dml2b2lk (base64 “vivoid”)

    • Khu vực nên scan:

      • persist, userdata, super, vendor


    4. Mi Account Xiaomi

    • Keyword nên search:

      • micloud, miaccount, mi_acc, miaccount_token, mi_sec, micloudid, mi_accountid, MiAccount, micloudv3, MiAcc, mi_sec_token, micloud_token

    • Pattern base64:

      • bWljbG91ZA== (base64 “micloud”)

    • Khu vực nên scan:

      • persist, userdata, misc, super, metadata


    5. FRP Google Pixel / Motorola

    • Keyword nên search:

      • frp, frp_flag, frp_lock, google_lock, frp_a15, frp_status, frpstate, FRP

    • Pattern base64:

      • Search các chuỗi base64 dài gần vùng có “frp”, hoặc đoạn có “QWRG…” (nhiều trường hợp Google FRP encode base64 từ “ADFW…”)

    • Khu vực nên scan:

      • metadata, userdata, frp, persist


    6. Generic/Universal cho Android 2024–2025

    • id, token, account, sec, lock, flag, crc32, auth, status

    • Dạng base64: scan toàn file pattern [A-Za-z0-9+/=]{16,}


    II. Script scan tổng hợp cho tất cả các dòng

4/5 - (1 bình chọn)
0 0 đánh giá
Đánh giá bài viết
Theo dõi
Thông báo của
guest
0 Góp ý
Cũ nhất
Mới nhất Được bỏ phiếu nhiều nhất