Is Olly going to release the format of the UDD file ? I can think of some interesting add-on's if he could release the specs of this file.

Squidge: i have an old UDD specification ... mail me with your ideeas and i will send it over

Done !

Did you receive the email? I sent it to the one specified in your user profile.

<pre>
.UDD (User-Defined Data) file consists of unaligned variable-length records.
Each record has the following format:

#define MI_SIGNATURE 0x00646F4DL // Module info signature
#define MI_FILENAME 0x6C69460AL // Record with full path of executable
#define MI_FILESIZE 0x7A69530AL // Record with file size
#define MI_TIMESTAMP 0x7473540AL // Record with timestamp file data
#define MI_USER 0x0073550AL // User data record (ORed with NM_xxx)
#define MI_INT3BREAK 0x7470420AL // Record with breakpoint data
#define MI_INT3BRKC 0x6370420AL // Record with checked breakpoint data
#define MI_ANALYSIS 0x616E410AL // Record with analysis data
#define MI_ANALPACK 0x636E410AL // Record with compressed analysis data
#define MI_CODECRC 0x7263430AL // Record with CRC of code for analysis
#define MI_SAVEAREA 0x6176530AL // Record with general-purpose save area
#define MI_END 0x646E450AL // End of module info data

struct t_record {
long tag; // Unique tag (MI_xxx) identifying record type
long size; // Size of data, bytes (may be 0)
char data[size]; // Data itself
};

(Try to read tags as ASCII text). File must begin with MI_SIGNATURE record
containing 22-byte string "Module info file v1.1&#92;0". All other records are
optional. If OllyDbg doesn't know the meaning of the record, it simply ignores
it. This assures backward compatibility: breakpoints set by v1.02, for example,
will appear in OllyDbg v1.00.


MI_FILENAME contains full path to the file.


MI_FILESIZE contains 32-bit file size. (I haven't heard yet about .exe or .dll
that is longer than 4G bytes).


MI_TIMESTAMP is formed as follows:

FILETIME tlastwrite;
// Get timestamp (time of last update) and size of executable file.
hf=CreateFile(pmod->path,0,FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
if (hf==INVALID_HANDLE_VALUE)
return; // Unable to query executable file
GetFileTime(hf,NULL,NULL,&tlastwrite);
filesize=GetFileSize(hf,NULL); // Here you has file size for MI_FILESIZE
CloseHandle(hf);
Saverecord(f,MI_TIMESTAMP,sizeof(tlastwrite),&tlastwrite);


For you, the most important record is MI_USER. I use it to save all types of
user data that are text. Size of data in MI_USER+xx records never exceeds 260
bytes (including terminal '&#92;0'). I don't use MI_USER directly; instead, it is
ORed with type of user data (NM_XXX) shifted 24 bits to the left (so NM_XXX
comes into the most significant byte of the tag).

#define NM_LABEL 0x31 // User-defined label
#define NM_EXPORT 0x32 // Exported (global) name
#define NM_IMPORT 0x33 // Imported name
#define NM_LIBRARY 0x34 // Name from library or object file
#define NM_CONST 0x35 // User-defined constant
#define NM_COMMENT 0x36 // User-defined comment
#define NM_LIBCOMM 0x37 // Comment from library or object file
#define NM_BREAK 0x38 // Condition related with breakpoint
#define NM_ARG 0x39 // Arguments decoded by analyser
#define NM_ANALYSE 0x3A // Comment added by analyser
#define NM_BREAKEXPR 0x3B // Expression related with breakpoint
#define NM_BREAKEXPL 0x3C // Explanation related with breakpoint
#define NM_INSPECT 0x40 // Several last inspect expressions
#define NM_WATCH 0x41 // Watch expressions
#define NM_ASM 0x42 // Several last assembled strings
#define NM_FINDASM 0x43 // Several last find assembler strings
#define NM_LASTWATCH 0x48 // Several last watch expressions
#define NM_SOURCE 0x49 // Several last source search strings

#define NMHISTORY 0x40 // Converts NM_xxx to type of init list

struct t_midata {
long offset; // Offset of symbol from the beginning of the module
char sztext[size-4]; // Zero-terminated symbolic name, 256 bytes max
};

Following user data types are associated with some module and can appear in any
.udd file:

NM_LABEL, // User-defined label
NM_LIBRARY, // Name extracted by object scanner
NM_COMMENT, // User-defined comment
NM_LIBCOMM, // Comment generated by object scanner
NM_BREAK, // Condition related with breakpoint
NM_BREAKEXPR, // Expression related with breakpoint
NM_BREAKEXPL, // Explanation related with breakpoint
NM_ANALYSE, // Comment added by analyser
NM_ARG // Decoding of known function

.udd file of main module (.exe) also keeps watch expressions and history lists
(they appear if you open pull-down window of the combobox). For this data,
offset field is simply a 1-based ordinal:

NM_LABEL | NMHISTORY, // List of last entered labels
NM_COMMENT | NMHISTORY, // List of last entered comments
NM_BREAK | NMHISTORY, // List of last entered break conditions
NM_BREAKEXPR | NMHISTORY, // List of last break expressions
NM_BREAKEXPL | NMHISTORY, // List of last break explanations
NM_INSPECT, // Inspect expressions
NM_WATCH, // Watch expressions
NM_ASM, // Several last assembled strings
NM_FINDASM, // Several last find assembler strings
NM_LASTWATCH, // Several last watch expressions
NM_SOURCE // Several last source search strings


When OllyDbg encounters MI_END, it stops file processing.
</pre>

it is a bit outdated ... i think from 1.04.
i cannot read my email till monday ... sorry

No Problem. Thanks, I can just reverse engineer the rest if I need too, now that I have a starting point.

Squidge: have u looked inside mapconv plugin ? it imports labels from .map file made from IDA/Softice

No, I didn't even know it existed. Thanks, I'll look into that.

Edit: Dang, wheres the plug-in page again?

Squidge: look for [ODF] posts or directly
<u>http://rohanpal.com/ollydbg/files</u> ("http://rohanpal.com/ollydbg/files")