有害的C源文件检查？ [英] Harmful C Source File Check?

问题描述

有没有办法为编程检查，如果一个 C源文件是潜在有害的？

Is there a way to programmatically check if a single C source file is potentially harmful?

我知道，没有检查将产生100％的准确率 - 但我感兴趣的至少的做一些基本的检查，将提出一个红色的标志，如果一些前pressions /关键字找到。什么任何想法去寻找？

I know that no check will yield 100% accuracy -- but am interested at least to do some basic checks that will raise a red flag if some expressions / keywords are found. Any ideas of what to look for?

注意：我会检查文件的大小（最多行数100S）相对较小，实现数值分析的功能，所有操作的内存。无需外部库（math.h中除外）应在code使用。此外，没有I / O，应使用（函数将在存储器阵列上运行）。

Note: the files I will be inspecting are relatively small in size (few 100s of lines at most), implementing numerical analysis functions that all operate in memory. No external libraries (except math.h) shall be used in the code. Also, no I/O should be used (functions will be run with in-memory arrays).

鉴于上述情况外，还有一些的程序检查我可以做的至少尝试的检测有害code？

Given the above, are there some programmatic checks I could do to at least try to detect harmful code?

注意：，因为我不希望任何I / O，如果code做I / O - 它被认为是有害的

Note: since I don't expect any I/O, if the code does I/O -- it is considered harmful.

推荐答案

如果你想确保它没有要求任何东西不准，然后编译件code，并研究一下它的链接（通过<$说C $ C>纳米）。既然你挂了一个纲领性的方法这样做，只是使用Python / Perl的/ bash的编译，然后扫描该目标文件名列表。

If you want to make sure it's not calling anything not allowed, then compile the piece of code and examine what it's linking to (say via nm). Since you're hung up on doing this by a "programmatic" method, just use python/perl/bash to compile then scan the name list of the object file.

有没有很多可以做缓冲将覆盖静态定义的缓冲区，但你可以针对电动栅栏式内存分配器链接到prevent动态分配的缓冲区溢出。

There's not a lot you can do about buffer overwrites for statically defined buffers, but you could link against an electric-fence type memory allocator to prevent dynamically allocated buffer overruns.

您也可以编译和链接问题的C文件对驱动程序的valgrind下，它可以帮助检测不佳或恶意书面code运行时，这将喂养它的典型数据。

You could also compile and link the C-file in question against a driver which would feed it typical data while running under valgrind which could help detect poorly or maliciously written code.

在最后，然而，你总是要反对这是否终止程序的问题，这是著名的不可判定跑起来。对此的一种切实可行的方法是编译程序和驱动程序运行它这将报警退房手续后的合理的一段时间内。

In the end, however, you're always going to run up against the "does this routine terminate" question, which is famous for being undecidable. A practical way around this would be to compile your program and run it from a driver which would alarm-out after a set period of reasonable time.

修改：示例显示使用纳米：

创建一个C段定义功能富这就要求的fopen ：

Create a C snippet defining function foo which calls fopen:

#include <stdio.h>
foo() {
   FILE *fp = fopen("/etc/passwd", "r");
}

与 -c 编译，然后看看生成的目标文件：

Compile with -c, and then look at the resulting object file:

$ gcc -c foo.c
$ nm foo.o
0000000000000000 T foo
                 U fopen

在这里，你会看到有是 foo.o的目标文件中两个符号。一个定义，富，子程序的名字，我们写了。一个是不确定的，的fopen ，这将被链接到它的定义时，目标文件与其他C-文件和必要的库联系在一起。使用这种方法，你可以立即看到，如果编译对象在其自己的定义之外引用什么，你的规则，可以被认为是坏的。

Here you'll see that there are two symbols in the foo.o object file. One is defined, foo, the name of the subroutine we wrote. And one is undefined, fopen, which will be linked to its definition when the object file is linked together with the other C-files and necessary libraries. Using this method, you can see immediately if the compiled object is referencing anything outside of its own definition, and by your rules, can considered to be "bad".

这篇关于有害的C源文件检查？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！