stricmp
in [ASM]
|
From: Evenbit on 12 Mar 2005 03:27 Sevag Krikorian wrote: > Evenbit wrote: [snip] > > fileio.position( fOpen ); > > mov( eax, prelocat ); > > Why do this? Just set prelocat to 0. Is operand-to-memory faster than register-to-memory? Anyways, I was letting the program logic document itself. > > > mem.alloc((type dword 1024)); > > mov( eax, myBuff ); > > Why type dword here? Anyway, your buffer is small > enough... use the stack instead. Uh... I guess I got a little paranoid about needing to type cast. Yeah, the stack will work for this example, but I was interested in investigating heap usage as well as fileio with this exercise. > > > 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. Yeah, I had forgotten about that. Cramed a little too much reading material into my head a little bit too fast... > > > 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. So I should have done a "mov(myBuff, esi)" and then stuck "[esi]" in here? [snip] > Here is a working procedure: Yep. That works! Thanks a billion! I thought this program would send me to the looney-bin for sure. [snip] > Using "rol" of course unscrambles the file. ROR does too. > 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. Uh... the current "ror" incarnation does that. Let me diagram it: al = 00001111 Do a ror(4, al) al = 11110000 Do another ror(4, al) al = 00001111 I just ran this Kain-Quick-File-Scrambler in several directories on my machine and it works like a charm! Nathan.
From: Evenbit on 12 Mar 2005 04:20 Frank Kotler wrote: > 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! It takes practice, patience, lots of reading, more practice.. etc.. Yes, it seems a little over-complicated for an assembly language (especially one aimed at beginners), but I doubt that that can be avoided when cramming a lot of powerfull high-level features into a low-level language. The more I play with it, the more I am convinced that HLA is, in reality, Randall's answer to C/C++ (and that both C and C++ had to have been written by someone named Doctor Jeckell because there is absolutely NO DOUBT that HLA was written by a Mister Hyde <grin>). > > 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! Must be a linux issue... > So now, ecx increases until gawd-knows-what value... likely > causing your access violation. No, the police report claims that the memory was violated on the first cycle of the loop. Like Sevag said, ebx gets corrupted before I even start to fetch from memory. > 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. Okay, I'll start the account as long as you promise not to start glueing fly eyes onto my head. ;-) > Well, either way works... But "Ollydbg" sounds like you're > doing Windows... Well SORRY!!! I know I'm a big sinner for developing for a Microsoft OS and having the nerve to pop my head into this group. I suppose I should leave this group in shame, with my head hanging low, and crawl over to NASM while I await the all-powerful Lusaxm. > > 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... True, he side-stepped the issue, so to speak. Nathan.
From: Sevag Krikorian on 12 Mar 2005 04:28 Evenbit wrote: > Sevag Krikorian wrote: > >>Evenbit wrote: > > [snip] > >>> fileio.position( fOpen ); >>> mov( eax, prelocat ); >> >>Why do this? Just set prelocat to 0. > > > Is operand-to-memory faster than register-to-memory? Anyways, I was > letting the program logic document itself. > I'm not too sure on that, but 'mov (0, prelocat)' is faster than using fileio.position first. Also, I don't think fileio.position can be trusted as soon as you open a file so to be sure, you would have to do "fileio.rewind (fOpen); fileio.position(fOpen);' I've had some problems with this before. > >>> mem.alloc((type dword 1024)); >>> mov( eax, myBuff ); >> >>Why type dword here? Anyway, your buffer is small >>enough... use the stack instead. > > > Uh... I guess I got a little paranoid about needing to type cast. > Yeah, the stack will work for this example, but I was interested in > investigating heap usage as well as fileio with this exercise. > > >>> 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. > > > Yeah, I had forgotten about that. Cramed a little too much reading > material into my head a little bit too fast... > > >>> 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. > > > So I should have done a "mov(myBuff, esi)" and then stuck "[esi]" in > here? > Yup. Personally, I would prefer if everything was just "pass address by value" and let the procedure figure out what to do with them, but alas, that was not to be. > [snip] > >>Here is a working procedure: > > > Yep. That works! Thanks a billion! I thought this program would send > me to the looney-bin for sure. > > [snip] > >>Using "rol" of course unscrambles the file. > > > ROR does too. > Duh! Your right. I was on a 'dword' mental state. NOT is quicker though, unless I'm mistaken. > >>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. > > > Uh... the current "ror" incarnation does that. Let me diagram it: > > al = 00001111 > > Do a ror(4, al) > > al = 11110000 > > Do another ror(4, al) > > al = 00001111 > > I just ran this Kain-Quick-File-Scrambler in several directories on my > machine and it works like a charm! > > Nathan. > -- [kain] http://www.geocities.com/kahlinor
From: Evenbit on 12 Mar 2005 04:30 FK> Well, I can't get HLA to assemble this as-is - wants a "DoOneValStmt"... EB> This procedure plugs into that "filter.hla" example downloadable from Webster {is that a nest-weaving reference or a word-finding reference? <grin>} and it #includes a "filter.hhf" file which defines and protos some Windows file operation APIs -- so it isn't going to work on Linux. Nathan.
From: Sevag Krikorian on 12 Mar 2005 04:41
Frank Kotler wrote: > 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! > HLA Linux has more bugs due to a smaller user base reporting them :) > >>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) > ---------------------- > > 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. > It sure seems that way. This might be something to bring to Randall's attention. >> 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. > Yes, in Linux, you would likely get a strange result here. > > 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. > Windows rules! ;) > 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... Humm, I thought I covered that when I mentioned fileio.read expects a pointer to byte. Sorry if I wasn't clear. > >>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 Methinks somebody has been curling up with a Douglas Adams novel. -- [kain] http://www.geocities.com/kahlinor |