Two problems I noticed

[Artic]

noticed 2 things:

 

- opening a target via the opening menu point is not working, dropping the target in x64dbg! x64dbg is then unable to debug the target

- is there a way to keep the Strings somewhere open/save, because when i search all of them and then go back into CPU view make there something and then want to look again for strings i have to search for them again

- sometimes the strings are not show, when the target is opened, but the string search works.

 

then i have another question: im loading a target blbla.exe and this has blbladgkd.dll, which its loading and want to set a dll-entry break there, is there a simple way to do that?

for olly i have used WEAKOD plugin for this job.

 

reversed first target so far and its overall pretty good to work with it, the analyse/disasm is going pretty fast. (im on a 5 yo notebook core2duo 2GHz, 3GB x64 win7)

 

so far hav not used x32dbg much, so cant tell you if there are the same problems i have encountered at the x64 version.

 

EDIT: another problem:

e.g.:

i have there a "jnz 7FEEA0E5EAE" and i want it to assembly it to "jnz 7FEEA0E5E87", then im getting an Error-box

i can set the JNZ to that adress( the memonic is set on 7FEEA0E5E85),

its also not possible to assemble for example to "jz 7FEEA0E5EAE" - im getting the same problem there, so in fact the same error-box.

do i edit it with the hexeditor that way the target works fine, so i am doing definitely nothing stupid. (cant post the target here, its a commercial one im reversing for myself and also to save the company)

 

Edited May 16, 2014 by Artic

[mrexodia]

noticed 2 things:

yea.. right

- opening a target via the opening menu point is not working, dropping the target in x64dbg! x64dbg is then unable to debug the target

Could you make some screenshots/video of this? I cannot reproduce it. Are you by any chance debugging a DLL and then you try to debug the same DLL again?

- is there a way to keep the Strings somewhere open/save, because when i search all of them and then go back into CPU view make there something and then want to look again for strings i have to search for them again

As long as you don't find any other references, you can find the strings under the tab 'References' (Alt+R).

- sometimes the strings are not show, when the target is opened, but the string search works.

Thanks for reminding me of this, it happens when you find strings twice and then start searching. I forgot to remove a few columns from the searchlist (the list you see has a hidden list above it, the search list. It's just a duplicate, this is because in this way it's not needed to store the original list somewhere). It is now fixed in the source code and will be fixed on the next release.

then i have another question: im loading a target blbla.exe and this has blbladgkd.dll, which its loading and want to set a dll-entry break there, is there a simple way to do that?

for olly i have used WEAKOD plugin for this job.

This is currently not build-in in x64dbg, but I will make a small plugin that does this soon.

 

reversed first target so far and its overall pretty good to work with it, the analyse/disasm is going pretty fast. (im on a 5 yo notebook core2duo 2GHz, 3GB x64 win7)

Glad to hear it worked well

so far hav not used x32dbg much, so cant tell you if there are the same problems i have encountered at the x64 version.

They are the same source code, so any problems you find *should be* the same for both the x32 and x64 version, as long as the problem is not related to a library (TitanEngine sometimes behaves a little strange on different architectures).

EDIT: another problem:

e.g.:

i have there a "jnz 7FEEA0E5EAE" and i want it to assembly it to "jnz 7FEEA0E5E87", then im getting an Error-box

error.png i can set the JNZ to that adress( the memonic is set on 7FEEA0E5E85),

its also not possible to assemble for example to "jz 7FEEA0E5EAE" - im getting the same problem there, so in fact the same error-box.

do i edit it with the hexeditor that way the target works fine, so i am doing definitely nothing stupid. (cant post the target here, its a commercial one im reversing for myself and also to save the company)

Indeed, this is not possible. The limitations of the assembler can be found here: https://bitbucket.org/mrexodia/xedparse I might fix this some day, but it's not really on my priority list right now.

Greetings,

Mr. eXoDia

[Artic]

1) yea.. right

2) Could you make some screenshots/video of this? I cannot reproduce it. Are you by any chance debugging a DLL and then you try to debug the same DLL again?

3) As long as you don't find any other references, you can find the strings under the tab 'References' (Alt+R).

4) Thanks for reminding me of this, it happens when you find strings twice and then start searching. I forgot to remove a few columns from the searchlist (the list you see has a hidden list above it, the search list. It's just a duplicate, this is because in this way it's not needed to store the original list somewhere). It is now fixed in the source code and will be fixed on the next release.

5) This is currently not build-in in x64dbg, but I will make a small plugin that does this soon.

 

Glad to hear it worked well

6) They are the same source code, so any problems you find *should be* the same for both the x32 and x64 version, as long as the problem is not related to a library (TitanEngine sometimes behaves a little strange on different architectures). Indeed, this is not possible. The limitations of the assembler can be found here: https://bitbucket.org/mrexodia/xedparse I might fix this some day, but it's not really on my priority list right now.

Greetings,

Mr. eXoDia

1) yeah turns out there were a few more points, so im not high or drunk

 

2) yes i can do later and upload here and yes im debugging exe with dll and both do not start. yes the same dll. i will do later a screenrecording.

 

3) dnam yeah i restarted the target and then searched again. my bad

 

4) perfect, thanks! looking forward to the upgrade, hope users do also bughunting like i do here. its really the 64 assembler i was waiting for. lots of clever ideas, hope you continue that route.

 

5) would make life easier for me, i would code it myself, but i have a lag of skill there, maybe somebody, when more advanced! one step after another.

 

6) this makes the life easier too. ok then i will use hview or something to edit the x64 target, 

by the way its ace to show the plain offset in the breakpoint window, make it easier to find things in hexeditors like hview, so this should it do it for the moment. so no reason to rush it.

 

Currently the parser can be considered reasonably fast, it parses about

200 000 instructions in 1,5 seconds.

 

i noticed this, dnam fast on older machines too, but its freaking fast on my desktop 8core.

 

Greetings

[Artic]

another point i ran into (maybe to dumb )

 

i opened my dll load with an exe-file and set breakpoint in the dll, then i restarted everything and the breakpoint is gone or at least it is not breakpointing on my breakpoint. I am doing something wrong?

i assume it should save the breakpoint somewhere in a debug-file or something? or do i have to save something?

 

EDIT: fixed some typos.

Edited May 20, 2014 by Artic

[mrexodia]

Hey,

This sounds like a strange behavior to me, on my side it works fine. Could you take a look in the db\filename.ddXX file (SQLite format). In the table 'breakpoints' you should see your module name + the breakpoint RVA in decimal.

You could try the command 'dbsave' but it should not matter because this is done automatically when you set a breakpoint somewhere.

Greetings

[Artic]

 

 

2) Could you make some screenshots/video of this? I cannot reproduce it. Are you by any chance debugging a DLL and then you try to debug the same DLL again?

yes i send you pm!

 

well yes the file is saved with the extension *.dd64, look for yourself i included it in the pm, if you want i can also send you the target i have used and ran into that problem.

1.6 alpha is the last version?

 

Greetings,

Artic