Hello everyboddy. Long time i havent been active on the scene, im still not , and didnt know the Fravia board is still living.

Thanks to dion for pointing me here.

I would like to start this thread to hear your comments, ideas and questions about DeDe and the sources, i made public.
It will be also nice if there is someone that have the wish and the potential to eventually continue further development or make improvements or bug reports or bug fixing etc. This doesnt mean i will stop the codding myself. Its for sure that i will add the Delphi 7 support when Borland relese it. Its now sure that there will be Delphi 7.


And now to dion's question



I dont understand very well what you exactly ask. What should DeDe recognize on the fly? And what you mean by "on the fly"

fix !! nice to see you alive ;D

Wazzup Thigo, nice to see good friends around

I dont know I am the only one but very often Dede locks my PC when loading delphi apps.Therefore I run the application and dump from memory.

Well this never happened to me. Realy. May be the problem is a conflict with some of the other programs you are running. Btw dumping from memory give less references than normal processing. And you always have the option to switch off running the target on processing if you dont want this.

Well strange but after making my sources public i got some strength and wish to finish the new version of DeDe. Here is part of the what's new:

1) Little change in the DSF symbols. The current version is now 2.2. Automatic convertion from v2.1 to v2.2 is included when opening ver 2.1 files.
2) Added option for advanced edit, insert and delete DSF symbol entries in a DSF file.
3) Added option for calculating a DSF ident for a procedure of a running process if you know its RVA. Added option to make DSF symbol ident for the currently disassembled procedure.
4) Added a few shortcuts for the disassembly window. F5 for disassemble again, Ctrl+A for select all, Ctrl+C for copy, Ctrl+F for find.
5) The class information form is now made visible on double click of item from the classes list.

Will be nice to read what you think is good for you to see in the next version 3.20

the case example on the fly is like after aspr-ed prog running and unpck itself, we can do unasm and apply the signatures directly from memory. can we do that?

if u don't mind, heres my comments. i think u should take a users point of view. u should think like them, asking why should i use dede instead idapro, example. asking to me, i'll answers:
- dede shows a better lib/class name, although sometime messed
- dede have sig for latest version of delphi, meanwhile idapro has
up to d5vcl only (as far as i know)
- dede lists class name, which useful to find an interesting one
- dede shows event/ctrl related procedure, which helps much in
tracking messages/program flow

some lacks i felt in dede are:
- the only attracting one in classes info tab is the name, i don't
have any idea what DFM offset and Unit name used for. it seems
lots of 'em sets to 0 and empty. also units info tab shows nothing
- something that has been planed by u, its better to visualize the
delphi form instead listing their properties. as addition, u can
integrate procedures tab to be part of delphi form shows. so,
when users click a button, dede'll shows its procedure directly
- no search class name string dialogbox
- there's no hint for DOI builder
- somehow pe editor is not necessary, excpt theres special feature
- ... i thought ur todo is good enough to make dede roxx

Hi dion and thanks for your comments. Here are my notes on them



Well unit name is good if you for example try to handle some protection and know that TUncleFaka is the main class used in the protection and you see it is from unit called SouthUnit. Well now it will be good to know which other classes are defined in this unit
DFM offset is the physical offset where starts the RCDATA for this class. By the way now (in 3.20) if you double click a class it is shown more information with all VMT entries, method list and field list. This can be good to explore some classes which dont have dfm resources and which methods can not be accessed via procedures tab.



Well im working on this May be it will be kind of a DFM editor which will show the form, type-of an objct inspector, and resource script. When i finish it (it is not that easy to make this ) i will think for adding procedures disassembly to show on clicking the controls.



I will add filtering and sorting by class name and unit name for the classes for 3.20



Yes because my intensions were that it will be used mostly by me. By the way i dont use it. Except when i create a DOI file for a new VCL version. There is also builder for doi files from pas files which you can find in DeDe. Run it with "more" parameter (not -more only more: "dede.exe more", then open the doi builder, hold ctrl+alt+shift and click 2 milimeters uper-right from the uper-right corner of the "New" button . So this is how you can activate the thingie. It is also used may be only by me for creating doi files.
So i plan to write description about DSF and DOI technologies, i believe i have done this in essays long ago but then noone cared for this, so i will describe how the things function and will explain how to use the DSF and DOI builders. There is already DSF editor in 3.20 implemented. I will also put something for easier managing of DOI stuff.



Well for me its very usefull because if you want to change a single flag or directory entry you dont need to run another program but can do it with DeDe. Dont know if you have seen the first version of DeDe but it had pe editor and a list with event handler names and their rva offsets only. So this has letf from the beginning.



Hmm ... dont have personal opinion about my todo but i think that DeDe roxxorz and for me it is clear it is better than IDA for delphi apps. The arguments for this are much more than the ones you have mentioned. The peoples just dont use it at 100%. And if you prefer IDA, Win32DASM or SoftIce you can just export everything there and enjoy. Dont know have you tried it but the win32dasm export is realy awesome! And it doesnt take too much time. May be i have to check is it a way to load symbols in trw. May be you can tell me ? <g> Oh ... and what about your other question for trw? i didnt catched it so ask again.

Cheerz

Well you can do this if you dump this process from DeDe. If your question is refered to is it possible to write a plugin for trw which will apply DeDe sigantures and show the symbol names then this is another cup of tea. Generaly it is possible but wont be fast. As i mentioned i think for another way to export DeDe references in trw. Because i use SoftIce i dont know how eventually this import in trw can be done. If the best option is writing a plugin then i can tell you everything you need to use DeDe's DSF files. But again it will be veeeeeery slow. The problem is you dont know which parts from the .CODE section are acctually executable code and which are VCL class info. So you will not be able to disassemble all the code, find call instructions and apply DSF identification for that RVA. So ti will not be fast to make idents for the whole code. The same case is with win32dasm export when you ask for all references. Probably i can speed this identifing for example with only looking for E8 byte followed by 32bit address which is in code section and only then to look does the proc at this offset have known dsf ident. But the speed will be known after we test it. Btw what language you code the plugins in ?

quote:
DFM offset is the physical offset where starts the RCDATA for this class. By the way now (in 3.20) if you double click a class it is shown more information with all VMT entries, method list and field list. This can be good to explore some classes which dont have dfm resources and which methods can not be accessed via procedures tab.

1. how could u enum every class name? are u scanning through all file for a string which begin with Twhatever?
2. could u tell me what u mean with 'some classes which dont have dfm resources and which methods can not be accessed via procedures tab'? if it doesn't have resource, then how it gets work?

quote:
Dont know if you have seen the first version of DeDe but it had pe editor and a list with event handler names and their rva offsets only.

sorry, but i don't see any event handler names list in pe editor, or am i forgot something?

quote:
If your question is refered to is it possible to write a plugin for trw which will apply DeDe sigantures and show the symbol names then this is another cup of tea.

yup! thats exactly my q.

quote:
As i mentioned i think for another way to export DeDe references in trw. Because i use SoftIce i dont know how eventually this import in trw can be done.

well, actually its available already, since trw can load .sym symbol file, and theres a tool to make symfile. and basically, but maybe i'm wrong, trw was built based on softice. lots of trw internal are ripped from softice. but, its add features, like dynamic load, auto disp imports, and blah-blah. i think if the author don't stop coding it, it'll be one of softice capable competitor. btw, lots of ppl complaint it buggy and weird behaviour, and then why u ppl dont try to fix and upgrade it? are u guys not smart enough to do so, or just happy being a goodboy users of powerful softice? maybe theres many guys become lame softice users right now, without knowing softice internal. ah... never mind that, maybe im just a lamer who trying to...

quote:
But again it will be veeeeeery slow. The problem is you dont know which parts from the .CODE section are acctually executable code and which are VCL class info. So you will not be able to disassemble all the code, find call instructions and apply DSF identification for that RVA.

hope im not wrong read this. but, gee... i dont have to take care all of that, coz we are in debugger, not anywhere. so the current opcode must be an executable code, right? one thing that might be have to do is check mempage availability and peek the byte, and do sign recog. btw, softice maybe slow to if it applied to her. and one again, we in debugger just see one instruction per se, so i dont plan to applying to whole prog, besides it could hang the computer if something bad happened

the language used for plugs is microsoft visual C++ v6.0. so, it can be c++ or asm, very flexible and could anything u want =)

First of all, I'd like to thank you for this tool, I've tried it last week and it is really great. I've been trying for two days to find something
and 5 minutes in Dede gave me the answer!
But there are two things; first, some of langres files seems to be invalid - I found that some lines aren't ended by 0x0d 0x0a but by only one of those bytes,
so its easy to fix; second, when I start processing some apps Dede says it is not Delphi App, but then it is processed right. The only app that was said to be Delphi 2 crashes Dede after some processing (Wincommander after manual unpacking).
But nevermind, this tool really deserves to be in reversers Hall of Fame.
Regards,
least

>1. how could u enum every class name? are u scanning through all file for a string which begin with Twhatever?

Classes are found by their self pointer not by searching a string To enumerate classes you should read dwords from the beginning of the file and if the dword value is equal to the RVA where this dword will be loaded in memory then this is a self pointer to a class. Then depending on a delphi version there is a structure of the VMT around this self pointer you can read and get all the additional information about the class you can find when you double click on it in the new DeDe.

>2. could u tell me what u mean with 'some classes which dont have dfm resources and which methods can not be accessed via procedures tab'? if it doesn't have resource, then how it gets work?

dfm resources have basicly only the forms. So the TStringList class for example for have dfm resources because its not a form. It will be the same with class called TDESCrypter for example

>sorry, but i don't see any event handler names list in pe editor, or am i forgot something?

I said that the first version of DeDe had only both pe editor and one list view with event handlers Btw during the times there was also API spy intergrated in DeDe but i removed it.

>well, actually its available already, since trw can load .sym symbol file, and theres a tool to make symfile.

Well then i should install trw and see how to directly compile and load the .sym file in trw as i do for SoftIce.


>hope im not wrong read this. but, gee... i dont have to take care all of that, coz we are in debugger, not anywhere. so the current opcode must be an executable code, right? one thing that might be have to do is check mempage availability and peek the byte, and do sign recog.

I thought about recognizing calls the already passed ones and the future ones some bytes ahead from the current EIP but on the same level. May be you have other ideas. Can you explain? And im realy not sure its good to implement dfs recognition plugin.

Oh some of the features i work on for the new DeDe are: As i said DFM editor, a good one , and i plan to put a debugger in DeDe. But a special one. My idea is to be able to put breakpoints on VCL classes methods directly. I.e. to put for example bpx ShowMessage or bpx TApplication.CreateForm or bpx TEdit.GetText etc which will break when this method is called.

Hi least and thanks for the comment



Probably you have old version. This problem is fixed from a month. Just dont upload text files in ascii mode like me because some idiot linux on the route may deicde it doesnt like the #13 and remove it



Yes you can process winhex with DeDe. It tells you its not delphi but if you chose ignore it will find some similar sturctures. But its not delphi for sure If you have found an application for which DeDe sais its not delphi app and then finds classes, units or foms i will be curious to look at it



Yes i know Delphi 2 applications crash DeDe. Delphi 2 executables structure is different from D3 and above and i have never had time to analize it more detaily. And the delphi 2 applications ratio to latest versions delphi applications used nowadays shoul be less than 0.1% i think.

If you manage to create these, well this will be so nice to have I keep my fingers crossed for you.

Rex

The app that Dede doesn't identified but processed right was one of tKC's cracking tutorial compilations (tuts 1-100),
I can't remember the name; it showed nag with text like Cracking Commander v1.0 ...
The app was packed so maybee the signature you use was somewhat damaged. Hope it helps.
Regards
least

quote:
To enumerate classes you should read dwords from the beginning of the file and if the dword value is equal to the RVA where this dword will be loaded in memory then this is a self pointer to a class.

got it in TClassDumper.Dump. but why that dword val must be RVA while loaded in memory? i dont understand what is FbClassFlag? what for?

hmm... could u describe how these class selfptr get load and processed? and why delphi not static linked/hardcoded every class's calls instead?

quote:
I thought about recognizing calls the already passed ones and the future ones some bytes ahead from the current EIP but on the same level. May be you have other ideas. Can you explain? And im realy not sure its good to implement dfs recognition plugin.

sorry, but i dont get ur point. i thought an already past calls are still in current page and can be applied to dsf. and the upcoming calls might be still in another memory pages, although its possible to pagein that page, i dont see it need to do so, besides pagein command should be used carefully, if not it'll hang the os.

a special debugger... gr8! cant wait ur new release now
PS. are u using debug api for that?

quote:
got it in TClassDumper.Dump. but why that dword val must be RVA while loaded in memory?

because its self pointer to itself its memory location equals its value

quote:
i dont understand what is FbClassFlag? what for?

acctually these structures are type information, not class definitions. So they can be class, record, enumeration etc. This flag shows what kind of structure is that. All with flag 7 are classes.

quote:
hmm... could u describe how these class selfptr get load and processed? and why delphi not static linked/hardcoded every class's calls instead?

the classes can not be called in this meaning. Their methods can be called. Borland created this typeinfo struture to store information about the classes. The virtual and dinamic metods are called using the virtual method and dinamic metod's tables in this class info. The methods which are not virtual and not dinamic are called using hardcoded offsets set by the compiler/linker. The static methods (called "class methods" in delphi) are also called with E8. Btw the typeinfo structure Borland developed is realy smart thing

About DSFs. As i said the problem is that the CODE section of delphi executable contains not only code but both code and data. Thats why win32dasm sometimes cant disassemble the code corectly. So if you scan the whole CODE section in memory for DSF references this will take lots of time. Its much better to try to identify a procedure at certain rva when you are sure that this rva is called as procedure.

Now about the DSF file format and identification engine. Well its not very well developed because the idents are not in a tree structure like the ida signatures for example. DSF file contains list of idents followed by a list of names. Of course this is not a problem becasue you can create the tree structure in the memory while you load the dsf file and this will speed up the recognition. DeDe keeps the list of dfs idents in the memory and also a list with the first byte of each ident and a list with the names. When a procedure should be recognized DeDe reads it's first 50 bytes into a buffer. Then loops among all dsf idents and check is the first byte of the ident (or signature, i call it ident) the same as the first byte of the buffer. If not then continue with the next ident. If the bytes are identical then the buffer and the ident are compared. Before doing the match loop the buffer is processed to remove all not relative data in it. Like absolute offsets. This is done by disassembling the buffer, analize the instructions and remove all unwanted bytes. This way from the buffer is calculated the dsf ident for this buffer. The function that does this i called UnlickCalls() and is implemented in DeDeDisAsm if i remember well. The reults shows that this matching works fast enough when the calles from only one procedures should be processed by the dsf engine. But when this should be done for the whole CODE section this is rather slow. A better method will be if the DSF idents in memory are stored in a sorted tree structure. Then the matching with all dsf idents can be done much faster. May be i will implement this in next version as well

quote:
a special debugger... gr8! cant wait ur new release now
PS. are u using debug api for that?

yes i plan to use debug api because it will be ring 3 debugger Its still on a very early stage. Just read your post about trw and remembered i wanted to add debugger in DeDe

i would to ask something, what method used by dede in displaying string reference? r u check every opcode byte or parse for xxxxxxxx char? looks like u forgot to filter every char, after i see it in disasm window.

sorry to quote again:
The problem is you dont know which parts from the .CODE section are acctually executable code and which are VCL class info.

mm... do i have to get VCL class info [by scanning for selfptr soFromBeginning] before applying dsf? i thought theres already a label in dsfs.

looking dsf a bit... i conclude that u match pattern per byte, and skipping 0 byte value. if found than index used for read the label. am i wrong?

looking dsf referencing proc... i think u were right, it can be slow. but i've another idea and reasons. the slowest/longest time taken to apply dsf could be measured from (sorry) ur dede, right? as plugin, i could do an ontime processing, ie after typing cmd, i do the process required to apply dsf [maybe using a virtual xport table]. after finished then users can countinue to dbug. so, the next process in unasm proc, i just do a lookup to that virtual table to alter the current call label.

looking at IDAs sig... looks like it using a tree structure, but i dont get the detailed field yet. just wonder, might be u know this in detail, plz let me know.

thking a bit... dont know why IDA take longer time to apply sig than dede. oh... b4 forgot, r u dsf-ing at load or at disasm proc?

quote:
i would to ask something, what method used by dede in displaying string reference? r u check every opcode byte or parse for xxxxxxxx char? looks like u forgot to filter every char, after i see it in disasm window.

For all push imm_data and mov imm_data instructions i check does the pointer points to a pascal ascii string


quote:
mm... do i have to get VCL class info [by scanning for selfptr soFromBeginning] before applying dsf? i thought theres already a label in dsfs.

VCL class info can be usefull because if you know all classes used in the program you can remove the references to the rest of them.

quote:
looking dsf a bit... i conclude that u match pattern per byte, and skipping 0 byte value. if found than index used for read the label. am i wrong?

dont realy understand what you meant


quote:
looking at IDAs sig... looks like it using a tree structure, but i dont get the detailed field yet. just wonder, might be u know this in detail, plz let me know.

yes ida uses tree structure and im also implementing tree structure for dede dsf recognition. You also should implement one because the data in the file are in a list. For dede i will read them and put them in a tree on the dsf loading. So later they will be easier to be used.

quote:
b4 forgot, r u dsf-ing at load or at disasm proc?

at disasm proc


And some good news The dfm editor development goes very well. I will put a very beta to hear comments on it. It can re create forms, show a tool window with tree structure of all controls and properties and can follow the focus of the mouse while you move over the recreated form. It still doesnt look very good but will be improved.

quote:
When a procedure should be recognized DeDe reads it's first 50 bytes into a buffer.

i cant find the _PatternSize definition anywhere. r u using a fix 50 bytes dsf sig? so, i just have to break each stream after "VCL2 dcu" to 50byte and then do unlinkcall() and match the pattern?

quote:
Before doing the match loop the buffer is processed to remove all not relative data in it. Like absolute offsets. This is done by disassembling the buffer, analize the instructions and remove all unwanted bytes.

case example [1st ident]:
53 push ebx
8BD8 mov ebx,eax
8BC3 mov eax,ebx
E800000000 call ????????
53 push ebx
6800000000 push ????????
B900000000 mov ecx,????????

what i mean with skip 0 byte is like call above, but looks like u do it opposite, thats in unlinkcall. r u sure that only relative data gets omitted or the other too like mov ecx,???????? above?

i just have to deal with .CODE section to get vcl infos, havent i? or the .DATA too?

i cant find the VMT struct. could u tell me wheres it?

quote:
VCL class info can be usefull because if you know all classes used in the program you can remove the references to the rest of them.

remove whose reference? i dont understand it.

so, u dsfing at disasm proc. he-he... thats cheats a bit. btw, how long would it take if u do that with whole CODE section? several minutes? or several hours? ;p

a little about pascal str. i see in disasm example and seeing in hexeditor, that most str refered is C style. how do u manage to disp both pascal and C style work together?

PS. r u coding whole day? anyway, gr8 progress!

quote:
i cant find the _PatternSize definition anywhere. r u using a fix 50 bytes dsf sig?

_PatternSize is defined in DeDeConstants and it has been different than 50 for the earlier dsf versions. For last one 2.1 and 2.2 it is 50.

quote:
so, i just have to break each stream after "VCL2 dcu" to 50 byte and then do unlinkcall() and match the pattern?

Man look at my code

quote:
r u sure that only relative data gets omitted or the other too like mov ecx,???????? above?

I remove all data which is relative and also fixed pointers to class instanced and other hardcoded pointers which VCL internaly use. Like mov eax, dword_value. Thats why dsf is much better than ida sig. I made dsf specially for VCL after long analisis of delphi compiler. So the unlinkcalls() procedure does it all.

quote:
i cant find the VMT struct. could u tell me wheres it?

it is not of great importance for coding dsf parrern compare

quote:
VCL class info can be usefull because if you know all classes used in the program you can remove the references to the rest of them.

remove whose reference? i dont understand it.

if the target application dont use the unit BlaUnit then you can remove all dsf idents for procs from this unit at the dsf file loading to make the database smaller i.e. faster matching.


quote:
so, u dsfing at disasm proc. he-he... thats cheats a bit. btw, how long would it take if u do that with whole CODE section? several minutes? or several hours? ;p

a lot ;p can be about hour for big executables. It will be surely optimized with the tree tructure and the E8 trick i mentioned. May be will be more than 10 times faster i believe.

quote:
PS. r u coding whole day? anyway, gr8 progress!

Look at my next started thread

Hello DaFixer,

maybe DeDe could accept drag & drop .exes? (for some lazy people ).

Regards,
sF

Done

if u dont mind, i have a basic question. i've read ur tut D1.htm about delphi preliminary. quote from the tut:

"Have you ever asked the question why Delphi executables are so big in size? The answer is that in them is stored also the code of all classes from the VLC (Visual Component Library) that is needed for your program to run."

i've trying to compile with different "uses" directive results same exe size. at this point, i thought that this VCL package classes function offset would be same for all exes. when i trying to add some codes, the results is rather different classes function offset, but with same DELTA offset. i just focus to classes that have VMT struct, the rest is ignored. from particular ptr in VMT struct, i check it to module window [Ctrl+Alt+M in delphi]. from here, i conclude that i could use this delta offset to unmangle classes member methods, of course limited to the rule above. or, in more simple word, it seems every vcl classes has a standardized class methods lists. the question is, do u feel this can be useful to reduce dsf sig requirement?

P.S. the symtable is ready to used now

thanks

Man have no idea what you call "classes function offset" and "DELTA offset"

quote:
or, in more simple word, it seems every vcl classes has a standardized class methods lists. the question is, do u feel this can be useful to reduce dsf sig requirement?

I dont understand what you call that is "standardized" in class method list. Also what you mean by "reducing dsf sig requirement" do you mean less bytes per pattern?

Note that the methods in a method list from VTM are the published methods and they are defenitely nothing to do with DSFs. Published methods contain only the last classes in hierarchy which are defined by the programmer and there are no dsfs for them. i.e. TMainForm is your main form and it has published methods. The TForm class have zero published methods. From VMT you also can take pointers to the list of virtual and dinamic methods of a class. Low level classes has lots of them. They are also not included in the DSF files because they are not called by E8xxxxxxxx (call offset) but are called by "call [reg+offs]" and this can not be matched from a dead listing. The virtual and dinamic methods are identified by the DOI engine and their references in DeDe are shown like this:


* Reference to control TBPL.LogMemo : TMemo
|
00539144 8B803C030000 mov eax, [eax+$033C]
0053914A 8B10 mov edx, [eax]

* Reference to method TMemo.Clear()
|
0053914C FF92DC000000 call dword ptr [edx+$00DC]

To be able to find them DeDe have to make a pseudo emulation of the code. It acctually only takes care about pointers to classes instances and their fields and methods access.

The methods you can find in the DSF file are not virtual, nor dinamic nor published. The definition, if such exists, is that they are methods called by "call offset".

quote:
P.S. the symtable is ready to used now

Im also almost ready with my tree structure of dsf idents in the memory. Soon will know how long it takes to identify *all* methods in the vcl classes in DeDe itself using the new tree structure. I hope this time will be reduced to less than 30 sec. Currently it will take more than ten minutes i guess.

Hi
I have an idea for DeDe .

for example : (435408 == GetText)
* Reference to: controls.TControl.GetText(TControl):System.String;
0050CB5D E8A688F2FF call 00435408

When Dede creates map file for IDA or SICE it looks like this :
.0050CB5D ; > controls.TControl.GetText(TControl):System.String;

I think it would be better if Dede marks 435408 as GetText instead of adding a comment on 50CB5D .
Because Dede only decodes the parts of the prog that r related to the Forms and not all the file .
Sometimes it happens like this :

435408 : xxxx Data refs : 50cb5d , 430598

When u r at 50cb5d you can see the comment and u will know that it is GetText ,
but when u r at 430598 u can't find out that .

It would be better if dede generate the map file this way , and save the time for not marking them manually

Sorry for the bad English .

Noticed the latest version seems to crash when I'm viewing a lot of different forms in the decompiled delphi unit to try and associate the formname with the form I get when I try to reg a program. It's find on a few forms, but when I go mad and start viewing all the forms in turn, it throws up an access violation a few times, and eventually dies. I'll try and get more info on this.

Also, could the disassembled output include jump references like w32dasm normally does (Location referenced by jump at address xxxxxxxx), or would this add too much processing to the otherwise turbo-charged dumping algo?

Ta for a great prog!

First of all thanx for the great app.
Some programs (eg atlast! file notes organiser) kill dede.
and also disable its "FILE" menu.
Is there a way to circumvent this from dede itself like anti antsice

the first one could be overcome by launching multiple instances of dede - so as to feed the hungry app with few ones !!!