Omer Can Akgun

19 papers C 5Journal 6Unranked 7
YearRankTypeTitle / Venue / Authors
2021 conf
BioCAS
Emmanouil Kandilakis, Wouter A. Serdijn, Omer Can Akgun
2020 J jnl
IEEE Trans. Biomed. Circuits Syst.
Omer Can Akgun, Kambiz Nanbakhsh, Vasiliki Giagka, Wouter A. Serdijn
2019 conf
BioCAS
Alberto Gancedo, Omer Can Akgun, Wouter A. Serdijn
2019 conf
BioCAS
Omer Can Akgun, Kambiz Nanbakhsh, Vasiliki Giagka, Wouter A. Serdijn
2019 C conf
ISCAS
Omer Can Akgun, Mauro Mangia, Fabio Pareschi, Riccardo Rovatti, Gianluca Setti, Wouter A. Serdijn
2018 C conf
ISCAS
Omer Can Akgun
2013 J jnl
Microprocess. Microsystems
S. M. Yasser Sherazi, Joachim Neves Rodrigues, Omer Can Akgun, Henrik Sjöland, Peter Nilsson
2012 J jnl
IEEE Trans. Biomed. Circuits Syst.
Omer Can Akgun, Joachim Neves Rodrigues, Yusuf Leblebici, Viktor Öwall
2011 C conf
ISCAS
S. M. Yasser Sherazi, Peter Nilsson, Omer Can Akgun, Henrik Sjöland, Joachim Neves Rodrigues
2011 J jnl
IET Comput. Digit. Tech.
Omer Can Akgun, Joachim Neves Rodrigues, Jens Sparsø
2010 C conf
VLSI-SoC
Joachim Neves Rodrigues, Omer Can Akgun, Viktor Öwall
2010 conf
ASYNC
Omer Can Akgun, Joachim Neves Rodrigues, Jens Sparsø
2009 J jnl
Int. J. Circuit Theory Appl.
Omer Can Akgun, Frank K. Gürkaynak, Yusuf Leblebici
2009 conf
PATMOS
Joachim Neves Rodrigues, Omer Can Akgun, Puneet Acharya, Adolfo de la Calle, Yusuf Leblebici, Viktor Öwall
2009
Omer Can Akgun
2008 conf
APCCAS
Thomas Liechti, Armin Tajalli, Omer Can Akgun, Zeynep Toprak Deniz, Yusuf Leblebici
2008 J jnl
J. Low Power Electron.
Omer Can Akgun, Yusuf Leblebici
2007 conf
ECCTD
Omer Can Akgun, Yusuf Leblebici, Eric A. Vittoz
2006 C conf
ISCAS
Omer Can Akgun, Yusuf Leblebici
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)));