I have disassembled a application in IDA4.3 but I can't work something out.

When I am searching for my string it always seems to find it in the .DATA: bit, but these line numbers don't go anywhere in the program.

So the question is... how do I find the ".DATA:" bit in the main program

Thats because when you click on the string it takes you to the .DATA section. You will see something like this:
.data:10020698 aStandard db 'standard',0 ; DATA XREF: sub_10002C6C+148o
.data:100206A1 align 4

In this example, 'standard' is referenced by sub_10002C6C. Double click on the reference sub_10002C6C to go to the code. You might also want to read an IDA primer while you're at it.

NO.... Not RTFM.

Regards,

This one does not have the XREF, so double clicking it does not work.

Did you wait for your disassembly to complete first? If you did not wait for the analysis to finish, string searching might not work correctly. As I stated before you might want to read an IDA primer. IDA is not an easy program to tackle (I'm a newbie myself).

And are you suggesting that they put a string reference in the .DATA section and "never" reference it in the code? Only reason that is likely to occur is that it is something which was in the code at one time and modification of the code removed the XREF and they simply did not delete it from the .DATA file. Or unless it's in an encrypted section.

Regards,

What I found out was... when I seached for the string and it was returned without the XREF, I used the line number (to the left of the returned string) and set a BPM at that address in SI and it seemed to work, the application stopped as it was about to return the string.

Does this sound right ?

I think if that has been the case (string has no longer been referenced), the linker would remove the whole string, isn't it right?

Unfortunately, the linker is not so smart or -better- it does not have the authority to do so.
Try compiling this:



Regards, bilbo

Imagine:
======

DATA.00000000: dataxxx
DATA.00000023: datayyy
DATA.00000034: dataabcd
DATA.0034cdfw: datapqer
.......


1)Accessing data simple way
======================

If a program refers to the data directly such as:

TEXT.00012345: push dataabcd

then you will find that actually:

DATA.00000034: dataabcd XREF: Text.00012345

If you click on the XREF, it will take you to the code location at TEXT.00012345.

2) Accessing data the TABLE way
=========================
Your program can also refer to the data indirectly such as:

TEXT.00012345 push [DATA.00000000+34]

In this case, you will NOT find any XREF when you see the data section. You will simply see:

DATA.00000034: dataabcd

the XREF: Text.00012345 part will not be there because its being reffered via a table.

However, you can search for XREFS at the BEGINNING of the table, i.e. at DATA.00000000 [OR] you can search for 34 binary in IDA.

Yet, there are many ways to indirectly access data. Use a different bait to fish out your strings. And make sure you are not confusing the DATA section strings with the RESOURCE section strings. You will NOT get RESOURCE section strings XREFS.

Have Phun

Or perhaps, as good as IDA is, it simply wasnt able to resolve an xref because the data is referenced by register
indirect addressing mode....or because the fragment of code which references the data hasnt been 'discovered'
by IDA for various reasons...

-Shadz

You say correct, biblio !
I compiled your code with VC .NET 2003, maximum optimize options. The mystring still in the data section.
markh51 !
Sometime, we should open the problem windows, and press C (Code) or P (proc) to force IDA try disassemly blocks of problem code (and you think they are code block), and may be the reference will be in those blocks.
Regards
TQN