flat assembler
Message board for the users of flat assembler.

Index > Heap > I need a set of PE EXE analyzing tools

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
Stuff such as:
* Assembler (got FASM)
* Disassembler
* Debugger
* Hex Editor
* Resources Editor

Which tools do you recommend?

Currently I have: FASM, ResEd. OllyDbg, Dependency Walker, PEiD.
Post 08 Feb 2013, 14:42
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
For serious disassembly work, nothing really beats IDA - but it costs a pretty penny, and dunno if they even sell to individuals these days. Dunno any decent free/cheap alternatives. (Of course there's torrents, but...)

For hex editing, I've come to like HxD - fast, simple, to the point. I also still use Mikael Klasson's HexIt, especially if I need to check opcodes for some short assembly snippets Smile
Post 08 Feb 2013, 15:42
View user's profile Send private message Visit poster's website Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
f0dder wrote:
Dunno any decent free/cheap alternatives. (Of course there's torrents, but...)


IDA Freeware?

The downside is it lacks features supported by newer versions of IDA.[/url]
Post 08 Feb 2013, 15:53
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:39; edited 1 time in total
Post 08 Feb 2013, 15:58
View user's profile Send private message Reply with quote
Fixit



Joined: 22 Nov 2012
Posts: 161
Fixit
Resource Hacker is good.

I am using version 3.6.0.92
Post 08 Feb 2013, 16:13
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
HaHaAnonymous wrote:

No IDA freeware for Linux. Better create your own if you aren't rich (and lazy).


I'm not aware of single Linux program that is similar like IDA freeware.
I think you could use the combination of gdb + ndisasm (NASM's dissassembler) + edb (Evan's debugger) + distorm + objdump + ...

Smile
Post 08 Feb 2013, 16:14
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:39; edited 2 times in total
Post 08 Feb 2013, 16:28
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
HaHaAnonymous wrote:

IDA is available for Windows, MAC and Linux (not cheap). If you don't know.


Yah I'm aware of it. That's why I mentioned "IDA freeware",
which is Windows only, and not the commercial version, which is multi platform. Smile

HaHaAnonymous wrote:

Anyway, I only disassemble programs just to test their accuracy itself. So, I really do not need one.


Me too. I only disassemble program due to curiousity.
Post 08 Feb 2013, 17:33
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
HaHaAnonymous wrote:
ndisasm - This one is really inaccurate. I lost the count of instructions that it "disassembled" completely wrong (eg., "and" instead of "mov"(this is just to illustrate how horrible the "error" was)).


Please supply evidence ... code disassembling badly, and version of NDISASM used Sad
Post 04 Apr 2013, 01:20
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
DOS386 wrote:
HaHaAnonymous wrote:
ndisasm - This one is really inaccurate. I lost the count of instructions that it "disassembled" completely wrong (eg., "and" instead of "mov"(this is just to illustrate how horrible the "error" was)).


Please supply evidence ... code disassembling badly, and version of NDISASM used Sad


You're joking - right? If not have you ever used ndisasm actually on something more than couple of bytes and more complex than flat binary? This is one of most simple disassemblers available - take a look at its source code - so it can't follow more complex execution flows and it does not trace data passing as well. All version of ndisasm are prone to the same problems. If you understand how disassemblers work and how ndisasm is implemented than no evidence is needed.

As for the toolset if you can't afford IDA Pro than I would recommend Immunity Debugger (which is based on Olly) but has integrated Python and some additional python packages like: pydbg and pefile, there are also couple of free and commercial disassemblers implemented in Python.
Post 04 Apr 2013, 12:28
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> You're joking - right?

NO

> If not have you ever used ndisasm actually on something more
> than couple of bytes and more complex than flat binary? This is
> one of most simple disassemblers available - take a look at
> its source code - so it can't follow more complex execution flows
> and it does not trace data passing as well. All version of ndisasm
> are prone to the same problems. If you understand how
> disassemblers work and how ndisasm is implemented
> than no evidence is needed.

Missing the point. This was not about how advanced NDISASM is about reconstructing "complex" stuff (not much), but about incorrect "(eg., "and" instead of "mov"(this is just to illustrate how horrible the "error" was))" results. So I am still waiting for the MOV instruction compiling with FASM and subsequently disassembling into AND with NDISASM.
Post 10 Apr 2013, 13:00
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
DOS386 wrote:

Missing the point. This was not about how advanced NDISASM is about reconstructing "complex" stuff (not much), but about incorrect "(eg., "and" instead of "mov"(this is just to illustrate how horrible the "error" was))" results. So I am still waiting for the MOV instruction compiling with FASM and subsequently disassembling into AND with NDISASM.


Allow me to completely disagree with you Sir.
At this point I must apologize to other users since the rest of discussion will be a bit off-topic. Maybe moving this discussion into another thread will be a good idea.

Before I'll delve further into your statement and explain my point of view on this subject I will allow myself to use your tactics and ask you to provide clear evidence supporting your claim. When you post your example I'll post mine with explanation. Please bear with me for while and be patient because there is a hidden sense in it Wink
Post 10 Apr 2013, 19:59
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:06; edited 1 time in total
Post 10 Apr 2013, 20:41
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
HaHaAnonymous wrote:

It didn't happen with "mov/and" that was just an example.

I don't know, it happened with Linux version which I can't remember.


I treated your previous post with understanding while DOS386 has chosen to treat it literally but lets give him a chance to proof his point using mov/and case. I'm up to the challenge to proof that I did not miss the point Wink
Post 10 Apr 2013, 22:08
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> When you post your example I'll post mine

About what? I didn't claim NDISASM would be broken.

> It didn't happen with "mov/and" that was just an example.
> I don't know, it happened with Linux version which I can't remember.

If you hate NDISASM due to lack of advanced file and code analysis, then why do you whine about something completely different - (inexistent) misdecompilation of MOV into AND ??? Confused

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

http://bugzilla.nasm.us/

http://bugzilla.nasm.us/show_bug.cgi?id=3064376

PS: OBJCONV http://board.flatassembler.net/topic.php?t=10291 is an advanced disassembler ... but on large files it's slow and can even crash ... not sure whether latest version is still affected :-\
Post 13 Apr 2013, 06:42
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
DOS386 wrote:
> When you post your example I'll post mine

About what? I didn't claim NDISASM would be broken.

> It didn't happen with "mov/and" that was just an example.
> I don't know, it happened with Linux version which I can't remember.

If you hate NDISASM due to lack of advanced file and code analysis, then why do you whine about something completely different - (inexistent) misdecompilation of MOV into AND ??? Confused

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

http://bugzilla.nasm.us/

http://bugzilla.nasm.us/show_bug.cgi?id=3064376

PS: OBJCONV http://board.flatassembler.net/topic.php?t=10291 is an advanced disassembler ... but on large files it's slow and can even crash ... not sure whether latest version is still affected :-\


First of all I'd like to ask you not to quote my post partially in such way that they are out of context in the future. Thank you in advance!

You could not accept that ndisasm can not provide accurate results due to its limitation and how it has been designed yet you failed to show example backing up your claims (that ndisasm is always disassembling MOV instruction correctly) while asking for an evidence everyone also who disagrees with you. Instead you have posted a number of links related to bug reporting.

Please accept the fact that disassembly quality is not only limited to proper byte to instruction translation. Since you clearly do not understand either my posts (ability to read is not equal to ability to read with understanding) or this particular subject I would recommend reading great "Reversing" book http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817/ref=sr_1_1?ie=UTF8&qid=1365882849&sr=8-1&keywords=reversing which contains a whole chapter on disassemblers internals.

Below is a simple file compiled with fasm. If you will be able to provide original source code in fasm format using only ndisasm (you can skip format and stack directives as well as import table section) and use no other tools or manual actions I will admit I missed your point, all I've written so far is irrelevant and you are right. When posting your solution please describe every single step you took to achieve the success. Without providing such description I will assume you did not complete the challenge successfully. After you provide your answer I will post original source code I've used so every one could see if the answer is correct or not. Please note that the is no encryption/compression used and all PE file structures were left intact just like fasm created them.

Next do one more thing: fire up IDA - I made it easy for you since you might not posses IDA licence as it is commercial product - and the file is in PE file format which is supported by freeware version. Compare the listings and the results quality. Not to mention all the errors in disassembly can be corrected manually in case of IDA.

If you will really do all of those exercise you will understand why people see bad disassembly listings using simple disassemblers like ndisasm.

Secondly as an x86 asm expert you should be aware that on x86 architecture there is no accurate way of distinguishing data from code and vice versa which poses serious troubles to all disassemblers. Therefore you simply could not provide a stream of bytes and disassemble it with ndisasm and say it is correctly disassemble "MOV" instruction because this could be data!

Last but not least: I don't see anyone around whining or hating ndisasm. In fact I never wrote anything like this. I've just described how it works. Many others simple disassemblers expose exactly the same set of problems. So if you would provide other example than ndisasm disassembler I'd point out the same issues.


Description: Simple disassembler test in PE file format
Download
Filename: disasmtestpe.zip
Filesize: 453 Bytes
Downloaded: 88 Time(s)

Post 13 Apr 2013, 20:29
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
ACP wrote:
First of all I'd like to ask you not to quote my post partially in such way that they are out of context in the future. Thank you in advance!


AFAIK I didn't do it in a way manipulating your claims into the opposite Smile

> You could not accept that ndisasm can not provide accurate results

Missing the point

> that ndisasm is always disassembling MOV instruction correctly)
> while asking for an evidence everyone also who disagrees with you

HaHa posted a deliberately false and invalid BUG report, up to him to start providing evidence (or you if you want to defend him ...)

> Instead you have posted a number of links related to bug reporting

Because HaHa's "BUG report" heavily sucks Sad

> Please accept the fact that disassembly quality is not only limited
> to proper byte to instruction translation.

see HaHa's post

> Since you clearly do not understand either my posts (ability
> to read is not equal to ability to read with understanding)
> or this particular subject

This is a rude false accuse, you persist missing the point and defending HaHa's "arguments" against NDISASM

> I would recommend reading great "Reversing" book
> Reversing-Secrets-Engineering-Eldad-Eilam
> which contains a whole chapter on disassemblers internals

Thanks ... but it doesn't make HaHa's post less bad Wink

> Below is a simple file compiled with fasm. If you will be able
> to provide original source code in fasm format using only ndisasm
> (you can skip format and stack directives as well as import table
> section) and use no other tools or manual actions I will admit
> I missed your point

Code:
if 1

format binary as "BIN"
use32
org $0040'1000

; NDW -b 32 crap.bin -o $00401000

; 0040'1000  FF31
; 0040'1002  C0EB03
; 0040'1005  FEC3
; 0040'1007  FF
; 0040'1008  EBFC
; 0040'100A  CDB8
; 0040'100C  15104000FF
; 0040'1011  E0FE
; 0040'1013  81FFBB011040
; 0040'1019  00FF
; 0040'101B  D36A00
; 0040'101E  FF1540204000

push dword [ecx]
shr bl,3
inc bl
db $ff
jmp short $0040'1006
int $b8
adc eax,$ff004010
loopne $0040'1011
cmp edi,$4010'01bb
add bh,bh
; shr dword [edx+0],cl
db $D3,$6A,0 ; No way to disable FASM's optimization
call dword [$0040'2040]

else

format binary as "BIS"
use32
org $0040'1000

; NDW -b 32 crap.bin -o $00401000
; -s $0040100B -s $00401015 -s $00401001 -s $00401006

; 0040'1000  FF
; 0040'1001  31C0
; 0040'1003  EB03
; 0040'1005  FE
; 0040'1006  C3
; 0040'1007  FF
; 0040'1008  EBFC
; 0040'100A  CD
; 0040'100B  B815104000
; 0040'1010  FFE0
; 0040'1012  FE
; 0040'1013  81
; 0040'1014  FF
; 0040'1015  BB01104000
; 0040'101A  FFD3
; 0040'101C  6A00
; 0040'101E  FF1540204000

db $ff
xor eax,eax
jmp short $0040'1008
;-------------------
db $fe
ret
;--
db $ff
jmp short $0040'1006
;-------------------
db $cd
mov eax,$0040'1015
jmp eax
;------
db $fe
db $81
db $ff
mov ebx,$0040'1001
call ebx
pushd 0
call dword [$0040'2040] ; ExitProcess AKA F**K-OFF Wink
;----------------------

end if
    


The result is 100% correct Smile (the upper one is ugly but it's not a BUG of NDISASM)

> please describe every single step you took to achieve the success

0. Get NASM package
1. RTFM
2. Cut $24 hot Byte's from the PE
3. Disassemble it
4. Load result into FASMD and fix remaining cosmetic code issues
5. Compile
6. MD5 the 3 files
7. WOW!!! WOW!!! WOW!!! WOW!!! WOW!!! WOW!!! They are identical !!!

> I will assume you did not complete the challenge successfully

Feel free to. You haven't provided the evidence of NDISASM misdecompilations (MOV->AND or whatever else) yet anyway.

> After you provide your answer I will post original source code

Please do

Quote:
Please note that the is no encryption/compression used and all PE file structures were left intact just like fasm created them.


Right Smile

Quote:
Next do one more thing: fire up IDA - I made it easy for you since you might not posses IDA licence as it is commercial product - and the file is in PE file format which is supported by freeware version. Compare the listings and the results quality. Not to mention all the errors in disassembly can be corrected manually in case of IDA


Please post your results ... I don't have IDA installed Shocked

> Secondly as an x86 asm expert you should be aware that on x86
> architecture there is no accurate way of distinguishing data from
> code and vice versa which poses serious troubles to all disassemblers.

Right.

> say it is correctly disassemble "MOV" instruction because this could be data

The disassembler can be correct, even if "disassembling" data Wink

Quote:
if you would provide other example than ndisasm disassembler I'd point out the same issues


Conclusion: ACP is affiliated with IDA company Sad

OBJCONV result (better):

Code:
extern ExitProcess                                      ; near; kernel32.dll

SECTION .text   align=1 execute                         ; section number 1, code

        push    dword [ecx]                             ; 00401000 _ FF. 31
        shr     bl, 3                                   ; 00401002 _ C0. EB, 03
        inc     bl                                      ; 00401005 _ FE. C3
?_001:
; Error: Illegal operands for this opcode
;       jmp     UNKNOWN REGISTER TYPE 3                 ; 00401007 _ FF. EB
        db 0FFH, 0EBH

;       cld                                             ; 00401009 _ FC
        db 0FCH
; Error: Instruction extends beyond end of code block
; Note: Function does not end with ret or jmp
;       int     -72                                     ; 0040100A _ CD
        db 0CDH

Entry_point:; Function begin
        mov     eax, ?_002                              ; 0040100B _ B8, 00401015(d)
        jmp     eax                                     ; 00401010 _ FF. E0
; Entry_point End of function

        db 0FEH, 81H, 0FFH                              ; 00401012 _ ...
?_002:  mov     ebx, Unnamed_1_1                        ; 00401015 _ BB, 00401001(d)
        call    ebx                                     ; 0040101A _ FF. D3
        push    0                                       ; 0040101C _ 6A, 00
        call    near [imp_ExitProcess]                  ; 0040101E _ FF. 15, 00402040(d)
    


And finally your full original code is back:

Code:
; Crappy code by "ACP"

; 4 viral points Smile))

; http://virustotal.com/file/b4d9c29355a437257b849a053359437e21a049c8c
; c9c8433225a48da11b9ba86/analysis/1366031204/

; http://board.flatassembler.net/topic.php?t=15078

; Misaligned jump targets and garbage inside code will break
; CPU's runtime optimization ... COOOOOOOOOOOL Smile

; This code does absolutely nothing except generating 4 viral
; points and wasting your HD space Smile

format PE console ; PE = Penis Enlargement http://en.wikipedia.org/wiki/PE

; WARNING : "format PE" creates a faulty MZ stub !!!
; WARNING : "format PE" creates bloated binaries !!!
; WARNING : "format PE" can brew PE header, sections and relox
;           (not used here), but it can't brew exports and imports !!!

entry mess0 ; Let's bug evil DOS386

include "import32.inc" ; Include files suck ... that why I use them

section '.text' code readable executable ; bloatable

  db $FF ; BLOAT CRAP

mess2:

  xor eax, eax    ; MOVNTQ EAX,0
  jmp short mess3 ; Let's bug even more the very evil DOS386
  ;--------------
  db $FE ; BLOAT CRAP

mess4:

  ret ; rat
  ;--
  db $FF ; BLOAT CRAP

mess3:

  jmp short mess4 ; Let's drive DOS386 into insanity
  ;--------------
  db $CD ; BLOAT CRAP

mess0:

  mov eax, mess1
  jmp eax ; Let's bug more evil DOS386
  ;------
  db $FE,$81,$FF ; BLOAT CRAP
  ; wrtsc ; Commented out as it DOESN'T COMPILE for unknown reasons !!!

mess1:

  mov   ebx, mess2
  call  ebx ; Let's bug even more evil DOS386
  pushd 0
  call  dword [ExitProcess] ; F**K OFF !!!
  ;------------------------

section ".idata" import data readable ; f**kable too

  library kernel32,"kernel32.dll" ; IIRC orig 80386 manual said "KERNAL"

  include "kernel32.inc" ; Include files suck ... that why I use them
    

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 15 Apr 2013, 13:36
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
Dear DOS386,
First of all I would like to make one thing clear: I'm not and actually have never been employee or contractor to DataRescue and Hex-Rays. The only connection is the fact I'm using their products for many years already and I have to pay for them like everyone else. I would like to ask you kindly to either provide evidence backing up your claims or not make any false accusation further. Stating false accusation without any evidence is actually an offence and illegal activity in many countries.

I have no idea why have you used my test case file on VirusTotal since this is completely - quoting one of your favorite answers - irrevelant to the whole discussion. Could you please explain what VirusTotal has to do with disassemblers? Actually you could also run my file with AppVerifier from MS and say that is not completely MS Windows compatible for example. Please understand that the code I've posted was a test case. Your action is actually an interesting experience for me and next time I'll post some test case or code sample I'll think twice before doing it. After all what is the point of sharing code and knowledge when users don't know how to handle test files or examples and abuse it by posting comments like "ACP crap code". I would really appreciate if you could sustain from such (personal) attacks, especially when you do not understand the topic. Otherwise wise people may stop posting here. I also believe that forum moderators should abstain from personal attacks on forum users but I guess our code of ethics differs.

Now we can come back to the main topic. Obviously you do not understand what "manual" phrase means or you broke this little challenge rules deliberately. Anyway I will not spend more time trying to explain to you topics like "linear sweep disassembler" because this is waste of time. I'm kind of sorry because we could have really interesting discussion about disassemblers inetrnals. I know I would like such.

As promised here is my original source code - anyone can now compare it with your results:

Code:
format pe console
entry _start

include 'win32a.inc'

section '.text' code readable executable
db 0ffh
proc_addr:
        xor eax,eax
        jmp loc
        db 0feh
@@:
        ret
        db 0ffh

loc:
        jmp @b
        db 0cdh

_start:
        mov eax,jump_addr
        jmp eax
        db 0feh
        db 81h
        db 0ffh
jump_addr:
        mov ebx,proc_addr
        call ebx
        invoke ExitProcess,0

section '.idata' import data readable
library kernel, 'kernel32.dll'

import  kernel,\
        ExitProcess, 'ExitProcess'

    


As you can see the aim of the code is to test how particular disassembler works with one of most trivial disasembly desynchronization techniques. Contrary to your comments there is no madness and the objective was not to drive you insane but to test the disassembly algorithm implementation. Your second example seems to be identical to my code but you have not achieved it with ndisasm only since you clearly state (please don't change your post!) that you had fixed it up in fasmd. So to summarize it: you are obviously not interested in on-topic discussion instead try to directly attack people, offending them and write accusations you can not back up with one single evidence. To blur your answers you introduce totally irrelevant facts (like VirusTotal case or commenting disassembler test case that it breaks optimization which if you would understand the topic knew was completely irrelevant) mishandling provided examples and not understanding or deliberately ignoring what has been written if it is contrary to your opinion. The sad part is that nobody here hates ndisasm and if you would think about it for a second it would be kind of stupid for someone posting on fasm forum who is using fasm to dislike other open source project - don't you think? In the whole discussion the only person who personally attacked others, used words like "hate" etc is you and only you.

The one thing I really like about your answers is the fact that you acknowledge at least the problem of distinguishing code from data yet you have not commented on it from ndisasm perspective. Obviously you couldn't since ndisasm can't handle such cases but as an "x86 asm" expert you could not denied it:
Quote:

> Secondly as an x86 asm expert you should be aware that on x86
> architecture there is no accurate way of distinguishing data from
> code and vice versa which poses serious troubles to all disassemblers.

Right.


Yet you keep ignoring the fact that quality of disassembly is partly base on this property of the automate you use.

Anyway I will not waste more of my time trying to convince you. If you want to take it further from this point please use PM since I doubt other users like to read false accusations, wrong conclusions and not on-topic discussion.
Post 15 Apr 2013, 20:22
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
ACP wrote:
I would really appreciate if you could sustain from such (personal) attacks, especially when you do not understand the topic.


it was you who had started with such (personal) attacks:

ACP wrote:
Since you clearly do not understand either my posts (ability to read is not equal to ability to read with understanding) or this particular subject


and it was Haha who had started with false accusations (against NDISASM) and wrong conclusions:

HaHaAnonymous wrote:
ndisasm - This one is really inaccurate. I lost the count of instructions that it "disassembled" completely wrong (eg., "and" instead of "mov"(this is just to illustrate how horrible the "error" was)).


and you are defending him with:

ACP wrote:
You could not accept that ndisasm can not provide accurate results


You are deliberately messing together 2 "problems" using your pet word "accurate" :

- [1] many horrible misdecompilations in NDISASM

- [2] lacking advanced functionality in NDISASM compared to IDA

The problem of "problem" [1] is that it most likely doesn't exist (up to you or Haha to provide evidence of existence of BUG), and the problem of "problem" [2] is that it's not a bug and doesn't make Haha's deliberately false and invalid "bug report" better, it's pretty unrelated and irrelevant to [1].

ACP wrote:
Yet you keep ignoring the fact that quality of disassembly is partly base on this property of the automate you use.


No I don't: correctness of disassembly <> quality of disassembly

Anyway, this thread is done for me.

EOD
Post 17 Apr 2013, 09:24
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
OzzY wrote:

* Debugger


We can't forget about WinDbg (including console debuggers from the same packge) from Microsoft supporting both 32 and 64 bit platforms. However it can be hard to use for first time and it's UI can be nightmare but in some cases this is the tool I use especially if you consider ring 0 debugging or 64 bit apps debugging.
Post 17 Apr 2013, 09:41
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.