It's interesting to know that Windows doesn't let you define the segment to set ZERO based tables. (Well yea, I guess you could say that VB is a Windows-based platform. Sorry, thanks for the tip.) You are already proving to me that WIN32 ASM requires some finesse that I did not just bring into this project.

rcl BYTE PTR [ 1 + REGS +_R24], 1

There is a simple convention I need to learn about regarding how to use mnemonics with this operand :

BYTE PTR [ 1 + REGS +_R24]

Once I am fluent with it then I'll be able to do some BYTE programming in WIN32.


I don't know if Windows forces me to code into the indexing method that selects the SBOX values, instructions that will add a carry bit to the higher order indexing value.

The SBOX is 256 bytes and ideally could be SETUP in a zero based table in its own segment. Under Windows its not possible.

The other 6 tables require 64 bytes each. Crossing segment boundaries in derived indexing better not be a problem. I am sure there is a CORRECT way to program these methods if I'm unable to define segments to ZERO-base the index value.

In 32-bit mode I guess it is possible to just do:

mov ax, and Viola! a value from the table.

If al holds a value 0 to 255

mov al, BYTE PTR [ DECODE + al]

al now holds the SBOX value?


Posted on 2002-03-13 13:27:10 by avrster
Typically you will set a register to the address of the table and then index from that address with another register.

mov al,

In this way ESI becomes the base, and the offset ECX is the dynamic zero based offset, and this allows a constant offset as well - very flexible.

This would be more better under windows:

; initialize EAX to zero
xor eax,eax ; and eax, 0 ; mov eax, 0

mov al,

mov al, eax]

You want to use 32-bit addressing.

I didn't want to assume you were using Windows. :tongue:
Posted on 2002-03-13 13:45:47 by bitRAKE
In Win32 I might as well setup the tables as BYTE values. I assume that memory will then hold consecutive values. (?)

.DATA Use32 Byte Public 'SBOX' ;256 bytes
.DATA Use32 Byte Public 'MOD0101' ; 64 bytes
.DATA Use32 Byte Public 'EXP0101' ; 64 bytes
.DATA Use32 Byte Public 'MOD0102' ; 64 bytes
.DATA Use32 Byte Public 'MOD0801' ; 64 bytes
.DATA Use32 Byte Public 'EXP0801' ; 64 bytes
.DATA Use32 Byte Public 'MOD0802' ; 64 bytes

Actually there is no point in multiple assembler directives. Just one will suffice and then the tables are defined as they were in the 16-bit source.

.DATA Use32 Byte Public 'TABLES' ;256 bytes

All tables require 256+(6*64) BYTES

I can experiment with the MASM32 directives a little and use PE viewer to see if there is a way to order memory with concecutive 8-bit table values.

Throwing the constant into the equation like you suggest, I could setup pointer values for each sub-table.

Always do base as:

mov esi, TABLE

then set esx with sub-table offset:

mov esx,

then if INDEX is already the value in al,

mov al,

puts SBOX value into al.

Its actually wasteful to create a table indexing method and just call it each time a new walue is wanted. Its very efficient to just set the esi and esx values and work through your method that derives the index value using

mov al, each time. There would be a call FETCH_TABLE instruction anyway so it actually requires MORE memory to code it.


Using MASM32 then I also assume that it will be possible to create a register to index the BASE address of the table and:

mov al, INDEX ; 0 - 256

mov esi, SBOX ;SETS esi to index the SBOX table

mov al, ; al holds indexed SBOX value

// assuming I have this straight then its on to the next crisis

crisi is plural form of crisis

The processing manipulates a carry bit using 8-bit operations.

In WIN32 I assume that al is then 16 bits.

I can adjust the values adding 256 before processing to affect the bits with adc and rol

Is it necessary? Does the MASM32 support the Pentium class processor in such a way that it has a native 8-bit register or register mode? I caught a glimpse of it with the BYTE PTR[ ] operand. Surely there is more ... (come on tease me)

Posted on 2002-03-13 14:18:11 by avrster
The header now includes this information:

; ##########################################
; Montgomery 8-bit Processing for 16-bit x86 Windows platform
; In a quest to create a Visual Basic DLL the processing has first been
; coded for 16-bit x86 ASM. However, to meet the real needs for
; Visual Basic 6 development, its thought that the processing should be
; coded for 32-bit x86 ASM.
; Compiler is MASM32
; ##############- LAST UPDATED -#################
; AVRSTER on 3-13 4PM CST
; ##############- TARGET PLATFORM -##############
; Win32 (Windows 9x, ME, 2000, XP)
; ##############- APPLICATION -##################
; Visual Basic 6 UNKNOWN (RSA encrypt-decrypt function)
; ##############- IMPLEMENTATION -###############
; Private Declare Function ENCRYPT Lib "MONTY.dll" Alias "ENCRYPT@1" (ByVal R4 as Integer , ByVal R5 As Integer, ByVal R15 as Integer, ByVal KEYas String, ByVal DATA As String) As String
; Private Declare Function DECRYPT Lib "MONTY.dll" Alias "DECRYPT@2" (ByVal R4 as Integer , ByVal R5 As Integer, ByVal R15 as Integer, ByVal KEYas String, ByVal DATA As String) As String
; ##############- NOTATIONS -##################
; 3-13 AV
; Passed parameters:

; Symbols Visual Basic DataType Description


; R4,R5 integer ;Two 8-bit control values to articulate permutation

; R15 integer ;8-bit value to articulate rounds

; KEY (byte array)* ;KEY values that VB has converted to ???* (option)

; DATA (byte array)* ;(8 Values???) PAYLOAD that VB has converted to ???* (option)

; R4,R5 integer ;Two 8-bit control values used articulate permutation
;Since they are alterred, it might be necessary to return
;them in their new state to the application. It depends
;on the processing. If they are over-written by new states
;from the stream then its un-necessary to return them.

; R15 integer ;8-bit value to articulate rounds
;SAME as for R4,R5 if processing warrants their return then
;should be done. Otherwise not.

; RESULT (byte array)* ;RESULT that VB will process as DATA ??? (option)

;*option Whatever is deemed to be the most preferable way
; to pass these values.
; 3-13 from SLUGGY"
; "If you pass ByVal, VB copies the string to a temporary place on the heap. When it makes that copy, it changes the format of the string
; from UniCode to ANSI, so your asm function will receive a pointer to an ANSI string stored in temporary space. That copy of the string
; is destroyed when you return to the VB function, so if you need a copy of it then your asm function will have to copy it to a private
; buffer."
; 3-13 AV 4PM CST

; Private Declare Function ENCRYPT Lib "MONTY.dll" Alias "ENCRYPT@1" (ByVal R4 as Integer , ByVal R5 As Integer, ByVal R15 as Integer, ByVal KEYas String, ByVal DATA As String) As String
; Private Declare Function DECRYPT Lib "MONTY.dll" Alias "DECRYPT@2" (ByVal R4 as Integer , ByVal R5 As Integer, ByVal R15 as Integer, ByVal KEYas String, ByVal DATA As String) As String

; R4 :8 Permutation1 pointer
; R5 :12 Permutation2 pointer
; R15 :16 Rounds pointer
; KEY :20 KEY string pointer
; DATA :24 DATA string pointer

; Returned result will be in the location pointed to by the DATA string pointer 24.
; Before processing input its standard practice to push affected registers onto the stack:
; push ebp
; mov ebp,esp
; push edi
; push esi
; push ebx
; mov edx, ;Get Permutation1 pointer
; mox R4,
; mov edx, ;Get Permutation2 pointer
; mox R5,
; mov edx, ;Get Rounds pointe
; mox R15,
; mov edx, ;Get Key pointer
; mox ptrKEY,
; mov edx, ;Get DATA pointer
; mox ptrDATA,
; *This is an example of accessing the passed parameters.
; Putting the values into locations might be regarded as a good Win32 programming practice.
; In that case a couple of simple methods to move the KEY and DATA buffers to program
; locations is needed.
; The result in the DATa buffer would be deposited in the same buffer that passed it into the
; method. On returning a value it will first be necessary to restore the pushed values, then the
; final ret instruction also has an operand to pass the pointer to the data buffer.

; pop ebx
; pop esi
; pop edi
; mov esp,ebp
; pop ebp

; ret 24
; Visual Basic receives a pointer to the processed DATA and resumes processing.
Posted on 2002-03-13 15:08:45 by avrster
This post has a very useful example for passing and receiving the parameters.



;NB Assumes all 8 hex bytes filled with 48("0") to 70("F")
; and all 32 bin bytes filled with 48("0") or 49("1")

; VB

;Select Case Index
;Case 0 'Hex Input
; Hex2Long2Bin
;Case 1 'Long Input
; Long2Bin2Hex
;Case 2 'Bin Input
; Bin2Hex2Long
;End Select

; For calling machine code
; res = CallWindowProc(lpMCode,InpDec, lpHex, lpBin, OpType)
; 8 12 16 20
; lpMCode pointer to machine code
; InpDec long decimal number input
; lpHex pointer to HexBytes(1) input & output
; lpBin pointer to BinBytes(1) input & output
; OpType long number 1,2 or 4 for respec. Hex, Dec & Bin input
; res long decimal output (from reg EAX)






push ebp
mov ebp,esp
push edi
push esi
push ebx

mov eax, ;Get OpType
rcr eax,1
jnc TestOp2


CALL Hex2Long ;Long result in eax & edx
push eax
CALL Long2Bin ;In: Long in edx
pop eax ;Long result in eax


rcr eax,1
jnc TestOp3


mov edx, ;Get decimal input

CALL Long2Bin
CALL Bin2Hex


rcr eax,1
jnc GETOUT ;Error? ignore


CALL Bin2Hex
CALL Bin2Long ;Long result in eax


pop ebx
pop esi
pop edi
mov esp,ebp
pop ebp
ret 16
Posted on 2002-03-13 15:46:22 by avrster
Posted file has new header information regarding parmeter passing. V (Below)

Its time to start writing code again!

Posted on 2002-03-13 16:05:23 by avrster
Use of ebx, esi and edi is essential to 32-bit programming.

The attached file has the changes to type definitions and uses 32-bit pointers in the short support functions.

I'm coding 32-bit ASM for Win32. It should be routine to make the changes.

Thanks for the help!

I was actually starting to think about another project while driving today that would allow VB to emulate a smartcard in a development application. I have the encryption for both sides and an interface that connects to the computer. Its a matter of determining the features that would make it useful in prototyping x86 code running on WIN32.

The biggest thing I can think of is the low startup cost, and the need for exporting the code to another taget processor that actually resides on a smartcard. You guys must know something about what is already available.

Posted on 2002-03-13 21:46:09 by avrster
There is still some work to do on getting the methods to use the correct input buffers.

The basic code is there, its a matter of going through the external processing to see exacly what is being passed into each public method and setting it up correctly. I just whipped it together.

Also, while I'm at it I'll be looking to see if some of the external processing can be added to the DLL possibly to keep a few more of the methods private.

Posted on 2002-03-14 11:52:45 by avrster