pouët.net

qkumba information 15 glöps

• general:
• level: user
• personal:
• first name: Peter
• last name: Ferrie

• demotool Windows Crinkler by Loonies [web] & TBC
• okay, so forget the LoadLibrary thing. :-)
  
  the dec al/inc al part - these seem less likely to appear than dec eax/inc eax.
  would it be better to xor eax,eax before the lodsb, and then dec eax and inc eax instead?
  the xor/lodsb sequence appears earlier, so maybe that helps compression.
  
  and in that case, perhaps instead of dec/jns, you could use test/jne, and instead of the inc/je, you could use cmp eax,ebp. it's bigger, but might compress better.
  you've reached the end of the list when ebp is zero.
  
  as far as initial registers, only ebx is defined. edx=eip only if syscall mode is used (which can be disabled in some ways), other register values have changed over time.
• isokadded on the 2012-07-19 22:15:47
• demotool Windows Crinkler by Loonies [web] & TBC
• the LoadLibrary pushes might be achieved in the header for no cost at all...
• isokadded on the 2012-07-19 20:42:59
• demotool Windows Crinkler by Loonies [web] & TBC
• Quote:

  You do realize that these pushes are in your code, right?

  
  
  I just checked again. It is Crinker code. It's the exit code when a DLL can't be loaded.
  The "OUT" label that I referenced was the truncated process name (OUT:some address).
• isokadded on the 2012-07-19 17:14:45
• demotool Windows Crinkler by Loonies [web] & TBC
• Quote:

  It seems you are right about ebx=[fs:30] on startup. A quick test suggests that we can
  save about 3 bytes. It does complicate the call transform code, but I think it will still be a net win in that case.
  Can we rely on this across all windows versions?
  It would be much appreciated if you can find the documentation you are mentioning :)

  
  
  Yes, you can rely on that across all Windows versions. I will look for the documentation.
  
  
  Quote:

  
  ...
  
  You do realize that these pushes are in your code, right?

  
  
  That was taken from the one file that I examined. It never occurred to me to check which parts Crinkler added. :-)
  
  
  Quote:

  Quote:

  the code in the header could be shortened by at least 3 bytes, but I didn't see any advantage because it seems that nothing can move into the gap.

  
  
  Yes, gaining a lone byte somewhere in the header doesn't really help.
  I'm guessing part of the saving you are mentioning is in the code around the stack reserve field.
  You also need to be aware that the code inside the header is not as naive as it might seem, as it is under some additional constraints.

  
  
  I understand that. I have some experience in crushing PE headers (see pferrie.host22.com). ;-)
  
  Speaking of which, you don't need any section table at all. It is legal to set NumberOfSections to 0 since you import nothing (import table must be in a section since WinXP), and you still allocate all the memory that you want. DEP is not a problem if section alignment < 4096. I'm sure that complicates things for you, but just in case you didn't know.
  
  
  Quote:

  mov ebx, dword 3
  is actually just a shorter way of jumping across the subsystem field (dword 2/3), while at the same time initializing ebx to something >1.

  
  
  Yes, but as noted above, it's already non-zero.
  
  
  Quote:

  Quote:

  
  
  for the import table on Win2k, the requirement was to import from either kernel32.dll, or something that imports from kernel32.dll, so that kernel32.dll is loaded somehow. lz32.dll could have been wmi.dll for a 1 byte saving.

  
  
  This is from the old header. We no longer support win2k. Also, you wouldn't really save 1 byte as it was in a 8 byte slot in the header.

  
  
  If you moved lfanew to 0x10, for example, then it would fit at offset 2, with room for an instruction or two.
  
  
  Quote:

  Quote:

  the original PEB_LDR_DATA code could be used, if you resolved LoadLibraryExA instead of LoadLibraryA. the ExA version exists in kernelbase.dll and kernel32.dll, and it takes two additional parameters which would both be zero.

  
  
  This sounds very interesting. I'm not really sure I follow. How do you get to kernelbase.dll and can you do this reliably on all windows versions?
  Using kernelbase would result in an overhead when the intro imports from kernel32, but I guess we could redirect the imports to kernelbase in the
  instances where we can. Either way, I'm curious about this :)

  
  
  When run on Win7, the old PEB code would fetch kernelbase.dll instead of kernel32.dll, and then call the wrong API because the hash loop exited.
  So, if you resolved LoadLibraryExA instead of LoadLibraryA, then you'd get a valid address no matter which platform was used.
  I haven't seen any demos using kernel32.dll, but I suppose that if one did, then you'd still have a regular import entry for it, so the behaviour would not change visibly. I will test that.
  
• isokadded on the 2012-07-19 16:50:44
• demotool Windows Crinkler by Loonies [web] & TBC
• the original PEB_LDR_DATA code could be used, if you resolved LoadLibraryExA instead of LoadLibraryA. the ExA version exists in kernelbase.dll and kernel32.dll, and it takes two additional parameters which would both be zero.
  
  for the import table on Win2k, the requirement was to import from either kernel32.dll, or something that imports from kernel32.dll, so that kernel32.dll is loaded somehow. lz32.dll could have been wmi.dll for a 1 byte saving.
• isokadded on the 2012-07-19 05:20:40
• demotool Windows Crinkler by Loonies [web] & TBC
• mov eax,[edx+1C]
  add eax,ebp
  mov eax,[eax+4*ecx]
  mov [esp+1C],eax
  
  if ebp and edx were exchanged, you could use
  
  add edx,[ebp+1C]
  mov eax,[edx+4*ecx]
  mov [esp+1C],eax
  
  for a 2 bytes saving
  
  extending that:
  
  mov eax,[edx+4*ecx]
  mov [esp+1C],eax
  popad
  
  could be
  
  pop eax
  push [edx+4*ecx]
  popad
  
  for a 3 bytes saving.
  of course, the actual savings after compressing these might be 0 or worse. :-/
  
• isokadded on the 2012-07-19 03:13:44
• demotool Windows Crinkler by Loonies [web] & TBC
• even better: ebx=fs:[30] on process start (it's even documented somewhere), so push ebx in the header, pop eax in the second stage, no need for the fs: line at all.
• isokadded on the 2012-07-19 00:02:39
• demotool Windows Crinkler by Loonies [web] & TBC
• I had a quick look at this today, and I see some things in the import code:
  
  64678B4730 mov eax,fs:[bx+30]
  could be
  6467A13000 mov eax,fs:[30]
  (maybe a zero in the instruction helps somehow)
  
  mov ebx,<image base>
  could be
  mov ebx,[eax+08]
  if placed after the fs: line, for a 2 bytes saving.
  
  also, the check for DLL loading:
  test ebp,ebp
  jne OUT
  push 00000000
  push 00000000
  push edx
  push 00000000
  could be
  test ebp,ebp
  jne OUT
  push ebp
  push ebp
  push edx
  push ebp
  since ebp is known to be zero at that point, for a 3 bytes saving.
  
  the code in the header could be shortened by at least 3 bytes, but I didn't see any advantage because it seems that nothing can move into the gap.
• rulezadded on the 2012-07-18 23:44:40
• 16k Windows Hammer Crime by High Class Villas
• white screen = bad paint message handling. cover the demo window with another window, then uncover it.
• isokadded on the 2012-05-07 05:03:52
• 8k Windows Graphism by Signal Noise Ratio
• D3DXCreateTextureFromFileA(".\color-demo_lex.png") is failing on some configurations, and then the demo crashes.
• sucksadded on the 2012-05-06 06:53:56