Good day
Is it possible to adjust the checker for the analysis of .efi files?
Will changing the header of the .efi files to the ELF format help?

Since the BAP 2.0 release is imminent, it would be awesome to port the cwe_checker too.

Hello Sir,

Intalled cwe_checker locally on my macbook, the tool failed to analyze the binary file.
run command:
cwe_checker bin/ls #ls is getton from Ubuntu
or "cwe_checker -c src/config.json bin/ls"
fail info:
thread 'main' panicked at 'Could not read configuration file: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/cwe_checker_lib/src/utils/mod.rs:18:46
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

could you help to check the problem. thank you.

Hi there,
I am very interested in this tool but am having some problems running it. I started off using the docker method and I get the following error:

/tmp > docker run --rm -v /tmp/socat:/input fkiecad/cwe_checker /input
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("unknown variant `ROUND`, expected one of `COPY`, `LOAD`, `STORE`, `PIECE`, `SUBPIECE`, `POPCOUNT`, `INT_EQUAL`, `INT_NOTEQUAL`, `INT_LESS`, `INT_SLESS`, `INT_LESSEQUAL`, `INT_SLESSEQUAL`, `INT_ADD`, `INT_SUB`, `INT_CARRY`, `INT_SCARRY`, `INT_SBORROW`, `INT_XOR`, `INT_AND`, `INT_OR`, `INT_LEFT`, `INT_RIGHT`, `INT_SRIGHT`, `INT_MULT`, `INT_DIV`, `INT_REM`, `INT_SDIV`, `INT_SREM`, `BOOL_XOR`, `BOOL_AND`, `BOOL_OR`, `FLOAT_EQUAL`, `FLOAT_NOTEQUAL`, `FLOAT_LESS`, `FLOAT_LESSEQUAL`, `FLOAT_ADD`, `FLOAT_SUB`, `FLOAT_MULT`, `FLOAT_DIV`, `INT_NEGATE`, `INT_2COMP`, `BOOL_NEGATE`, `FLOAT_NEG`, `FLOAT_ABS`, `FLOAT_SQRT`, `FLOAT_CEIL`, `FLOAT_FLOOR`, `FLOAT_ROUND`, `FLOAT_NAN`, `INT_ZEXT`, `INT_SEXT`, `INT2FLOAT`, `FLOAT2FLOAT`, `TRUNC`", line: 45658, column: 45)', caller/src/main.rs:277:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The file type is a 32-bit Linux ELF for ARM:

/tmp > file /tmp/socat
/tmp/socat: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=5cfa8023dbbef69e608816f9967e981c94910f20, stripped

I also tried building cwe_checker locally and running from there, but I get the same error. I tried digging in to see what was happening under the hood, and I see cwe_checker is calling the PCodeExtractor.java file. So I create a new project in Ghidra and run the PCodeExtractor.java file directly but I get the following error:

Index 0 out of bounds for length 0
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
	at PcodeExtractor.run(PcodeExtractor.java:58)
	at ghidra.app.script.GhidraScript.executeNormal(GhidraScript.java:379)
	at ghidra.app.script.GhidraScript.doExecute(GhidraScript.java:234)
	at ghidra.app.script.GhidraScript.execute(GhidraScript.java:212)
	at ghidra.app.plugin.core.script.RunScriptTask.run(RunScriptTask.java:47)
	at ghidra.util.task.Task.monitoredRun(Task.java:124)
	at ghidra.util.task.TaskRunner.lambda$startTaskThread$0(TaskRunner.java:104)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

---------------------------------------------------
Build Date: 2020-Dec-29 1701 EST
Ghidra Version: 9.2.2
Java Home: /Library/Java/JavaVirtualMachines/jdk-11.0.7.jdk/Contents/Home
JVM Version: Oracle Corporation 11.0.7
OS: Mac OS X 10.16 x86_64
Workstation: <redacted>

I get the same error using Mac OSX and Linux Mint. Any clue why I can't run cwe_checker?

$ sudo docker run --rm -v/path/to/binary_file:/path/to fkiecad/cwe_checker /path/to -p=CWE78,CWE134,CWE190,CWE215,CWE243,CWE332,CWE367,CWE426,CWE467,CWE476,CWE560,CWE676,CWE782,Memory -j -q -out=f.json
error: Invalid value for '--config ': No such file or directory (os error 2)

When I try to run a docker image after build or run a container, every time have an error:

opam: opam: Missing argument.
      Usage: opam config [OPTION]... exec [--] COMMAND [ARG]...      

OS: Ubuntu 18.04

When I download the last release version , How do I run it with ida pro?
I read README.md but still not understand
I tried to run cwe_checker/CweCheckerParser.py , but Ida Pro 7.4 did not give me any results

cwe_checker 0.5.0
Execution of Ghidra plugin failed: Process was terminated.

at ghidra.app.util.headless.HeadlessAnalyzer.processWithImport(HeadlessAnalyzer.java:1753)

where is error:

https://github.com/NationalSecurityAgency/ghidra/blob/436bb4873e8571b87a4d785bb828d9bf772b4867/Ghidra/Features/Base/src/main/java/ghidra/app/util/headless/HeadlessAnalyzer.java#L1753
cmd:
docker run -it --rm -v /path/to/bind:/bind fkiecad/cwe_checker:stable -j -o /bind/output.json -p CWE78,CWE134,CWE190,CWE215,CWE243,CWE332,CWE367,CWE426,CWE467,CWE476,CWE560,CWE676,CWE782,Memory /bind/binary
why error?

When running cwe_checker on the cross-compiled 64 bit PE target cwe_416_x64_mingw32-gcc.out or the 32 bit ELF target cwe_416_x86_gcc.out we get some warnings but not any for CWE416. Some amateurish attempts at debugging on my part seem to indicate that issue lies on line 119 of src/cwe_checker_lib/src/analysis/pointer_inference/object_list/cwe_helpers.rs. Here the line:

let ids: Vec<AbstractIdentifier> = object_pointer.referenced_ids().cloned().collect();

returns a vector of length one when the 64 bit ELF target is supplied (cwe_416_x64_gcc.out) but a vector of length zero when we supply the 64 bit PE target or 32 bit ELF target. I believe this vector is supposed to cotain the abstract memory objects the freed pointer points at and so this explains why the free is not properly marking memory as dangling.

when I want to install cwe_checker using opam install cwe_checker , it display:[ERROR] No package named cwe_checker found, why?

File : ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.7.0, stripped

no signatures for specified compiler and architecture Failed to create a project: no entry Backtrace: Raised at file "src/error.ml" (inlined), line 9, characters 14-30 Called from file "src/or_error.ml", line 74, characters 17-32 Called from file "lib/bap/bap_project.ml" (inlined), line 192, characters 15-29 Called from file "lib/bap/bap_project.ml" (inlined), line 193, characters 35-41 Called from file "lib/bap/bap_project.ml", line 272, characters 19-36 Called from file "src/or_error.ml", line 66, characters 9-15

Due to recent changes to this docker image, the previous method of running this tool is now failing with this error:

error: Invalid value for '<binary>': /input is not a file.

To make matters worse, there is no history of tags on dockerhub to use a previous working version.

I found a workaround by overriding the entrypoint. Trickier to do within a Gitlab (gitlab-ci.yml) pipeline but also possible.
I also found that cwe_checker no longer works if called within docker and the full path must now be specified (/home/cwe/cwe_checker)

It would be nice if:
1- Changes were not breaking or backward incompatible.
2- If they have to be, then at least a previous tag be made available to maintain historical behavior.

However, since I wish to use the latest iteration of this tool, it would be nice to be able to use it consistently.

For context, this is my current gitlab job specification:

.cwechecker: &cwechecker
  stage: cwechecker
  image: fkiecad/cwe_checker:stable
  allow_failure: true
  before_script:
    - <removed>
  script:
    - set +e
    - cd xxx/rootfs/
    - for filename in $(cut -d':' -f1 <<< "$(find . -type f -exec file {} + | grep ELF)") ; do echo "#######" ; ls $filename ; echo "#######" ; cwe_checker "$filename" ; done | tee cwechecker-results.txt
    - cd -
    - cp xxx/rootfs/cwechecker-results.txt output/
    - set -e
  artifacts:
    name: <removed>
    paths:
      - output/cwechecker-results.txt
    expire_in: 3 days

For completeness, the workaround was adding:

entrypoint: [""]

under the line with the image: keyword

$ sudo docker run --rm -v /path/to/binary_file:/path/to fkiecad/cwe_checker path/to -p=CWE78,CWE134,CWE190,CWE215,CWE243,CWE332,CWE367,CWE426,CWE467,CWE476,CWE560,CWE676,CWE782,Memory -j -q -out=f.json
thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', src/cwe_checker_lib/src/utils/log.rs:192:43
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Hello!

On line 83 of src/cwe_checker_lib/src/intermediate_representation/bitvector.rs within the un_op function the BoolNegate case is handled by the following code:

if self.is_zero() {
    Ok(Bitvector::from_u8(1))
} else {
    Ok(Bitvector::from_u8(0))
}

Whilst this should work if the input is a correctly managed boolean (in which all the bits are zero except for the LSB which represents the boolean value), this function will behave incorrectly on less well-formed inputs. For example the negation of 0b11111110 should be true however the above code will return false. From the P-code reference:

This is a logical negate operator, where we assume input0 and output are boolean values. It puts the logical complement of input0, treated as a single bit, into output. Both input0 and output are size 1. Boolean values are implemented with a full byte, but are still considered to only support a value of true or false.

cwe_checker/cwe_checker_to_ida/CweCheckerParser.py

line 13

"CWE-782" should be "CWE782"

line 127

    @staticmethod
    def _parse_cwe782(warning):
        warning.address = warning.warning.spit("(")[1].split(")")[0].strip()
        return warning

s/spit/split/

Hi,
It seems that the cwe_checker_to_ida.py script fails to properly generate output for IDA, when a valid JSON input file is supplied to the script. I have tested both latest and stable releases.

The result is the same regardless of provided json input, generated from different binaries.
Ghidra v10.0 is installed on the system running the script. The json file loads fine in Ghidra and the plugin correctly highlights the findings, so it is not in a corrupt state.

Am I missing something?

This seems to be similar to a previously fixed and closed issue:
#34

BAP sometimes fails to resolve calls to functions in the dynamic symbols table of a binary. Since many checks rely on these calls getting resolved by BAP, we should detect these cases and print a warning for the user. Right now, the user will simply see no output from most checks in these cases, which is indistinguishable from those cases, where everything worked and there were simply no CWEs found.

As a temporary workaround, one can detect these cases by running bap BINARY -d | grep call. If this doesn't print any explicit calls to dynamic symbols, BAP failed to resolve these calls.

When I run
docker run -v "$PWD"/test:/tmp/test fkiecad/cwe_checker_travis_docker_image bap /tmp/test --pass=cwe-checker

The error shows:
Failed to find pass: cwe-checker

While attempting to run cwe-checker for CWE415 against one of the individually built Juliet Test Suite for C/C++ Version 1.3 test cases, I am unable to get the output directed to a file using the -out option.

I am running the following versions:

• cwe-checker 0.3-dev
• bap 2.1.0-alpha+5937def

See attached screenshot for behavior.

thread 'main' panicked at 'called Result::unwrap() on an Err value: Error("missing field string_symbols", line: 0, column: 0)', src/cwe_checker_lib/src/checkers/cwe_78.rs:104:69
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

rather, this is due to the fact that the binary is stripped

Right now the handling of calling conventions for PE files is wrong for most analyses:

The PointerInference (and most other analyses) assume that internal function calls adhere to a standard calling convention, which is either named __stdcall or __cdecl (this happens in the Project::get_standard_calling_convention method). But for example in the x64-PE acceptance test binaries the only known calling conventions are __fastcall and __thiscall. So we either have to choose the right one as a standard calling convention for PE binaries or we have guess the correct one (or let Ghidra guess for us, if Ghidra provides this information).

Note: There are probably some more bugs with respect to the handling of PE calling conventions.

Right now the makefile and the actual program use different methods for determining the folder where configuration files should be located. This works OK on Linux, but it fails badly on non-Linux systems (see discussion in #141).

Note that we have not decided yet, whether we want to officially support any OS other than Linux. But right now we do not depend on anything Linux-specific, so we should investigate whether supporting Windows and MacOS is feasible.

Using the latest Master branch, Docker image built via the install.sh script.

BAP fails the cwe_checker pass against many targets with one of two issues. First was already reported here #61 and is being handled as a BAP bug.

The second error is listed below. It seems to trigger on x86-32 targets from my limited-sample testing. In particular it was observed on these three file-type targets.

ELF 32-bit LSB executable, intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.8, stripped
ELF 32-bit LSB executable, intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.8, not stripped
PE32 executable (console) Intel 80386, for MS Windows

pass "cwe-checker" failed in runtime with ("[Map.add_exn] got key already present"
(key 7381610))
Backtrace:
Raised at file "src/error.ml" (inlined), line 9, characters 14-30
Called from file "src/error.ml", line 11, characters 19-40
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 226, characters 10-90
Called from file "src/map.ml", line 226, characters 10-90
Called from file "src/map.ml", line 226, characters 10-90
Called from file "src/map.ml", line 226, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 226, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml", line 231, characters 10-90
Called from file "src/map.ml" (inlined), line 237, characters 4-90
Called from file "src/map.ml", line 1249, characters 11-140
Called from file "lib/bap_types/bap_ir.ml", line 1378, characters 6-89
Called from file "src/main.ml", line 98, characters 24-68
Called from file "src/main.ml", line 152, characters 12-35
Called from file "lib/bap/bap_project.ml", line 444, characters 56-59
Called from file "lib/bap/bap_project.ml", line 428, characters 20-32
Re-raised at file "lib/bap/bap_project.ml", line 433, characters 6-15
Called from file "lib/bap/bap_project.ml", line 469, characters 4-20
Called from file "lib/bap/bap_project.ml", line 480, characters 10-24

The error is consistent across all failing targets with the exception of the key number which is consistent on each run against a specific target.

And here is a sample invocation of cwe_checker as I am using it against one on one of the Juliet test binaries which is experiencing this issue.
sudo docker run --rm -v ~/CWE476.exe:/tmp/input cwe-checker bap /tmp/input --pass=cwe-checker

Please let me know if there's any obvious cause to this I'm missing or any additional information about the environment that would be valuable.

I tried to run the docker image on the botan cli executable. Unfortunately, after running for a while it panics with

$ docker run --rm -v $(pwd)/botan:/input fkiecad/cwe_checker /input
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("missing field `tid`", line: 80734887, column: 9)', src/caller/src/main.rs:300:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Checking a very simple hello-world example works fine, though.

I'm on Manjaro Linux with kernel 5.10.23-1.

I am trying to use it for a project. Installed it through the docker and I cant get it to work..
Also i cant seem to install it locally.
error: Invalid value for '': No such file or directory (os error 2) Tried multiple way... May be my syntax is wrong Can u please give me some ideas

Following the test/artificial_samples/README.md I compiled the Docker image.

...
COMMIT cross_compiling
--> a5ed18c91f4
Successfully tagged localhost/cross_compiling:latest
a5ed18c91f4998ace529c4b4475692faf2ec6a9cdc60e47e4c7a01e6faad9619
cwe_checker/test/artificial_samples on  master took 5m 27s 

But when I try to run the cross build itself, it fails with the following error:

error: unable to open output file 'build/arrays.c_aarch64_clang.o': 'Permission denied'

See the full log here:

[i] ℤ podman run --rm -v $(pwd)/build:/home/cwe/artificial_samples/build cross_compiling sudo python3 -m SCons                                                                                                                    14:39:25 
Error: statfs /home/user/cwe_checker/test/artificial_samples/build: no such file or directory
cwe_checker/test/artificial_samples on  master 
[i] ℤ mkdir build                                                                                                                                                                                                                 14:41:51 
cwe_checker/test/artificial_samples on  master 
[i] ℤ podman run --rm -v $(pwd)/build:/home/cwe/artificial_samples/build cross_compiling sudo python3 -m SCons                                                                                                                    14:42:10 
scons: Reading SConscript files ...
Building for architecture x64
Building for architecture x86
Skipping architecture x86 for cwe_782.c
Skipping architecture x86 for cwe_782.c
Skipping architecture x86 for cwe_782.c
Building for architecture arm
Skipping architecture arm for cwe_782.c
Skipping architecture arm for cwe_782.c
Building for architecture aarch64
Skipping architecture aarch64 for cwe_782.c
Skipping architecture aarch64 for cwe_782.c
Building for architecture mips
Skipping architecture mips for cwe_782.c
Skipping architecture mips for cwe_782.c
Building for architecture mipsel
Skipping architecture mipsel for cwe_782.c
Skipping architecture mipsel for cwe_782.c
Building for architecture mips64
Skipping architecture mips64 for cwe_782.c
Skipping architecture mips64 for cwe_782.c
Building for architecture mips64el
Skipping architecture mips64el for cwe_782.c
Skipping architecture mips64el for cwe_782.c
Building for architecture ppc
Skipping architecture ppc for cwe_782.c
Building for architecture ppc64
Skipping architecture ppc64 for cwe_782.c
Skipping architecture ppc64 for cwe_782.c
Building for architecture ppc64le
Skipping architecture ppc64le for cwe_782.c
Skipping architecture ppc64le for cwe_782.c
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build
clang -o build/arrays.c_aarch64_clang.o -c -target aarch64-linux-gnu -g -fno-stack-protector -std=c11 -O0 arrays.c
error: unable to open output file 'build/arrays.c_aarch64_clang.o': 'Permission denied'
1 error generated.
scons: *** [build/arrays.c_aarch64_clang.o] Error 1
scons: building terminated because of errors.

Hi,

1. Maybe it's because the stm32f407vg.json path is wrong, how to set the path?
2. Is it possible to analyze .hex files?

➜  ~ docker run --rm -v ~/test_sample.bin:/input fkiecad/cwe_checker --bare-metal-config /cwe_checker/bare_metal/stm32f407vg.json /input
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/caller/src/main.rs:115:81
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'main' panicked at 'called Option::unwrap() on a None value', src/cwe_checker_lib/src/analysis/graph.rs:312:85
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Currently there is some basic code in cwe_checker, but it doesn't use Primus taint tracking features. See, for example:

• BAP/plugins/primus_taint
• BAP/plugins/primus_propagate_taint

I see that checkers/cwe_476.ml has some code for working with tainting but it's one checker-specific and too basic. My suggestion is:

• Use Primus Taint plugins
• Make an abstract taint interface that would be available for all checker authors.

i fixed the cwe_checker_to_ida code how can i pass sources?

Generated script has got only two strings:

import sark
import idaapi

I think after refactoring of logging the output hasn't got "WARN" string so cwe_checker_to_ida.py cannot normal generate an IDA annotate script.

Apologies if I'm misunderstanding the intended behaviour of default nodes in fixed point computations, but it seems they're not being fully utilised.

Whilst get_node_value (here on line 171 of src/cwe_checker_lib/src/analysis/fixpoint.rs) correctly returns the default_value when a node has no specified value, the update_edge function does not refer to it but instead directly looks to the node_values, ignoring the update if no value is specified. (here on line 204 of src/cwe_checker_lib/src/analysis/fixpoint.rs)

Thus the default_value is used when communicating the results of nodes for which no value has been calculated externally, but not when calculating the results of nodes that have no value yet internally. Is this intended?

could you please let me know what will be the actual command . I have tried with below but I am getting error .

my firmware bin file in this path = ~/Desktop/MobileProject My bin file name _demo_4.9.8.501.bin.extracted

sudo docker run --rm -v ~/Desktop/MobileProject:/input fkiecad/cwe_checker /input 126 ⨯
[sudo] password for kali:
error: Invalid value for '': /input is not a file.

Even trying to install locally
cwe_checker BINARY - Not working

Request your help

Hello! I'm running an assessment on a binary named "Banload" on a Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz 16GB RAM VirtualBox VM:

5MB e5cb86789b8770b8c2fa35f67bbd48b4cd305217f8bb05d37aa437718c076042 binary at https://github.com/InQuest/malware-samples/tree/master/2019-05-Banload

The command I used was:
cwe_checker /tmp/input/e5cb86789b8770b8c2fa35f67bbd48b4cd305217f8bb05d37aa437718c076042

The assessment does not end, it's been running for a few days, and the assessment does not slow down or hang, only continues.

Could not find a means for detecting "when" the assessment may be given up, and stopped. I was curious if you came by such a condition before and/or how you would handle it.

I have a Debian box running on WSL2 and I have gotten Ghidra and Rust installed without issue. However when running CWE checker, I run into the following permissions issue:

thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', caller/src/main.rs:262:10 stack backtrace: 0: 0x563b08fc1ef0 - std::backtrace_rs::backtrace::libunwind::trace::h04d12fdcddff82aa at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/../../backtrace/src/backtrace/libunwind.rs:100:5 1: 0x563b08fc1ef0 - std::backtrace_rs::backtrace::trace_unsynchronized::h1459b974b6fbe5e1 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x563b08fc1ef0 - std::sys_common::backtrace::_print_fmt::h9b8396a669123d95 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/sys_common/backtrace.rs:67:5 3: 0x563b08fc1ef0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he009dcaaa75eed60 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/sys_common/backtrace.rs:46:22 4: 0x563b08fe776c - core::fmt::write::h77b4746b0dea1dd3 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/fmt/mod.rs:1078:17 5: 0x563b08fbe3a2 - std::io::Write::write_fmt::heb7e50902e98831c at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/io/mod.rs:1518:15 6: 0x563b08fc4465 - std::sys_common::backtrace::_print::h2d880c9e69a21be9 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/sys_common/backtrace.rs:49:5 7: 0x563b08fc4465 - std::sys_common::backtrace::print::h5f02b1bb49f36879 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/sys_common/backtrace.rs:36:9 8: 0x563b08fc4465 - std::panicking::default_hook::{{closure}}::h658e288a7a809b29 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:208:50 9: 0x563b08fc4108 - std::panicking::default_hook::hb52d73f0da9a4bb8 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:227:9 10: 0x563b08fc4c01 - std::panicking::rust_panic_with_hook::hfe7e1c684e3e6462 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:593:17 11: 0x563b08fc4747 - std::panicking::begin_panic_handler::{{closure}}::h42939e004b32765c at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:499:13 12: 0x563b08fc23ac - std::sys_common::backtrace::__rust_end_short_backtrace::h9d2070f7bf9fd56c at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/sys_common/backtrace.rs:141:18 13: 0x563b08fc46a9 - rust_begin_unwind at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:495:5 14: 0x563b08fe5921 - core::panicking::panic_fmt::ha0bb065d9a260792 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/panicking.rs:92:14 15: 0x563b08fe5743 - core::option::expect_none_failed::h7e1dd0a94971eb61 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/option.rs:1268:5 16: 0x563b08e5d99d - cwe_checker::run_with_ghidra::hefc12dba33663939 17: 0x563b08e5b1e8 - cwe_checker::main::h16e80103ba1c8ae3 18: 0x563b08e4d283 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf02e4990abdd83b7 19: 0x563b08e4d299 - std::rt::lang_start::{{closure}}::hb83bf57cf898bc11 20: 0x563b08fc5027 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h57e2a071d427b24c at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/ops/function.rs:259:13 21: 0x563b08fc5027 - std::panicking::try::do_call::h81cbbe0c3b30a28e at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:381:40 22: 0x563b08fc5027 - std::panicking::try::hbeeb95b4e1f0a876 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:345:19 23: 0x563b08fc5027 - std::panic::catch_unwind::h59c48ccb40a0bf20 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:396:14 24: 0x563b08fc5027 - std::rt::lang_start_internal::ha53ab63f88fee728 at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/rt.rs:51:25 25: 0x563b08e5e662 - main 26: 0x7f6a3f4cc09b - __libc_start_main 27: 0x563b08e1e0aa - _start 28: 0x0 - <unknown>

Trying to figure out where exactly it is running into a permissions issue, but this being my first time working with Rust, the trace is a bit cryptic. Any assistance would be greatly appreciated!

This is more a BAP issue, of course, but let's discuss it here, on your side. I've noticed, that you guys are parsing incidents and incident location observations. I understand your motivation, as incidents are defined locally in a plugin and there is no programmatical interface to this observation. Of course, incidents should be published and an interface to them should be provided. So in the future, if you need any functionality in BAP, please do not hesitate to create an issue with a request, or just submit a PR, if you think it will be faster. It is much easier for us to be reactive (i.e., provide the necessary functionality on demand), rather than being proactive (guess what is needed by the community right now and what can be implemented later). The former is engineering the latter is the art :)

Now, back to the incidents, I'm currently working on improving the incidents facility, mostly on deduplication (as we have too many incidents that are somehow instances of the same problem). I don't want to break any existing interfaces (even the textual representation, so no worries here) and I'm introducing a few new observations, namely, incidence-new-class, incidence-new-instance, incidence-new-representative. In short, all incidence will be now grouped by their locality class, so that closely related instances could be processed in one go. The number of incidence reports will remain the same, but now they will be grouped. Also, each class will have a representative, which is the incidence that subsumes all other incidences. The representative will be updated every time a better candidate is found. Below is the excerpt from the current design documentation, if you have any suggestions or requirements, please feel free to share, while I'm still on it. I will provide a library interface to incidents (and in the future, I will probably provide a plugin that will process incidents). Once this interface is provided, for robustness, I would recommend you switching on the library interface, instead of parsing. Agreed?

 Each incident is represented by its name and a tuple of
 locations. Each location is represented as a trace. It is not
 requred, in general, that all traces that denote locations of an
 incident should belong to the same path of execution (i.e.,
 traces could easily be disjoint). The last (the most recent)
 point of the trace is called the _endpoint_ or just the location,
 when it is obvious from the context that we mean only the
 endpoint of the trace.

 Incidents of the same name are partitioned into locality classes,
 so each incident belongs to one and only one class. We say that
 an incident [i] subsumes an incident [j] iff the endpoint of each
 location in [j] is is in the trace of a corresponding location in
 [i].

 Two incidents belong to the same class, if one the incidents
 subsumes another. Of the set of incidents that belong to the same
 class, an incident that subsumes all other incidents is selected
 as a representative of the class. Note, that there could be more
 than one incidents, as they may have equal locations, which
 differ only in machine identifiers, which are not considered in
 the substring relation.


 When an incident is reported it either belongs to an existing
 class or starts its own class.

 When an incident is an instance of an existing class <cls>, then
 we make an observation:
 [(incident-new-instance <name> <cls> <p1> ... <pM>)]

 When an incident is not a member of any class a new class is
 created and an observation is made:

 [(incident-new-class <name> <cls> <p1> ... <pM>)].

 When a newly discovered instance of a class is selected as a new
 representative, in addition to the new-instance observation  we
 also make an observation

 [(incident-new-representative <name> <cls> <p1> ... <pM>)]

Also, subscribing @gitoleg on this discussion :)

I am using fkiecad/cwe_checker:stable and noticed recently that scans are taking around a minute for each binary file.
I have about 450 files to scan in my rootfs and this adds up to several hours which is not feasible.
I am wondering if it has always taken this long or if this was due to a recent change.
I'm also wondering if there is a way to speed up scans especially when you have a folder full of binaries that you want to go through.

Ideally, the cwe_checker command would accept a folder and scan it internally for binaries and provide a single report file rather than having to come up with a script that iterates through files in a folder, find out which ones are executable binaries and feed them to cwe_checker sequentially and figure out how to sort the std output into a single usable log file.

docker run -v $(pwd):/frak -it --entrypoint /bin/bash a0dab8d38a7a
cwe@f45dbfc86557:/frak$ time /home/cwe/cwe_checker ./rg_rootfs_usr/sbin/lsof
...
real	1m11.029s
user	2m2.363s
sys	0m5.199s

upload firmware and scan, there are many errors in the terminal like this:
[cwe_checker][ERROR]: cwe_checker execution failed: Execution of Ghidra plugin failed: Process was terminated.
ERROR REPORT: Import failed for file: /input (HeadlessAnalyzer)

Hi, all

I followed the https://fkie-cad.github.io/cwe_checker/doc/html/cwe_checker/index.html#ToolIntegration to integrate cwe-checker into ida pro.
But the command line error confused me.

$ bap xxx.so --pass=cwe-checker --cwe-checker-json --cwe-checker-out=cwe_hits.json
cwe-checker: unknown option `--json'.
             unknown option `--out'.
Usage: cwe-checker [OPTION]...
Try `cwe-checker --help' for more information.

Hello,

I've attached some binaries in a zip file that, when analyzed with cwe_checker, cause a failure for some reason or another. These binaries are taken from a Kali Linux 2021.2 image. I disassembled each file in Ghidra to ensure that wasn't causing an issue. I will go through the output of cwe_checker for each file below.

Here are the binaries.

tigerdeep

docker run --rm -v C:\Users\Andrew\Repositories\FailToRun\tigerdeep:/input fkiecad/cwe_checker:stable /input
thread 'main' panicked at 'Error while generating runtime memory image: type is too big (1879047925) for 244128', src/caller/src/main.rs:122:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

xfwm4

docker run --rm -v C:\Users\Andrew\Repositories\FailToRun\xfwm4:/input fkiecad/cwe_checker:stable /input
thread 'main' panicked at 'Error while generating runtime memory image: Malformed entity: Section 0 size (0) + offset (4294967296) is out of bounds. Overflowed: false', src/caller/src/main.rs:122:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

cherrytree

I am not an expert in Ghidra or disassembly in general, but I don't get any error popups when I disassemble this binary in Ghidra. I do see occurrences of 'Error [Bad Instruction]', which could certainly be an issue.

docker run --rm -v C:\Users\Andrew\Repositories\FailToRun\cherrytree:/input fkiecad/cwe_checker:stable /input
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/cwe_checker_lib/src/pcode/expressions.rs:31:34
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

tmux
There are occurrences of 'Error [Bad Instruction]' when disassembling this binary as well.

docker run --rm -v C:\Users\Andrew\Repositories\FailToRun\tmux:/input fkiecad/cwe_checker:stable /input
thread 'main' panicked at 'Error while generating runtime memory image: Malformed entity: Section 0 size (1039382085632) + offset (1) is out of bounds. Overflowed: false', src/caller/src/main.rs:122:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Bash
I encounter an error when importing this file into Ghidra which is almost certainly why cwe_checker fails to run. I know this isn't an issue in cwe_checker so there is no need to worry about this, but I've included this file because I have no idea why this would be the case and would appreciate any thoughts on why it might be happening.

PS C:\Users\Andrew\Repositories\FailToRun> docker run --rm -v C:\Users\Andrew\Repositories\FailToRun\bash:/input fkiecad/cwe_checker:stable /input
Execution of Ghidra plugin failed: Process was terminated.
ERROR REPORT: Import failed for file: /input (HeadlessAnalyzer)

btrfs-image
This binary also fails to be analyzed in Ghidra due to a '/ by zero' issue. Again, I know this isn't an issue with cwe_checker, but I would appreciate any ideas on why it would happen.

docker run --rm -v C:\Users\Andrew\Repositories\FailToRun\btrfs-image:/input fkiecad/cwe_checker:stable /input
thread 'main' panicked at 'Error while generating runtime memory image: Malformed entity: Section 0 size (1693539964551168) + offset (1129576398848) is out of bounds. Overflowed: false', src/caller/src/main.rs:122:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

you are planning to do support for PE, DEX, MATH-O, COFF, BINARY?
if not, what pieces of code are responsible for mapping the binar and extracting instructions?
which interfaces can be overridden, responsible for working with the file format?

I have compiled the Juliet 1.3 C/C++ test suite as both a Windows executable and Ubuntu 16.04 ELF and ran BAP w/cwe_checker against both. I am using the fkiecad/cwe_checker container image from docker hub.

Neither executable assessment completes correctly. The Win10 EXE assessment produces the error: 'Fatal error: out of memory.' after ~1 minute, and the ELF assessment never returns, with no output from either standard out or err. I have attached archives of the two executables to this issue ticket.

Win10 EXE: Testcases.zip
Ubuntu 16.04 ELF: Juliet1.zip

I have had success with assessment of smaller executables using the same configuration and methodology.

I get a lot of these type of errors when analyzing ARM 32 binaries cross compiled for a Broadcom type chipset. I navigate to my cross-compiled root file system and run this:

$docker run -it -v `pwd`:/opt fkiecad/cwe_checker /bin/bash

bap@ca1c05ffa64c:~/cwe_checker$ cwe_checker --version
0.3-dev
bap@ca1c05ffa64c:~/cwe_checker$ file /opt/ot-cli
/opt/ot-cli: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.16, stripped
bap@ca1c05ffa64c:~/cwe_checker$ cwe_checker /opt/ot-cli
INFO: Using standard configuration...
failed to build a project: Tag_sexp
validation errors
view must not be empty
value 0x57A23:32u < bound 0x57A24:32u

Backtrace:
Raised at file "src/error.ml" (inlined), line 9, characters 14-30
Called from file "src/or_error.ml", line 72, characters 17-32
Called from file "lib/bap_disasm/bap_disasm_driver.ml", line 470, characters 34-50
Called from file "lib/monads/monads_monad.ml", line 1010, characters 60-63
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1010, characters 38-42
Called from file "lib/monads/monads_monad.ml" (inlined), line 1005, characters 29-34
Called from file "lib/monads/monads_monad.ml", line 1020, characters 21-27
Called from file "lib/knowledge/bap_knowledge.ml", line 2671, characters 10-45
Called from file "lib/bap_types/bap_toplevel.ml", line 54, characters 8-38
Called from file "lib/bap_types/bap_toplevel.ml", line 59, characters 2-15
Called from file "lib/bap/bap_project.ml", line 51, characters 6-130
Called from file "lib/bap/bap_project.ml", line 254, characters 25-51
Called from file "lib/bap/bap_project.ml", line 280, characters 12-47
Called from file "src/or_error.ml", line 64, characters 9-15

I see this error with any binary linked to busybox. I also noticed that files with no symbols return this error. Does this mean that cwe_checker only works with binaries that have not been stripped of symbols?

The documentation claims that the system only supports ELF binaries.

It would be very useful to me if the system supported PE files.

I noticed you have a plugin for Ghidra, but it is not the only one FOSS tool available.
Rizin is a highly-portable cross-platform reverse engineering framework and a toolkit without dependencies. It has support for analyzing binaries, disassembling code, debugging programs, attaching to remote GDB/LLDB, WinDbg servers, rich plugin system (see rz-pm), and integration with various decompilers. For example, ghidra decompiler plugin - rz-ghidra. It is actively developed and can be easily integrated in various open source and commercial products.

For documentation on writing plugins for rizin see Scripting and Plugins Rizin Book chapters.

Cutter is a crossplatform Qt/C++ GUI frontend to rizin:

For documentation on writing plugins for Cutter see the official tutorial and the curated list of various popular plugins.

support kernel modules and vmlinux scan

Hello, while running cwe_checker I noticed that I seem to get different results with each run. I'm unsure of what the cause could be.

I've included an example of what is happening. Below you can see two calls to run cwe_checker on the same file, but I receive different results both times.

Is this intended behavior? What could be causing this?

PS C:...> docker run --rm -v C:\...busybox-1.30.1_lite_busybox_unstripped_x86_64:/input fkiecad/cwe_checker:latest --quiet /input
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ad4 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00405762 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00405888 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0041824a may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0040f1ee may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b509 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004082a8 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00404466 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0041afea may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00448201 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004271dd may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0040cdbb may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440acd may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004270dc may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004058ae may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b4c9 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0040e875 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0044cd50 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b461 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004138b7 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042d305 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004147e8 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0044f094 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00408827 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 004311a6 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004058db may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00427beb may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004087f9 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00405836 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004047da may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 004182b3 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00427bfa may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0040e8a1 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00408292 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00408820 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004059db may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00445940 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00408845 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ac6 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00403cc0 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00404472 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00416bb2 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b4b5 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0044f105 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 004155d5 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0044594c may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00408852 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0044f16b may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b487 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042e9c8 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ac0 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00417399 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ae2 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00405904 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004176a3 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440adb may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0040f113 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004058bd may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042ae3c may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0040eb77 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042d277 may be out of bounds


PS C:\...> docker run --rm -v C:\...busybox-1.30.1_lite_busybox_unstripped_x86_64:/input fkiecad/cwe_checker:latest --quiet /input
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00404472 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00448201 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0044f105 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00408827 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0040f1ee may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b4b5 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00408852 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00408292 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00417399 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ac0 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004176a3 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ac6 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042d277 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00427bfa may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00408845 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042ae3c may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004147e8 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0040e875 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004138b7 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ad4 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0044f16b may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00403cc0 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0044f094 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042d305 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 004182b3 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 004311a6 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b509 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440acd may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0040cdbb may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00408820 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0044594c may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0040e8a1 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004087f9 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0040eb77 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0040f113 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b4bd may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440adb may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004047da may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b4c9 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004271dd may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004082a8 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042e9c8 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0044cd50 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 004270dc may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00440ae2 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00416bb2 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 0041824a may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b487 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00404466 may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 00427beb may be out of bounds
[CWE125] (0.2) (Out-of-bounds Read) Memory load at 0042b461 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 004155d5 may be out of bounds
[CWE787] (0.2) (Out-of-bounds Write) Memory write at 00445940 may be out of bounds

Refer to the README and run Docker with the following command.

But I get an error. do you know about this
➜ ~ sudo docker run --rm -v :/input fkiecad/cwe_checker:stable /input

Execution of Ghidra plugin failed: Process was terminated.
INFO REPORT: Save succeeded for file: /input (HeadlessAnalyzer)
INFO REPORT: Post-analysis succeeded for file: /input (HeadlessAnalyzer)

run cmd:
docker run --rm -v /root/Desktop/iscm:/input fkiecad/cwe_checker /input
output:
thread 'main' panicked at 'called Result::unwrap() on an Err value: Error("missing field tid", line: 23469063, column: 9)', src/caller/src/main.rs:300:64
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

whats wrong?how to debug ,thank you