Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: Charles A. Crayne on 27 Jan 2006 00:36 On 26 Jan 2006 20:45:05 -0800 "Dragontamer" <prtiglao(a)gmail.com> wrote: :I may have not seen this "inform" myself, but if the designers had :half-a-brain, they'd try to keep the language simple and efficient. Inform is not a general purpose language, but rather a compiler for a virtual architecture known as a 'z-machine', which was designed about 35 years ago for the specific purpose of providing portability across a number of hardware platforms. The complexity arises from the fact that the virtual machine itself was designed specifically for text adventure games. Here is a brief sample of Inform code: Prop o14 "fount" r15 with name 'fountain' 'fount' 'basin', describe [; switch(self.ostate) { 0: "There is a lovely marble fountain playing here, full of water."; 1: "The lovely marble fountain is slowly refilling with water."; } ], description "The basin is about twenty feet across and two feet deep. The figures^ in the center are a god and a nymph doing something that I can't^ describe in a family game. The water is deep enough that you can't^ tell if there is anything on the bottom.", ;
From: sevagK on 27 Jan 2006 01:01 Charles A. Crayne wrote: > On Fri, 27 Jan 2006 00:15:02 +0000 (UTC) > Alex McDonald <alex_mcd(a)btopenworld.com> wrote: > > :someCodePtr dd $ ; "pointer to self" address > :someCode ... ; code to execute > : > : mov eax, someCodePtr ; fetch the code address > : add eax, # 4 ; point at someCode > : jmp eax ; and call it > : > :What's the problem with it? > > It can be replaced by 'jmp someCodePtr+4' > > -- Chuck I think Rene's intentions are not to convert any assembly code to other processors, but code specificaly written to be portable, in which case all this would be trivial. The real stumper comes not from how the code is written, but how to communicate with the OSes of the various processors... There needs to be a portable library with common function calls available, which is the biggest part of the work. Of course, right away there is a problem with Rosasm users ever making use of such an encoder as DLL's aren't supported across a wide variety of OSes. The only one I know of is Windows/ROS! So he would have to begin support for statically linked libraries/object modules. -sevag.k -=Kain=- www.geocities.com/kahlinor
From: Betov on 27 Jan 2006 04:14 "Charles A. Crayne" <ccrayne(a)crayne.org> ?crivait news:20060126192653.1af4a113(a)heimdall.crayne.org: > Just for the record, how many instances of such structures do you expect > to find in Betov's source code? As many as required by Win32 Programming. :]]]]] Betov. < http://rosasm.org >
From: Herbert Kleebauer on 27 Jan 2006 04:48 Betov wrote: > > As many as required by Win32 Programming. Seems you will get much more time to finish RosAsm: http://www.reactos.org/xhtml/en/news_page_14.html One final note, this audit of the code is going to take a long time. It could take years, but it will happen, this project will come out better than it was before.
From: Alex McDonald on 27 Jan 2006 04:55
Charles A. Crayne wrote: > On Fri, 27 Jan 2006 00:15:02 +0000 (UTC) > Alex McDonald <alex_mcd(a)btopenworld.com> wrote: > > :someCodePtr dd $ ; "pointer to self" address > :someCode ... ; code to execute > : > : mov eax, someCodePtr ; fetch the code address > : add eax, # 4 ; point at someCode > : jmp eax ; and call it > : > :What's the problem with it? > > It can be replaced by 'jmp someCodePtr+4' > > -- Chuck No it can't. 1. You would need to analyse the entire code, not just this fragment, to guarantee that someCodePtr is never modified. 2. You would have to analyse the code to ensure that someCode or its descendants don't require EAX to point at someCode. 3. The address in SomeCodePtr might lie on other than a 4 byte boundary (say, for x86 to MIPS translation) 4. The add changes the flags. Given that we're trying to translate from x86 to another target, then the simple code sequence above is very, very difficult to analyse. Your assumption that jmp will do it is wrong; it doesn't take account of any of these problems. It's inelegance isn't at issue; the ability to mechanically translate it (and much less and more elegant code with similar properties) to another target is the issue. These are some of the reasons why virtual machine emulators are the only way to handle this. -- Regards Alex McDonald |