💾 Archived View for clemat.is › saccophore › library › ezines › textfiles › ezines › APJ › apj_2.txt captured on 2021-12-03 at 14:04:38.
-=-=-=-=-=-=-
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::. Dec 98/Jan 99
:::\_____\::::::::::. Issue 2
::::::::::::::::::::::.........................................................
A S S E M B L Y P R O G R A M M I N G J O U R N A L
http://asmjournal.freeservers.com
asmjournal@mailcity.com
T A B L E O F C O N T E N T S
----------------------------------------------------------------------
Introduction...................................................mammon_
"Keygen Coding Competition".................................Ghiribizzo
"How to Use A86 for Beginners".................................Linuxjr
"Using the Gnu AS Assembler"...................................mammon_
"A Guide to NASM for TASM Coders"..................................Gij
"Tips on saving bytes in ASM programs"...................Larry Hammick
Column: Win32 Assembly Programming
"A Simple Window".........................................Iczelion
"Painting with Text"......................................Iczelion
Column: The C Standard Library in Assembly
"The _Xprintf functions"....................................Xbios2
Column: The Unix World
"X-Windows in Assembly Language: Part I"...................mammon_
Column: Assembly Language Snippets
"IsASCII?"............................................Troy Benoist
"ENUM, CallTable"..........................................mammon_
Column: Issue Solution
"PE Solution"...............................................Xbios2
----------------------------------------------------------------------
+++++++++++++++++++++++Issue Challenge++++++++++++++++++++
Write the smallest possible PE program that outputs its command line
----------------------------------------------------------------------
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::..............................................INTRODUCTION
by mammon_
Wow! This issue is huge. More than twice the size of the last; maybe it is time
to go monthly...
This issue has as its theme --such as it were-- the use of popular free- and
shareware assemblers. It began with my needing to write a GAS intro to
accompany my X-Windows article; shortly thereafter, Linuxjr emailed me the
benefits of his university training with his A86 tutorial (beginners: this is
for you! Linuxjr explains *everything*). I then appealed to Gij to allow me to
incorporate his Nasm 'Quick-Start' guiide, which I have used often...he posted
the condition that I edit it heavily ;)
I would like to draw your attention first to our new column: Assembly Language
Snippets. Originally this was an idea which I and a few others had; however, I
never received any contributions for the 'Snippets' section. Then I received an
email from Troy with the first one... I pulled the rest out of my various asm
sources and voila, a new column was born. This is something that is fully open
to contributions; asm snippets --and we will need lots-- may be emailed to
asmjournal@mailcity.com or mammon_@hotmail.com, or they may be posted to the
Message Board at http://pluto.beseen.com/boardroom/q/19784/
Basic format should be:
;Name: Name to title you with
;Routine Title: Name to title the snippet with
;Summary: One-Line Description
;Comaptibility Specific Assemblers or OSes this works with
;Notes: Any extra notes you have
--Code--
I should point out here that freeservers.com is not very reliable; thus the
APJ home page is inaccessible more often than not. For this reason I have set
up a mirror on my own page, at http://www.eccentrica.org/Mammon/APJ/index.html
As for this issue's articles, we once again have two fine Win32 asm tutorials
by Iczelion, who maintains an excellent page at http://iczelion.cjb.net (with
a Win32 asm message board!). Ghirribizzo has supplied his fun Key Generator
Competition results (I can't say I was surprised when I saw the winner ;).
Larry Hammick --who also maintains an excellent, smoking-enabled page at
http://www3.bc.sympatico.ca/hammick/-- has contributed a fantastic piece on asm
optimization. XBios2 has this time gone above and beyond, not only with the C
Language in Assembly but with his Issue Challenge as well... asm coders and
reverse engineers alike should read this.
As for the issue challenge, XBios2 did not provide me with one for next issue,
so I used one from a text I found on the Internet somewhere... he has been
emailed the text and can try to beat it ;) Also, I am going to be setting up a
page for reader responses to the Issue Challenges -- readers can anticipate the
solutions before each issue comes out, or try and best the solution afterwards.
Submissions can be sent to the same places as the Snippets.
Author Bio's? I know mainstream mags do this-- if you want one, send one. I'll
tack it onto the end of the article ... anything within reason: URL, email,
hobbies, perversions, favorite drink, favorite linux distro, etc.
Next Issue: How many articles on Code Optimization can I get? That would make a
great theme (with the foundation laid this issue)--anything from code theory to
PentiumII-specific optimizations would be welcome. Prospective articles, send
to me or post on the MB...no topic is unacceptable unless you can in no way
possible relate it to assembly language.
Enjoy the ish,
_m
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Keygen Coding Competition
by Ghiribizzo
Introduction
------------
The competition was to write the smallest key generator for the simple serial
scheme I wrote as a trainer for newbies. I had a few reasons for starting this
competition:
� To give the newbies a chance to participate in a competition
� To give old hands the chance to brush up on their assembly skills
� To promote tight assembly coding
� To demonstrate the various different methods used to improve efficiency in
coding
Well, I'm back from my short European jaunt and the competition is now closed.
I have greatly enjoyed the entire competition, from the coding of the crackme
and the chats with various crackers on IRC through to deciding the winner and
writing this document.
Analysis of the Serial Scheme
-----------------------------
The serial scheme was kept deliberately simple as it was written for newbies to
train with. The scheme took a name of up to 16 bytes long and required a 16
byte serial number. There was a 256 byte lookup table that was indexed directly
with the ASCII values of the name field. The name was padded to a length of 16
(if necessary) using values hardcoded into the scheme. The 256 byte lookup
table was created using eight maximal 8 bit linear feedback shift registers
(LFSRs) in parallel i.e. producing one output byte per 'clock'. The LFSRs were
initialised to produce 'Ghir_OCU' as the first 8 output bytes. The table was
precomputed and it was not expected that the cracker recognise the nature of
the lookup table - although a post I made to the cracking forum about LFSRs
might have tipped the more astute crackers!
The rules of the competition required that some standard interface text be
included which strongly urged the use of service 9 interrupt 21h - though this
would probably be used in any case - and discouraged blank screens and other
unfriendly UIs from being used to save bytes. Also, the rules specified a range
of input to be handled smaller than the possible 256 maximum. Due to the simple
nature of the serial scheme, this meant that the lookup table could immediately
be stripped down to the input range.
I envisioned that there would be 3 �fights�. One to reduce the original
algorithm, second to reduce the packed table lookup algorithm and the last to
reduce the LFSR algorithm. As it turned it, everyone seemed to go for the
packed table option.
The Entrants
------------
The following entrants have been included because they illustrate the different
ideas and methods used to reach the common goal of reducing code size. I didn't
realise that so many crackers would use the precomputed table method. Perhaps
word got out during IRC chats and everybody started using them? In any case,
this didn�t reduce the size cutting war as precomputation had its own routines
that needed to be optimised.
Ghiribizzo Alpha (223 bytes)
----------------------------
This was not an entrant as it would hardly be fair for me to enter the
competition knowing how the lookup table was generated! This keygen was
basically converted from the crackme and improved 'on-the-fly' by generating
the lookup table in code and tidying up routines where they were obviously
inefficient. No great thought went into this and the code size was just to give
myself an idea of what crackers would be aiming for. Aside from generating the
lookup table, the only other unusual feature of this keygen was the use of the
XLAT command instead of the standard indexing used in the crackme. I didn't
stop to check whether this used less space or not, but included it as newbies
may not be familiar with the XLAT instruction. As it happened, the XLAT
instruction was used in Spyder�s keygen.
From the size I got from this keygen, I tried to guess a required key input
range to put this size between thestraight table precomputation and the packed
table precomputation.
One thing to note is how I ended the program. I was quite surprised by the fact
that nobody else seemed to know that you could quit com programs with a ret
instruction. Further size savings can be made by using Bb�s trick of keeping DH
and also by tweaking the generator to fix some of the bitstreams produced to
give us the bits we need and save later processing.
Cruehead Alpha (244 bytes)
--------------------------
I got this from Cruehead on IRC when I asked to see what he had managed so far.
Although this version is unfinished it is still impressive. The keygen relies
on precomputing the whole table and reducing the keygen to a single table
lookup.
The coding is very simple - almost seems as if Cruehead was typing the steps
going through his head straight onto the keyboard (perhaps he was?) the
resulting code is consequently very easy to understand and follow.
Bb #10 (230 bytes)
------------------
Bb has written an excellent keygen. He has put some serious hard work into this
including taking the time to calculate the dx offsets manually instead of just
using the �offset� feature that the compiler provides. It has been fun watching
Bb�s keygen progress as the first one I received was version 5 which was 256
bytes long. The keygen presented here is version 10. There are other nice bits
and bobs throughout this code. This makes it quite frustrating as in various
places so much space is blatantly wasted. Just take a look at the last 6 lines
of code! There shouldn�t even be 6 lines there! I�m sure Bb will learn a lot
from seeing some of the other keygens here and I�m sure he will do very well
should he enter the next competition.
Spyder (211 bytes)
------------------
Tidy, compact and elegantly coded. A little sparse in commenting (it seems like
Spyder coerced IDA to write the keygen for him ;-p). The table lookup is an
interesting piece of code.
VoidLord (247 bytes)
--------------------
Another keygen using the idea of a packed precomputed table. VoidLord�s first
keygen. Let�s hope we see more!
Honourable Mentions
-------------------
Special mention given to Trykka who managed to deduce how the look-up table was
created - but never sent in an entry!
The Winner
----------
Well it looks like Spyder is the winner by quite a large margin. Incidentally,
I have just made a quick check that the keygens work. You might be able to bump
yourself up on the scale by picking holes in the other keygens :-)
Rankings
--------
__Keygen______Size________Author______
kgen.com 211 Spyder
kg.com 224 Ghiribizzo (alpha)
kg10.com 230 Bb
kg9.com 233 Bb
kg6.com 239 Bb
kgvoid.com 247 VoidLord
kgcrue.com 255 Cruehead (alpha)
kg5.com 256 Bb
kgt.com 529 Serial Scheme
Final Words
-----------
There have been some excellent ideas in the keygens. However, none of the
keygens are as small as they could be. They all have some scope for improvement.
By combining some of the ideas given in the above keygens, we could create a
new smaller keygen. It will be interesting to see what the smallest possible
keygen would look like.
I hope that everyone who has taken part in the competition, or who has followed
it, has gained something from it. I hope that there will be more entries for
the next competition!
The Source Codes
----------------
; Ghiribizzo�s Keygen =========================================================
.model tiny
.386
.code
.startup
; The first part of the code is the table generator
; Note that we can actually do some �precomputing� by
; fixing some of the bits in the generator to produce
; the bits that we need. This will save some bytes
; in the serial section. I have not bothered to do this.
mov ax, 5547h
mov bx, 6869h
mov cx, 725fh
mov dx, 4f43h
mov di, offset PRD
mov si, offset PRD + 0ffh
LFSR:
stosb
;Save MSB
mov bp,ax
mov al,ah
and ax,0ffh
xchg ax,bp
;Tap
xor ah,bl
xor ah,ch
xor ah,al
;Shift
mov al,bh
mov bh,bl
mov bl,ch
mov ch,cl
mov cl,dh
mov dh,dl
;Store MSB
and dx,0ff00h
or dx,bp
cmp di,si
jle LFSR
;-----------------------------------------------------------------
mov ah,9
mov dx,offset startMsg
int 21h
mov ah,10
mov dx,offset NameInput
int 21h
;-----------------------------------------------------------------
mov si,offset NameBuffer
mov di,offset NameHash
mov bx,offset Table1
MakeSerial:
lodsb
xlat
and al,3fh
or al,30h
byteOK:
cmp al,39h
jle keepit
add al,7
keepit:
stosb
cmp di,offset stopbyte
jl MakeSerial
;-----------------------------------------------------------------
mov dx,offset NH2
printMsg:
mov ah,9
int 21h
exit:
ret
StartMsg db 0dh,0ah,'OCU Keggen #1 ',0feh,' Ghiribizzo 1998 ',0dh,0ah
db 0dh,0ah,'Enter Name :