Sometimes not working when generate CDG,PDG.. from il

[Byland]

Hi,
After I generate the il file from ida database, I use the il file
to
generate the CFG, CDG,PDG, sometime is ok, but some time is not ok,
especially when the ida database is very big.
For one error below:
./irtrans -fromhuman ../testfiles/test1.il -cfg ../testfiles/test1-
cfg.dot d
../testfiles/test1.il:1.1046-1.1047:error: Syntax error line 47 pos
14: :

test.il:
line 47 void ios_base::good()
line 48 {
line 49 label pc_0x41100a:
line 50 /*jmp 0x000000000041403a*/
line 51
line 52 jmp(name(pc_0x41403a));
line 53 return;
line 54 }

I guess this function is inherited from function good, once there is
not inheritance, everything is ok, so
Any one have some suggestion? Thanks very much!!!!!!!!!!!

[Stephen McCamant]

>>>>> "B" == Byland <zb198...@gmail.com> writes:

B> Hi,
B> After I generate the il file from ida database, I use the il file
B> to generate the CFG, CDG,PDG, sometime is ok, but some time is not
B> ok, especially when the ida database is very big.
B> For one error below:
B> ./irtrans -fromhuman ../testfiles/test1.il -cfg ../testfiles/test1-
B> cfg.dot d
B> ../testfiles/test1.il:1.1046-1.1047:error: Syntax error line 47 pos
B> 14: :

B> test.il:
B> line 47 void ios_base::good()
B> line 48 {
B> line 49 label pc_0x41100a:
B> line 50 /*jmp 0x000000000041403a*/
B> line 51
B> line 52 jmp(name(pc_0x41403a));
B> line 53 return;
B> line 54 }

B> I guess this function is inherited from function good, once there
B> is not inheritance, everything is ok, so
B> Any one have some suggestion? Thanks very much!!!!!!!!!!!

Vine doesn't know anything about the semantics of inheritance per
se, since it's working at the binary level. But my guess as to what is
triggering this error is the "::" symbol in the function name (which
is related inheritance in the broad sense that it comes from the fact
this is a C++ method rather than a plain C function). Vine identifiers
have the same syntax as C identifiers, namely [A-Za-z_][A-Za-z_0-9]*,
which doesn't allow colons or other punctuation marks.

The general phenomenon going on here is called "name mangling"
[1]. The IDA plugin is collecting the unmangled names of functions,
since those are more informative for users, but you would need to use
a mangled name for a Vine identifier. At a high level, you could do
this either by getting the mangled name in the plugin, or by
re-mangling the name in Vine.

Hope this helps,

-- Stephen

[1] http://en.wikipedia.org/wiki/Name_mangling

[Byland]

Hi, Stephen
Thanks for ur help. According to ur suggestion, one way is I should
change IDASql plugin which you have wrote in vine ? and another way is
to re-mangling the name in Vine, how can I do it in this way?
Thanks!

On Mar 30, 7:33 am, Stephen McCamant <s...@CS.Berkeley.EDU> wrote:

[Byland]

Hi, Stephen
And also another problem is that every time I generate the CFG,
DDG , the data inside the CFG is right, but the data inside the DDG is
not right, every time is below:

digraph G {
BB_Entry [label="BB_Entry\n/*entry node*/\n", shape=box];
BB_Exit [label="BB_Exit\n/*exit node*/\n", shape=box];
BB_3 [label="BB_3\n/*Empty bb*/\n", shape=box];
}

I use this command:
./irtrans -fromhuman ../testfiles/test.il -ddg ../testfiles/test-
ddg.dot

Thanks!!!!!!

On Mar 30, 7:33 am, Stephen McCamant <s...@CS.Berkeley.EDU> wrote:

[Stephen McCamant]

>>>>> "ZB" == Byland <zb198...@gmail.com> writes:

ZB> Hi, Stephen
ZB> And also another problem is that every time I generate the CFG,
ZB> DDG , the data inside the CFG is right, but the data inside the
ZB> DDG is not right, every time is below:

ZB> digraph G {
ZB> BB_Entry [label="BB_Entry\n/*entry node*/\n", shape=box];
ZB> BB_Exit [label="BB_Exit\n/*exit node*/\n", shape=box];
ZB> BB_3 [label="BB_3\n/*Empty bb*/\n", shape=box];
ZB> }

ZB> I use this command:
ZB> ./irtrans -fromhuman ../testfiles/test.il \
ZB> -ddg ../testfiles/test-ddg.dot

Sorry for the delayed response: I hope it's still valuable to you or
someone else.

Do you have a small example that demonstrates this behavior? I wasn't
able to reproduce it using either a small hand-written example like
the one I'd used in discussing slicing:

var INPUT_0:reg8_t;
var INPUT_1:reg8_t;
var INPUT_2:reg8_t;
var a:reg32_t;
var b:reg32_t;
var c:reg32_t;
var d:reg32_t;
a:reg32_t = cast(INPUT_0:reg8_t)U:reg32_t;
b:reg32_t = cast(INPUT_1:reg8_t)U:reg32_t;
c:reg32_t = cast(INPUT_2:reg8_t)U:reg32_t;
c:reg32_t = a:reg32_t + b:reg32_t;
d:reg32_t = a:reg32_t + 10:reg32_t;

which on my machine gives the following graph:

digraph G {
BB_Entry [label="BB_Entry\n/*entry node*/\n", shape=box];
BB_Exit [label="BB_Exit\n/*exit node*/\n", shape=box];

BB_3 [label="BB_3\na_64:reg32_t = cast(INPUT_0_57:reg8_t)U:reg32_t;\n",
shape=box];
BB_4 [label="BB_4\nb_65:reg32_t = cast(INPUT_1_58:reg8_t)U:reg32_t;\n",
shape=box];
BB_5 [label="BB_5\nc_66:reg32_t = cast(INPUT_2_59:reg8_t)U:reg32_t;\n",
shape=box];
BB_6 [label="BB_6\nc_67:reg32_t = a_64:reg32_t+b_65:reg32_t;\n", shape=box];
BB_7 [label="BB_7\nd_68:reg32_t = a_64:reg32_t+10:reg32_t;\n", shape=box];
BB_3 -> BB_6;
BB_3 -> BB_7;
BB_4 -> BB_6;
}

or the larger IL file generated from running appreplay on the
"five.trace" example in the release, which gives a ~4700-node graph.