stricmp
in [ASM]
|
From: Evenbit on 11 Mar 2005 14:36 Frank Kotler wrote: > Evenbit wrote: > > ... > > I can do a "mov( aBuff, ebx )" but then both "mov( al, [ebx > > + ecx] )" and "mov( al, ebx[ecx] )" are illegal. > > When you say "illegal", do you mean HLA won't accept the > syntax, or you get an access violation? This is working fine > for me! Yeah, those must have been access violations. The following works: program bufftest; #include( "stdlib.hhf" ) var testBuff :dword; begin bufftest; mem.alloc(1024); mov( eax, testBuff ); xor( ecx, ecx ); mov( testBuff, ebx ); mov( 55, al ); while((type dword ecx) < (type dword 1024)) do mov( al, [ebx + ecx] ); inc( ecx ); endwhile; mem.free( testBuff ); end bufftest; I guess in my rush to debug, having created multiple versions of the source (and subversions containing fractional pieces of the source) plus perhaps changing more than one item between compile-run cycles, I'd lost track of which HLA scream and which Ollydbg scream was associated with which source. And perhaps I need to make myself a short HLA Quick Reference Guide to help me keep track of syntax DOs and DON'Ts. One project I've been working on is adding functionality to the "filter.hla" proggy in the HLA Examples download. Just add your own "processFile" procedure to make it do powerful things. Thought I'd make it do a Quick-File-Scramble to hide those confidential MS-Office docs from the casual, non-tech-savy, office mate when you step out of the room. Somehow, there is a Memory Access Violation {I can see the headlines now "Programmer arrested on Memory Violation Charges"} when the inner While loop referrences "[ebx + ecx]" and {perhaps I'm not using Ollydbg's full potential, but} I can't detect when EBX is getting corrupted. Here is my current code for that procedure: procedure processFile( filename:string ); var myBuff :dword; fOpen :dword; size :dword; curlocat :dword; prelocat :dword; begin processFile; if( filename = NULL ) then stdout.put( "processFile: NULL" nl ); else stdout.put( "processFile: """, filename, """" nl ); fileio.open( filename, fileio.rw ); mov( eax, fOpen ); fileio.position( fOpen ); mov( eax, prelocat ); mem.alloc((type dword 1024)); mov( eax, myBuff ); while( !fileio.eof( fOpen ) ) do fileio.read( fOpen, myBuff, 1024 ); mov( eax, size ); fileio.position( fOpen ); mov( eax, curlocat ); fileio.seek( fOpen, prelocat ); mov( myBuff, ebx ); mov( 0, ecx ); while( (type dword ecx) < size ) do mov( [ebx + ecx], al ); ror( 4, al ); mov( al, [ebx + ecx] ); inc( ecx ); endwhile; fileio.write( fOpen, myBuff, size ); mov( curlocat, eax ); mov( eax, prelocat ); endwhile; fileio.close( fOpen ); mem.free( myBuff ); endif; end processFile; Any ideas? Yes, Frank...I know! I know! I should have tucked in some "Here we are!" code and "this register is such" code and all the appropriate exception handling code but I tend to be the Rapid-Dev type focusing on the app logic and I know I can get the "Here we are" and "register is such" answers from Ollydbg, so... I guess I'll just suffer the consequences when Beth the quantom sourcerous causes that elephant to appear over my head. ;-) Nathan.
From: Sevag Krikorian on 11 Mar 2005 22:16 Evenbit wrote: > Frank Kotler wrote: > >>Evenbit wrote: >> >>... >> >>>I can do a "mov( aBuff, ebx )" but then both "mov( al, [ebx >>>+ ecx] )" and "mov( al, ebx[ecx] )" are illegal. >> >>When you say "illegal", do you mean HLA won't accept the >>syntax, or you get an access violation? This is working fine >>for me! > > > Yeah, those must have been access violations. The following works: > > program bufftest; > #include( "stdlib.hhf" ) > > var > testBuff :dword; > > begin bufftest; > > mem.alloc(1024); > mov( eax, testBuff ); > xor( ecx, ecx ); > mov( testBuff, ebx ); > mov( 55, al ); > while((type dword ecx) < (type dword 1024)) do > mov( al, [ebx + ecx] ); > inc( ecx ); > endwhile; > mem.free( testBuff ); > > end bufftest; > > I guess in my rush to debug, having created multiple versions of the > source (and subversions containing fractional pieces of the source) > plus perhaps changing more than one item between compile-run cycles, > I'd lost track of which HLA scream and which Ollydbg scream was > associated with which source. And perhaps I need to make myself a > short HLA Quick Reference Guide to help me keep track of syntax DOs and > DON'Ts. > > One project I've been working on is adding functionality to the > "filter.hla" proggy in the HLA Examples download. Just add your own > "processFile" procedure to make it do powerful things. Thought I'd > make it do a Quick-File-Scramble to hide those confidential MS-Office > docs from the casual, non-tech-savy, office mate when you step out of > the room. Somehow, there is a Memory Access Violation {I can see the > headlines now "Programmer arrested on Memory Violation Charges"} when > the inner While loop referrences "[ebx + ecx]" and {perhaps I'm not > using Ollydbg's full potential, but} I can't detect when EBX is getting > corrupted. Here is my current code for that procedure: > > procedure processFile( filename:string ); > > var > myBuff :dword; > fOpen :dword; > size :dword; > curlocat :dword; > prelocat :dword; > > begin processFile; > > if( filename = NULL ) then > > stdout.put( "processFile: NULL" nl ); > > else > > stdout.put( "processFile: """, filename, """" nl ); > fileio.open( filename, fileio.rw ); > mov( eax, fOpen ); > fileio.position( fOpen ); > mov( eax, prelocat ); Why do this? Just set prelocat to 0. > mem.alloc((type dword 1024)); > mov( eax, myBuff ); Why type dword here? Anyway, your buffer is small enough... use the stack instead. > while( !fileio.eof( fOpen ) ) do In the stdlib manual, it is suggested that you use a try/endtry exception to capture the end of file. > fileio.read( fOpen, myBuff, 1024 ); I think fileio.read expects a pointer to byte as the second parameter. Here is where "myBuff" is getting scrambled. > mov( eax, size ); > fileio.position( fOpen ); > mov( eax, curlocat ); > fileio.seek( fOpen, prelocat ); > > mov( myBuff, ebx ); > mov( 0, ecx ); > while( (type dword ecx) < size ) do ecx is already a dword. Easy on the type casting :) > mov( [ebx + ecx], al ); > ror( 4, al ); > mov( al, [ebx + ecx] ); > inc( ecx ); > endwhile; > > fileio.write( fOpen, myBuff, size ); > mov( curlocat, eax ); > mov( eax, prelocat ); > endwhile; > fileio.close( fOpen ); > mem.free( myBuff ); > > endif; > > end processFile; > > Any ideas? Yes, Frank...I know! I know! I should have tucked in some > "Here we are!" code and "this register is such" code and all the > appropriate exception handling code but I tend to be the Rapid-Dev type > focusing on the app logic and I know I can get the "Here we are" and > "register is such" answers from Ollydbg, so... I guess I'll just > suffer the consequences when Beth the quantom sourcerous causes that > elephant to appear over my head. ;-) > > Nathan. > Here is a working procedure: procedure processFile( filename:string ); var charbuf :char[1024]; fOpen :dword; size :dword; curlocat :dword; prelocat :dword; endvar; begin processFile; if( filename = NULL ) then stdout.put( "processFile: NULL" nl ); else stdout.put( "processFile: """, filename, """" nl ); fileio.open( filename, fileio.rw ); mov( eax, fOpen ); mov (0, prelocat ); try forever lea (ebx, charbuf); fileio.read (fOpen, [ebx], @elements (charbuf) ); mov (eax, size); fileio.position( fOpen ); mov( eax, curlocat ); fileio.seek( fOpen, prelocat ); xor (ecx, ecx); while ( ecx < size) do mov ([ebx + ecx], al); ror (4, al); mov (al, [ebx + ecx]); inc (ecx); endwhile; lea (ebx, charbuf); fileio.write (fOpen, [ebx], size); mov (curlocat, eax); mov (eax, prelocat); endfor; exception ( ex.EndOfFile ); fileio.close (fOpen); endtry; endif; end processFile; Using "rol" of course unscrambles the file. Instead of "ror" if you use "not" , you don't have to write an unscrambling routine. Run it once to scramble, run the same file again to unscramble. -- [kain] http://www.geocities.com/kahlinor
From: Frank Kotler on 12 Mar 2005 01:18 Evenbit wrote: .... > Here is my current code for that procedure: Well, I can't get HLA to assemble this as-is - wants a "DoOneValStmt"... Honestly, the more I try to use HLA, the less I like it! > procedure processFile( filename:string ); > > var > myBuff :dword; > fOpen :dword; > size :dword; > curlocat :dword; > prelocat :dword; > > begin processFile; > > if( filename = NULL ) then > > stdout.put( "processFile: NULL" nl ); > > else > > stdout.put( "processFile: """, filename, """" nl ); > fileio.open( filename, fileio.rw ); > mov( eax, fOpen ); > fileio.position( fOpen ); > mov( eax, prelocat ); > mem.alloc((type dword 1024)); > mov( eax, myBuff ); > while( !fileio.eof( fOpen ) ) do > fileio.read( fOpen, myBuff, 1024 ); > mov( eax, size ); I think this is your problem. "fileio.read", as I understand it, is *supposed* to return the number of bytes read, but look at the code! (linux version) ---------------------- procedure fread( Handle:dword; var buffer:var; count:uns32 ); @nodisplay; var BytesRead: dword; begin fread; pushRegs; pushfd(); cld(); push( Handle ); push( buffer ); push( count ); call linux.read; if( eax = -1 ) then raise( ex.FileReadError ); endif; mov( BytesRead, eax ); if( eax = 0 ) then raise( ex.EndOfFile ); endif; popfd(); popRegs; end fread; ----------------------- What in hell is supposed to be going on with "BytesRead"??? As I understand this (and I'm *not* an HLA user, so I could be very confused), eax is returning some uninitialized garbage off the stack. > fileio.position( fOpen ); > mov( eax, curlocat ); > fileio.seek( fOpen, prelocat ); > > mov( myBuff, ebx ); > mov( 0, ecx ); > while( (type dword ecx) < size ) do So now, ecx increases until gawd-knows-what value... likely causing your access violation. > mov( [ebx + ecx], al ); > ror( 4, al ); > mov( al, [ebx + ecx] ); > inc( ecx ); > endwhile; > > fileio.write( fOpen, myBuff, size ); > mov( curlocat, eax ); > mov( eax, prelocat ); > endwhile; > fileio.close( fOpen ); > mem.free( myBuff ); > > endif; > > end processFile; > > Any ideas? Yes. The HLA Standard Library should be put on CVS (or similar) somewhere, so the "million pairs of eyes" can clean up some of the bugs. > Yes, Frank...I know! I know! I should have tucked in some > "Here we are!" code and "this register is such" code and all the > appropriate exception handling code but I tend to be the Rapid-Dev type > focusing on the app logic and I know I can get the "Here we are" and > "register is such" answers from Ollydbg, so... Well, either way works... But "Ollydbg" sounds like you're doing Windows... The Windows version of the library looks okay (from what little I know of Windows... at least "BytesRead" makes sense), so I'm back to not understanding what the problem is... Watch both ebx and ecx, and you'll probably spot it. Sevag's suggestion to use the stack, instead of "mem.alloc" is a good one, but it doesn't solve the problem of what's wrong with *this* code... > I guess I'll just > suffer the consequences when Beth the quantom sourcerous causes that > elephant to appear over my head. ;-) .... "sourceress", you mean :) Best, Frank
From: Annie on 12 Mar 2005 02:30 On 2005-03-12 fbkotler(a)comcast.net said: > ... Honestly, the more I try to use HLA, the less I like it! _____ Duh! ((( `\ _ _`\ ) Welcome to the sunset of HLA's (^ ) ) 'Age of Aquarius,' Frank. Hehe! ~-( ) _'((,,,))) ,-' \_/ `\ ( , | `-.-'`-.-'/|_| \ / | | =()=: / ,' aa --- "HLA.EXE is not an assembler. Indeed, it's not even a compiler, pre-processor (or 'preparser', whatever that is), though it *might* qualify as [a] 'text converter.'" - Randy Hyde, author of 'HLA,' in ALT.LANG.ASM newsgroup -- August 11, 2004
From: Betov on 12 Mar 2005 03:10
Frank Kotler <fbkotler(a)comcast.net> ýcrivait news:423289B9.A0D969F2 @comcast.net: >> Any ideas? > > Yes. The HLA Standard Library should be put on CVS (or > similar) somewhere, so the "million pairs of eyes" can clean > up some of the bugs. :)) :)) :)) :)) :)) Simpler is to put Randall Hyde on the pal he deserves. Let's just hope it would not be... faster. :)) :)) :)) :)) :)) Betov. < http://rosasm.org/ > |