How to make encrypt()/decrypt() produce same result in 16/32

[hua]

How to enable encrypt()/decrypt() to produce the same result in 16 and 32 bits version? So far I noticed a 16-bit decrypt() can't correctly decrypt a string encrypted by a 32-bit encrypt().

Any help is much appreciated as it's quite urgent.

TIA.

[Antonio Linares]

Hua,

We are going to review this issue as soon as possible.

We are actually at Holland providing a FWPPC seminar but today we will look for some free time to review it

[hua]

Thanks Antonio. Appreciate it

[Antonio Linares]

Hua,

We have tested it in both 16 and 32 bits and the results are the same.

Could you please provide a sample where the encrypted result is different ? thanks

[hua]

Sorry for the late reply Antonio. Got to finish other stuffs that were due first. A brief description about the following samples. There would be 2 exe involved. The 32-bit exe would be calling the 16-bit exe.

This is the code for the 32-bit exe. (FWH2.8+xHarbour 0.99.61)

Code: Select all  Expand view  RUN

#include "FiveWin.ch"

function Main()

   local oDlg, oIco, cId := "SUPERVISOR"

   DEFINE ICON oIco FILE "..\icons\fivewin.ico"

   DEFINE DIALOG oDlg TITLE "I am a DialogBox" COLOR "W+/B" ;
      ICON oIco


   @ 3, 5 BUTTON "Run module" SIZE 40, 12 ;
      ACTION winexec("exe16.exe "+encrypt(trim(cId))  )


   ACTIVATE DIALOG oDlg CENTERED

return nil


And this is the code for the 16-bit exe. (FW2.3+Clipper 5.2)

Code: Select all  Expand view  RUN

#include "fivewin.ch"

function main16(cID)

  default cId := ""
  msginfo(decrypt(trim(cID)))

return nil


The resulting string is not SUPERVISOR as expected.

[Antonio Linares]

Hua,

Thats risky: the encrypted result may contain embedded zeroes that the application initialization may not properly parse.

Better write the encrypted text to a file and read that file from the 16 bits EXE

[James Bott]

Hua,

>Better write the encrypted text to a file and read that file from the 16 bits EXE

If you do this, don't forget to securely erase the file after reading it. I don't mean to just delete it, but to write dummy data to it multiple times before deleting it.

James

[hua]

Antonio, James, thanks for the feedback and input. It never occur to me that passing encrypted string as I was doing could be problematic as the string length stays the same in exe32 and exe16.

[James Bott]

Hua,

I don't know if this will work, but you could try:

@ 3, 5 BUTTON "Run module" SIZE 40, 12 ;
ACTION winexec([exe16.exe ]+["]+encrypt(trim(cId))+["] )

Enclosing the passed parameter in quotes may fix any problems with spaces in cID.

James

[hua]

Thanks for the idea James. I just find it odd that if both the above samples are compiled in 16-bit I do get the expected string i.e. SUPERVISOR

[AlexSchaft]

Hi,

Another trick I use where high (>127) ascii and low(<32) can be tricky is to mime encode the strings

Code: Select all  Expand view  RUN


   @ 3, 5 BUTTON "Run module" SIZE 40, 12 ;
      ACTION winexec("exe16.exe "+cmimeenc(encrypt(trim(cId)))  )



and

Code: Select all  Expand view  RUN

msginfo(trim(decrypt(cmimedec(cId))))


[James Bott]

Hua,

>Thanks for the idea James. I just find it odd that if both the above samples are compiled in 16-bit I do get the expected string i.e. SUPERVISOR.

Granted that does seem odd. Are you using the same versions of FW and FWH? Perhaps there was a change in the versions that is causing the problem rather than 16bit vs 32bit.

James

[Antonio Linares]

James,

There have not been changes in functions Encrypt() and Decrypt() source code. Its easy to check that their results are compatible, so Hua problem has to be something else. Maybe something related to calling 16 bits from 32 bits.

[hua]

@ 3, 5 BUTTON "Run module" SIZE 40, 12 ;
ACTION winexec([exe16.exe ]+["]+encrypt(trim(cId))+["] )

Unfortunately, the above didn't work James.

Granted that does seem odd. Are you using the same versions of FW and FWH? Perhaps there was a change in the versions that is causing the problem rather than 16bit vs 32bit.

No. I'm using FW2.3 and FWH2.8 respectively. I'm holding on to a time-tested principle, "if it ain't broken, don't fix it". Hence my reluctance to touch anything that's working fine so I left my 16-bit programs with FW16. I doubt there was a change, if there was, a lot more people would've been affected.

Another trick I use where high (>127) ascii and low(<32) can be tricky is to mime encode the strings

Hey, that's a neat trick there Alex. I'll keep it in mind. I know it'd have never crossed my mind.