home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,764 of 4,675   
   wolfgang kern to Kerr Mudd-John   
   Re: BASE64 again   
   29 Jun 17 21:51:15   
   
   From: nowhere@never.at   
      
   Kerr Mudd-John wrote:   
   ..   
   >> First thing my variant does is to move the unmodified string to 044.   
      
   > I move mine after fixups (do I still need a jmp to reload the cache?   
   > I doubt I'll be putting this on a 486), your way is probably shorter.   
      
   REP MOV after modify shouldn't need a reload (just data), and we need   
   a jmp/ret to 044 after modify anyway. Moving before may not be any   
   shorter but easier to view and act on bp+xx offsets (the true address).   
      
   >> I need three bytes for one single or paired modify to produce 00..20   
   >> and A7..FF by one SUB, but it needs two bytes more to create 7B..A6.   
   >>   
   >> ie:   
   >>  PUSH 0x7761         ;could have used 0x7a61   
   >>  POP AX              ;(4 byte)   
   >>  SUB [bp+..],AL      ;21->C0 66->FB   
   >>  SUB [bp+..],AH      ;21->AA   
   >>  SUB [bp+..],AX      ;two at once   
   >>  ...                 ;(+3 each)   
   >> ;but for 80..        ;(+2 more)   
   >>  SUB AL,0x7a         ;ie: 5B -61-7a = 80   
   >>  SUB [bp+..],AL      ;AX is possible too   
      
   > I'm putting fixup values in cx too. Mostly xor's still.   
      
   I cover all required code with only one PUSH 0x7761-fixup and SUB.   
      
   a handy trick is to arange code for more paired mod options,   
   ie:  jnc +4 |mov al,0x3f   (needs 73 04 B0 3f)   
   here I modify two at once to make 0xB004 from 0x2765-0x7761   
   so the origin is: 73 65 27 3f   
      
   and because we cant use offset 07F to modify for RET (C3),   
   I moved the return to be right after the opposite branch:   
   cmp al,3d |jnz +1 |ret    3c 3d 75 01 c3 (C301 became a pair)   
   and at 07e there is now an EB.. (reachable and also married)   
      
   >>> I'm using direct code for some ; e.g.   
   >>>   
   >>>           ; sub al,'a'-'A'-26   ; a-z ; sub al,6   
   >>>           sub al,0x5A   
   >>>           sub al,0x5A   
   >>>           sub al,0x52          ; whew! -6!   
      
   >> me too replaced a MOV CL,4 with four INC CX (was zero anyway)   
   > Oops, I forgot to set cx. That's another 8 bytes gone!   
      
   I'm quite familiar with things like this ...   
      
   >> would six DEC AX alter your AH ?   
   > No, nice spot, but it's still 6 bytes!   
      
   my SUB-modify would save you one byte here.   
      
   >> I had an ADD AL,06 in my code and replaced it with SUB AL,0xFA.   
   >> This FA is a 5B in the original but modified by SUB 61.   
   >> So only 2+3 bytes instead of 6.   
      
   >> I create FA (-6) with single sub by either "["-"a" or "q"-"w"   
      
   >>> as there's some room for expanding from 50 and 64; I dropped trying to   
   >>> keep it to pure B64.   
      
   >> Yeah, SMC with pure B64 seems impossible or at least heavy detouring.   
      
   >>>> So when I look back to the xor-sub-sub 2:1 and your 50 byte variant   
   >>>> and compare what's required for direct modify with the 2:1 algo, we   
   >>>> may not gain too much :)   
      
   >> wasn't "shorter than this" our previous target ? :)   
      
   > Yes. Just getting this thing working is my current ambition!   
      
   I'm sure that my brain still work on it in the background :)   
   but I see no shorter way at the moment, let's wait a while...   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca