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