From: james.harris.1@nospicedham.gmail.com   
      
   On 19/07/2017 20:42, Kerr-Mudd,John wrote:   
   > James Harris  wrote in news:oko6rd   
   > $5jr$1@dont-email.me:   
   >   
   >> On 19/07/2017 09:10, Kerr Mudd-John wrote:   
   >>> James Harris  wrote in   
   > news:okm0bq   
   >>> $4vd$1@dont-email.me:   
   >>>   
   >>>> On 18/07/2017 22:34, James Harris wrote:   
   >>>>> On 18/07/2017 19:34, Kerr Mudd-John wrote:   
   >>>>>> "wolfgang kern"  wrote in news:oklfc9$1lr5$1   
   >>>>>> @gioia.aioe.org:   
   >>>>>>   
   >>>>>>>   
   >>>>>>> James Harris asked:   
   >>>>>>>   
   >>>>>>>> How short was the (current) shortest solution?   
   >>>>>>>   
   >>>>>>> by adopting Kerr Mudd-John's decoder routine we are down to 209   
   > []   
   >>>>>> Depends on the spec; my shortest using only B64 chars is 246.   
   > []   
   >>>>   
   >>> SMC:   
   >>>>         
   >>>>   
   >>>> And I wonder if it would be shorter to change that to   
   >>>>   
   >>> 2:1:   
   >>>>         
   >>>>   
   >>>> The pre-decoder would convert just the base64 decoder to binary. The   
   >>>> binary version of the base64 decoder would then decode the text. The   
   >>>> pre-decoder would decode a simple format.   
   >>>>   
   >>> You might try running e.g. (246 byte 2:1)   
   >>>   
   >>> ZRPRhp0XPR5p1PRRjL4hPa5LU1GJ1GLUX+G=1GeRSVG8+r6238wbt083t+RU=rY=   
   >>> 66Z2202Zffffff0222F6====MJ=20=17===eeee+++slOBI9UnEdoAasbaANE9E7   
   >>> jelperHQE9sAjesuH8lpssMIG7asA9babaaGv7h8A7IdH9RKi8A9EGI8sCoAlpin   
   >>> MIT9lpadITt7YoH9f7=tAm6CAHNIcNIZWxsbyB3b3JsZCEk=   
   >>>   
   >>>   
   >>> through debug.   
   >>>   
   >>>> On one hand, the base64 decoder might take up more room. On the other   
   >>> it   
   >>>> could use any asm instructions so might be shorter. (Some or all of   
   > the   
   >>>> pad could be saved, too.)   
   >>>>   
      
   > I dunno why you think there are boundaries that need padding.   
      
   That came from the implications of this:   
      
   JH>> I could guess there might be problems with the location of the   
   decoded code. So I guess it is meant to be started at CS:0 or CS:100. Am   
   I anywhere close?   
   WK> The challenge implied that the final decoded stuff starts at CS:0100   
      
   My thought was that if the converted code were to overwrite the original   
   text it was replacing then by the time the code gets to start writing   
   the converted code there might need to be up to 15 bytes of padding   
   before the payload (so the converted code can be written on a 16-byte   
   boundary).   
      
   >>>   
   > []   
   >> One more "wheel", though, just out of interest. I see that of the   
   >> opcodes available there are, in hex, these "ranges":   
   >>   
   >> the 3x range which gives some very useful xor and cmp   
   >> the 7x range which provides short jumps _if_ offsets fit   
   >>   
   >> but there are not many useful instructions available. Has it already   
   >> been looked at to xor a run of bytes in order to make some other opcode   
   >> ranges available (and maybe make jCC offsets more amenable)? I've not   
   >> worked out any particular xor value. Just asking if it's already been   
   >> considered.   
   >   
   > Yes. AFAICT it's the only way. Take a look at one of the published   
   > strings, like the one I gave above, or Wolfgang's that uses a wider set   
   > of characters (esp 'sub')   
      
   Since you suggested I look back at the discussion I had a search to find   
   the beginning. To my surprise it's been going on for about six months.   
   Its genesis seems to be this   
      
   https://groups.google.com/d/msg/comp.lang.asm.x86/Cvio9QqBTP0/0Kpf-bqRFwAJ   
      
   which is available on Google Groups but not my news service - even more   
   mystery! :-)   
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)