.EXE -> .ASM -> .EXE
in [ASM]
|
Prev: HLA
Next: cygwin/nasm woes
From: Ben on 29 Jun 2006 19:33 Betov wrote: > This is not, at all, the problem, Ben. If you had been a bit > more serious in your own work, you would know that the main > problem with Disassembling PEs, is about identifying what is > Code vs what is Data. This is a terrific and never ended problem, > and, in case of failure, looking at the "others' outputs" is > much helpfull for saving search time. i was not referring to the Code.vs.Data problem. i was referring to the engine it self. Ollydbg's available open source code is filled with disasm errors. and this goes the same to the ollydbg DE as self. i have tested some opcodes (plain opcodes - series of bytes) and i got bad results in it > > i must say that "PVDasm will fade in the current months" is pretty a > > strong statement, on what grounds have you based that? > > On the fact that you took some "diagonal" road to try to make > a room to your production. and which road is that? just because masm is included as a source code wizard? i would love to hear your theory, when it comes to PVDasm, it is not designed to be for one thing, it is in my mind the most 'free work' disassembler out there. PVDasm includes code freedom and user freedom (ideas and features). it doesn't enforce X on you. and if you think otherwise, mabye its because i haven't implemented this feature yet. > From scratch, writing a Disassembler in C, is a very strange > idea, that usualy goes where the strange ideas are used to go. some would say about ASM as well. personally there is no rule of telling you to write a software in language X. actually i would say the same for you: "From scratch (??), writing a Disassembler in ASM, is a very strange idea, why not code in BINARY than?." > > i think that everyone has it's own set of tools which he can use > > together to perform the best analysis. > > Not sure of what you wish to mean, here... meaning that i do not force PVDasm on others with the options its got. i just state what its capabilities. it is upto the user to decide whenever he wants to use it for his task. pvdasm if u didn't know can be linked with IDA (for example) to give a better support to the user while mixing the two. so as i said, more tools the better analysis the person does. btw note that i do not try to bash or flame your RosASM tool becuase i think that any tool that is out there is worth being used or tried. and it always helps to share information. i do not believe in saying to ppl that thier product is bad or something alike, because it doesn't serve my point: "share and learn".
From: Eman on 30 Jun 2006 09:55 "santosh" <santosh.k83(a)gmail.com> ???????/???????? ? ???????? ?????????: [.. long part ..] "Yes, of course", mostly :) >> The next part, the same effect can be achieved with a hll+asm >> mixing. The loss is, you need to link several object outputs. >> The gain is, you can write non-critical parts of your code >> faster, you can use standard C or another HLL for such parts >> of code, so that they can be easy reused. Secondly, you can >> optimize the critical assembly parts of your code finely, and >> shape them in pure notation, so that they can be easy reused >> with another assembler. > > This exactly what most software developers do, and this is the > programming paradigm that is opposed by Betov. > > He argues the exact opposite of what you argue. That assembly should > *never* be micro-optimised and that the whole application should be > written in assembly and specifically that assembly routines should not > be made available/linkable to HLL parts of the code. > > You might try taking your case to him :) As to Betov, afair he explained quite plainly that his stuff is destined for ReactOS, but not for Windows. It seems to be enough to understand his programming paradigm. >> The only case i find expedient for usage of true assembly code >> is an implementation of some algorithm, where you have not the >> necessity to call heavy HLL-written functions (trusted assembly- >> written library code is not the case). Since you are an "asmer" >> and this code is assembly code entirely, you can make it really >> great. Otherwise it would be a "casting pearls to hogs" ;) >> That's what about the expediency. > > Hmmm... that would probably be possible only in the embedded area. > Under desktop and server computers, if you do any I/O at all, you'll > end up calling tons of HLL code. I'm not aware of any assembly library > that completely replaces the need to call library or OS code. [..] > However you seem to be saying that using assembly is pretty much > useless, unless all the support code is also "trusted", optimised > assembly. > > This seems to me to be neither a practical statement nor one reflective > of reality. "Numerical computing" and "multimedia", "encodings" and "translations", "parsing" and "tokenizing", encryption and compression, dynamic data structures.. Lot of pretty useful stuff can be done without system API calls. There might be reasons to program such things in assembly by hand depending on what exactly the program is supposed to do and what's considered to be its benefits. Secondly, as you said, the things are not so "Black and White" as one makes out to be. There are also a quite light system APIs in Windows, so that a usage of them will not obliterate your asm goals. Maybe it's useful to differentiate these things properly (sometimes using a disassembler).
From: randyhyde@earthlink.net on 30 Jun 2006 11:53 Eman wrote: > > As to Betov, afair he explained quite plainly that his stuff is > destined for ReactOS, but not for Windows. It seems to be enough > to understand his programming paradigm. > Or, at least, to realize that you'll never understand his (il)logic. :-) Cheers, Randy Hyde
From: sevagK on 30 Jun 2006 23:17 santosh wrote: > sevagK wrote: > > Frank Kotler wrote: > ... snip ... > > > > That would explain it... but that would be incredibly dumb. I can > > > confirm that it happens. Worse yet - it doesn't need printf. A simple > > > call to "write()" shows the same effect (approximately). Dumb things > > > happen, I guess. I don't know that this spells the end of static > > > linking, but I won't be linking libc statically again soon!!! > ... snip ... > > > Well, there is one excuse I can think of. > > -Practically all programs in Linux make use of libc (or are expected > > to), so it makes sense to have one object file to load into memory and > > use dynamic linking. > > Programs that want to statically link to avoid the high costs of > > process switching have to live with the bloat. > > Huh!? Correct me if I'm wrong but how would a dynamically linked libc > cause more process switching than a statically linked one? > > My understanding is that the entire libc is mapped by the OS's VM > system into the address space of each process that uses it. Since > calling libc involves calling routines at the same privilege level, why > should process switching occur? > > Of course, libc itself calls the OS, causing a context switch. But this > is exactly the same for both static as well as dynamic libc. > > Maybe I'm not understanding something here. Do you mean 'process > switching' or 'context switching'? I don't see why a dynamically linked > libc should incur higher amounts of either over statically linked one. Could be or not. I remember a benchmark I did a while back where I tried both kinds of linking and the static linked program performed the function call a little faster. This could've been an anomaly. I took it for granted as it was the expected result in my mind and I didn't try any other tests. If it is not the general case, then it would be useful to know. My Linux box is down for now so I can't perform any more tests until I get up and running again. -sevag.k www.geocities.com/kahlinor
From: Betov on 13 Jul 2006 07:53
"Ben" <shanytc(a)gmail.com> ?crivait news:1151624005.686960.15570 @d56g2000cwd.googlegroups.com: > Betov wrote: > >> This is not, at all, the problem, Ben. If you had been a bit >> more serious in your own work, you would know that the main >> problem with Disassembling PEs, is about identifying what is >> Code vs what is Data. This is a terrific and never ended problem, >> and, in case of failure, looking at the "others' outputs" is >> much helpfull for saving search time. > > i was not referring to the Code.vs.Data problem. i was referring to the > engine it self. > Ollydbg's available open source code is filled with disasm errors. and > this goes the same to the ollydbg DE as self. > i have tested some opcodes (plain opcodes - series of bytes) and i got > bad results in it These are easy _details_. Why don't you report to Olly, instead of saying that it is faultive? >> > i must say that "PVDasm will fade in the current months" is pretty a >> > strong statement, on what grounds have you based that? >> >> On the fact that you took some "diagonal" road to try to make >> a room to your production. > > and which road is that? Diversification in the direction of a Web engine. > just because masm is included as a source code > wizard? Oh! _YES_, too... What a shame... > i would love to hear your theory, when it comes to PVDasm, it > is not designed to be for one thing, ?... > it is in my mind the most 'free > work' disassembler out there. ???!!!... Since when is it under GPL? > PVDasm includes code freedom and user freedom (ideas and features). it > doesn't enforce X on you. > and if you think otherwise, mabye its because i haven't implemented > this feature yet. ? >> From scratch, writing a Disassembler in C, is a very strange >> idea, that usualy goes where the strange ideas are used to go. > > some would say about ASM as well. > personally there is no rule of telling you to write a software in > language X. > actually i would say the same for you: > > "From scratch (??), writing a Disassembler in ASM, is a very strange > idea, why not code in BINARY than?." When one writes an Assembler or a Disassembler, he should be, at least, write it in the language he is working with. If you do not see any reason why, well... >> > i think that everyone has it's own set of tools which he can use >> > together to perform the best analysis. >> >> Not sure of what you wish to mean, here... > > meaning that i do not force PVDasm on others with the options its got. > i just state what its capabilities. it is upto the user to decide > whenever he wants to use it for his task. > pvdasm if u didn't know can be linked with IDA One another shame. > (for example) to give a > better support to the user while mixing the two. > so as i said, more tools the better analysis the person does. Agrea. Betov. < http://rosasm.org > |