Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Repository files navigation

binlore - generate and aggregate info about executables in nix packages

Since binlore is very young and currently has a limited scope, the vision may make a little more sense if I outline what it currently does and why. If you'd like to help improve binlore, see How to help

Why / Motive

I'm building binlore to help resholve decide how likely the executables it finds in shell scripts are to also execute one of their arguments.

This information helps resholve scrutinize these invocations more carefully and require user triage as-needed (without wasting user time on unlikely cases).

What / API (high level)

binlore itself is a Nix API with three main functions:

  • make which builds a derivation that runs a black-box we'll call [analysis] for a single package and outputs a directory with one or more named files containing some or all of the output from that analysis.
  • collect which builds a derivation that depends on and aggregates the output of make for each package in a list. In this case, aggregation means concatenating files with the same name for every package into a single file of the same name.
  • synthesize which (with the aid of a Shell DSL) makes it easy to attach manually-generated lore overrides to a specific package.
  • It'll take some use for norms/patterns to settle, but I tentatively see each file as a "type" or "kind" of lore.

Trying out the API

If you want to contribute to binlore or use binlore in your own project, then you’ll probably want to see what lore binlore produces for particular commands. Here’s how you would get the lore for hello and haskellPackages.hello:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-build -E 'with import <nixpkgs> { }; (callPackage ./binlore.nix { binloreSrc = ./.; }).collect { drvs = [ hello haskellPackages.hello ]; }'/nix/store/...-more-binlore
$ cat result/execerscannot:/nix/store/...-hello-2.12.1/bin/hellocannot:/nix/store/...-hello-1.0.0.2/bin/hello
$ cat result/wrappers
$

In this example, result/wrappers is empty.

How / Analyses

The only [analysis] so far meets resholve's immediate needs. You can find its definition in the loreDev attr in default.nix, but the broad strokes are that it:

Trying out the analyses (low-level)

Sometimes it's enough to see the high-level lore produced by the collect function for a specific package or executable, and other times you'll need to pop open the hood to understand how binlore's YARA rules are leading to a specific result. (Perhaps because it's wrong, or perhaps because binlore just doesn't have rules for a specific language or binary format.)

With the traditional nix commands, you can do something like:

$ git clone https://github.com/abathur/binlore.git
$ cd binlore
$ nix-shell
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Using the experimental CLI you can do something like:

$ nix develop github:abathur/binlore
$ binlore_yara /nix/store/...-diffutils-3.10...executable /nix/store/...-diffutils-3.10/bin/cmpmacho_binary /nix/store/...-diffutils-3.10/bin/cmpbinary /nix/store/...-diffutils-3.10/bin/cmpmacho_cannot_exec /nix/store/...-diffutils-3.10/bin/cmpdecidable /nix/store/...-diffutils-3.10/bin/cmpcannot_exec /nix/store/...-diffutils-3.10/bin/cmpexecutable /nix/store/...-diffutils-3.10/bin/diffmacho_binary /nix/store/...-diffutils-3.10/bin/diffbinary /nix/store/...-diffutils-3.10/bin/diffmacho_execve /nix/store/...-diffutils-3.10/bin/diffexecve /nix/store/...-diffutils-3.10/bin/diffdecidable /nix/store/...-diffutils-3.10/bin/diffcan_exec /nix/store/...-diffutils-3.10/bin/diff

Each line here indicates that a YARA rule of the same name (currently in execers.yar) matched for that path.

Note: You may also want to fork this repo, add the relevant package to big.nix (if it isn't already there), and push it up to github to run the CI process. The CI job will dump this information (and some additional analysis) for all included packages.

Meta

I'm not sure what binlore's long-term relationship to individual analyses will be (or that the current abstractions are right).

  • I suspect there may be utility in having a collection of standardized analyses that people can discover and apply without needing to understand enough to write one. This makes me want to collect them in binlore for now. (But there's no real mechanism yet--I don't want to fall into over-designing this until someone's asking.)
  • But I also realize that needs may be too idiomatic for standardized analyses to ever be a good fit. If it smells like analyses are accumulating with no real re-use (no in-the-clear uses, re-use that almost always entails tweaking/adjusting an existing form, etc.)

Lore Formats

There are currently two "kinds" of lore. In both cases below, the field separator is equivalent to FIELD_SEPARATOR=$':':

  • $out/execers, which has the format: ${verdict}${FIELD_SEPARATOR}${executable_path} where:
    • verdict=can|cannot|might
    • executable_path is whatever path YARA printed for the match
  • $out/wrappers, which has the format ${wrapper_path}${FIELD_SEPARATOR}${wrapped_path} where:
    • wrapper_path is a path identified as a wrapper by YARA
    • wrapped_path is the path that the shell_wrapper yallback and exec_target function in execers.yall pick out of the source of the wrapper

Usage / Examples

For now, at least, resholve's own uses of binlore should serve as a good example of the rough intent and usage:

About

No description, website, or topics provided.

Resources

Stars

11 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages