Xiao-Zhi Zhang

15 papers C 3Journal 9Unranked 3
YearRankTypeTitle / Venue / Authors
2024 J jnl
Biomed. Signal Process. Control.
Xichu Zhang, Xiao-Zhi Zhang, Lijun Ouyang, Chuanbo Qin, Lin Xiao, Dongping Xiong
2024 J jnl
IET Image Process.
Xiao-Zhi Zhang, Liu Zhou, Yaping Wan, Bingo Wing-Kuen Ling, Dongping Xiong
2018 J jnl
IEEE Trans. Signal Process.
Xiao-Zhi Zhang, Bingo Wing-Kuen Ling, Hai Huyen Dam, Kok Lay Teo, Changzhi Wu
2018 J jnl
IET Signal Process.
Xiao-Zhi Zhang, Bingo Wing-Kuen Ling, Ran Tao, Zhijing Yang, Wai Lok Woo, Saeid Sanei, Kok Lay Teo
2017 J jnl
Circuits Syst. Signal Process.
Xiao-Zhi Zhang, Bingo Wing-Kuen Ling, Daniel Pak-Kong Lun, Jiang-Zhong Cao, Qingyun Dai
2017 J jnl
Circuits Syst. Signal Process.
Xiao-Zhi Zhang, Bingo Wing-Kuen Ling, Meilin Wang, Yu Zheng, Chuqi Yang
2017 J jnl
Digit. Signal Process.
Xiao-Zhi Zhang, Bingo Wing-Kuen Ling, C. K. Li, Nixon C. M. Leung
2017 conf
APSIPA
Xiao-Zhi Zhang, Ya Li, Bingo Wing-Kuen Ling, Chao Song, Kok Lay Teo
2016 C conf
ICCE
Xiao-Zhi Zhang, J. Xiao, Bingo Wing-Kuen Ling, C. K. Li, Kim Fung Tsang
2016 C conf
IECON
Shuang Li, Nili Tian, Xiao-Zhi Zhang, Qing Miao, Wei-Chao Kuang, Wing-Kuen Ling
2016 conf
CSNDSP
Qing Liu, Xiao-Zhi Zhang, Wing-Kuen Ling, Meilin Wang, Qingyun Dai
2016 conf
ICIT
Xiao-Zhi Zhang, Ya Li, Bingo Wing-Kuen Ling, Chi-Kong Li
2016 J jnl
Signal Image Video Process.
Nili Tian, Xiao-Zhi Zhang, Bingo Wing-Kuen Ling, Zhijing Yang
2015 J jnl
Digit. Signal Process.
Xiao-Zhi Zhang, Bingo Wing-Kuen Ling, Suba Raman Subramaniam, Apostolos Georgakis
2015 C conf
INDIN
Xiao-Zhi Zhang, Caixia Liu, Bingo Wing-Kuen Ling, Meilin Wang, Lidong Wang, Vera Sau-Fong Chan, Kim Fung Tsang, Kwok Tai Chui, Chung Kit Wu, Faan Hei Hung, Wing Hong Lau
redb/extractors/js_extractors/scripts/js-xray-runner.js
← Index redb/extractors/js_extractors/scripts/js-xray-runner.js javascript
#!/usr/bin/env node
// Bridge between the Python JS pipeline and @nodesecure/js-x-ray.
//
// Usage: node js-xray-runner.js <path-to-js-file>
//   stdout  one JSON object: {"obfuscator": <name|null>, "warnings": [...]}
//   stderr  human-readable error on failure
//   exit 0  analysis ran (the file may still be benign — see "obfuscator")
//   exit 1  the file could not be read or analysed
//
// Each warning is emitted as {kind, value} so the Python side can tag
// supporting signals (encoded-literal, short-identifiers, suspicious-literal,
// unsafe-stmt) without having to mirror js-x-ray's whole schema.
//
// js-x-ray ≥7 ships as an ES module, which CommonJS `require()` cannot load
// from a `.js` script — the dynamic `import()` below is what makes the
// bridge work without renaming the file to `.mjs` or adding `"type":
// "module"` to package.json (which would break tools that still
// `require()` from this directory).

const fs = require("fs");
const path = require("path");

function fail(msg) {
  process.stderr.write(msg + "\n");
  process.exit(1);
}

async function main() {
  const target = process.argv[2];
  if (!target) fail("usage: js-xray-runner.js <file>");

  let source;
  try {
    source = fs.readFileSync(target, "utf8");
  } catch (e) {
    fail(`read failed: ${e.message}`);
  }

  // The legacy `runASTAnalysis` function is deprecated (removed in v8); the
  // current API is the `AstAnalyser` class. Both produce a result with the
  // same `warnings` shape, so the rest of the bridge is unchanged.
  let AstAnalyser;
  try {
    ({ AstAnalyser } = await import("@nodesecure/js-x-ray"));
  } catch (e) {
    fail(`@nodesecure/js-x-ray not installed (run \`npm install\` in ${path.dirname(__filename)}): ${e.message}`);
  }

  // js-x-ray defaults to module-mode parsing, which rejects scripts that
  // (legally) use reserved words as identifiers, top-level `return`, etc.
  // A lot of real-world JS malware is script-style (WScript/HTA bodies,
  // pasted snippets) — retrying in script mode catches those without
  // pulling in a more lenient parser. Both attempts share the same
  // analyser; only the parse mode flips. If both fail, the original error
  // (module-mode) is reported because that's the more informative one for
  // genuinely broken sources.
  let result;
  const analyser = new AstAnalyser();
  let firstErr;
  try {
    result = await analyser.analyse(source, { module: true });
  } catch (e) {
    firstErr = e;
    try {
      result = await analyser.analyse(source, { module: false });
    } catch (e2) {
      fail(`js-x-ray analysis failed: ${firstErr.message}`);
    }
  }

  const warnings = (result.warnings || []).map((w) => ({
    kind: w.kind,
    value: w.value !== undefined ? w.value : null,
  }));

  // js-x-ray flags the obfuscator family in a warning whose kind is
  // "obfuscated-code" and whose value names the family (jsfuck, obfuscator.io,
  // freejsobfuscator, morse, jjencode, ...). Absent => not detected.
  const obfWarning = warnings.find((w) => w.kind === "obfuscated-code");
  const obfuscator = obfWarning ? obfWarning.value : null;

  // js-x-ray runs its own AST internally with a modern parser, so its
  // identifier-length average is the only path the Python pipeline has to
  // that signal on ES2015+ sources — pyjsparser is ES5.1-only and silently
  // drops to 0 the moment it hits destructuring, classes, optional chaining,
  // etc. Surfacing this lets the heuristic's `avg_identifier_length<2`
  // strong signal fire on real obfuscator.io output. `null` when the value
  // is missing or non-numeric (defensive — older js-x-ray builds may differ).
  const idsLengthAvg =
    typeof result.idsLengthAvg === "number" && !Number.isNaN(result.idsLengthAvg)
      ? result.idsLengthAvg
      : null;

  process.stdout.write(JSON.stringify({ obfuscator, warnings, idsLengthAvg }));
}

main().catch((e) => fail(e.message || String(e)));