[ itf @ 25.11.2005. 13:28 ] @
Sljedeci dio koda sluzi kako bih kodirao sadrzaj RichEdit-a (R1), dok rezultat prikazujem u RichEdit-u R2:

Code:
int i, j;
    char pom[4096], pom2[4096];

    R2->Lines->Clear();
    for(i = 0; i < R1->Lines->Count; i++){
        strcpy(pom, R1->Lines->Strings[i].c_str());
        for(j = 0; pom[j] != '\0'; j++)
            pom2[j] = pom[j] ^ StrToInt(E1->Text);
        pom2[j] = '\0';
        R2->Lines->Add(AnsiString(pom2));
    }


Problem je sto ovaj programski odsjecak (kao i kompletan program) dobro mi radi na laptopu koji ima iste windows (32-bit) kao i stolno racunalo. Medjutim, stolno racunalo ima 64 bit procesor.

Poanta je da mi taj isti program dobro radi na laptopu, ali na stolnom racunalu uvijek daje krivi rezultat. U cemu je rijec??

[Ovu poruku je menjao itf dana 25.11.2005. u 14:29 GMT+1]
[ X Files @ 25.11.2005. 15:18 ] @
Code:

int i, j;
char pom[4096], pom2[4096];

R2->Lines->Clear();
for(i = 0; i < R1->Lines->Count; i++){
    strcpy(pom, R1->Lines->Strings[i].c_str());
    for(j = 0; pom[j] != '\0'; j++)
        pom2[j] = pom[j] ^ StrToInt(E1->Text);
    pom2[j] = '\0';
    R2->Lines->Add(AnsiString(pom2));
}


Šta ako tvoja XOR kunkcionalnost u pom2 stringu napravi neki kontrolni kod,
koji će se kasnije sukobiti sa logikom ->Add()?

Generalno gledano TRichEdit je ASCII editor i *ne može* u ispravnom stanju da
se nosi sa kontrolnim kodovima (pogotovo sa NULL-om).

Takođe, za slične operacije koristi "unsigned char", a ne "char" !!!

U svakom slučaju probaj kripciju u jednom prolazu, koristeći Text[]:

Code:

// MISLIM DA INDEKSI POČINJU OD JEDINICE (ZBOG OBJECT PASCAL-A) !!!
for ( int i=1; i<=RichEdit1->Text.Length(); i++ )
{
   // Upotrebi KARAKTER po potrebi: RichEdit1->Text[i];
}


A evo i fragmenta jednog mog koda:

Code:

unsigned char ResourceMask = 224;
// ...
for ( resource_i=0; resource_i<resource_duzina; resource_i++ )
   resource_temp[resource_i] = (unsigned char)resource_temp[resource_i] ^ ResourceMask;


Pri čemu sam (primeti) koristio ResourceMask=224, zbog izbegavanja sukoba sa
kontrolnim kodovima (ako se dobro sećam).



[Ovu poruku je menjao X Files dana 25.11.2005. u 16:25 GMT+1]
[ itf @ 25.11.2005. 16:31 ] @
Sve ovo opet ne objasnjava zasto doticni kod daje dobar rezultat na jednom kompjuteru, a na drugome ne....
[ X Files @ 25.11.2005. 16:45 ] @
Citat:

Poenta je da mi taj isti program dobro radi na laptopu, ali na stolnom racunalu
uvijek daje krivi rezultat. U cemu je rijec??


Nisi rekao sta znaci *dobar* a sta *pogresan* rezultat :) ...

Sta ocekujes da bude ispisano u R2, kada je rezulat dobar?

P.S.

Garantujem da je problem u kodu... Imam i ja 64 procesor i sve kripcijske stvari rade dobro...


[Ovu poruku je menjao X Files dana 25.11.2005. u 17:46 GMT+1]
[ itf @ 25.11.2005. 17:25 ] @
Uzmem taj program da mi kodira istu datoteku. Kodirani tekst opet kodiram istom sifrom i dobijem originalni sadrzaj. To je dobar rezultat. Sve isto to ponovim na kucnom racunalu i nakon sto kodiram vec kodiran tekst ne dobijem dobar rezultat :)

Ako treba posaljem ti na mail?

[Ovu poruku je menjao itf dana 25.11.2005. u 18:43 GMT+1]
[ NastyBoy @ 25.11.2005. 17:32 ] @
A da ti tu petlju pustish kroz debugger, na obe mashine, pa uporedish rezultate?

Ovako mozhe samo da se nagadja da li je StrToInt neshto zabrljao oko velichine podataka, ili je do toga shto koristish 'char' koji se interno konvertuje u 'int', uradi se Xor, pa nazad u 'char'
[ itf @ 25.11.2005. 17:37 ] @
Vec sam provjerio. Konverzije su OK. Velicine podataka na obje masine su iste
[ NastyBoy @ 25.11.2005. 17:43 ] @
Proverio su petlju u debuggeru na obe mashine posebno? I don't think so, inache bi nashao problem :)
[ X Files @ 25.11.2005. 17:48 ] @
Savetujem da probas sa konverzijom/ponovnom konverzijom BEZ TRichEdit-a,
dakle samo u nekom nizu. Da li se i onda javljaju pogresni rezultati na 64-bit
mašini? Obavezno koristi "unsigned char" i za nizove i za masku...

Nikakva 64-bitna mašina ne moze tada da zabrlja stvar...
[ itf @ 25.11.2005. 17:48 ] @
Budem pokusao Memo a i promjeniti podatke... Mozda nekakva 32 bit-na enkripcija pomogne ili sl..


[Ovu poruku je menjao itf dana 25.11.2005. u 18:51 GMT+1]
[ itf @ 25.11.2005. 17:54 ] @
Je li itko ovim kodom pokusao kod sebe testirati da li ovo radi? Da budem jasniji... testirao sam na nacin da sam pokretao EXE program na obje masine, a ne kompajliranjem..

[Ovu poruku je menjao itf dana 25.11.2005. u 18:56 GMT+1]
[ X Files @ 25.11.2005. 18:21 ] @
Da, probao sam sada...

Radi za neke vrednosti Edit1->Text, kao na primer za vrednost 224, ali za na primer
vrednost 120, više nećeš dobiti ono od čega si počeo...

Nećeš da me poslušaš :)

Nije do algoritma nego do TRichEdit-a, jer je kao što rekoh to je ASCII kontejner a
ne buffer za podatke.

Ne koristi ni TMemo, jer je to jedno te isto!!! Ako ipak hoćeš u njima, moraćeš da
izračunaš vrednosti "maske" kada ASCII set sa njome ne dovodi do vrednosti
manjih od 32 (mislim). Ja sam za sebe izračunao 224.

[ X Files @ 25.11.2005. 19:26 ] @
Ili prostije objasnjenje:

1) Ako imas neki string: "abcdefghijklm"
2) pa ga kriptujes i dobijes "*************"

...ovaj poslednji kripovani string sada moze imati negde u sebi kontrolne
kodove '\r' i/ili '\n'. Može imati i neke druge problematične...

3) pa nakon sledeceg dodavanja (kriptovanog stringa):

RichEdit1->Lines->Add( "*****\r\n*****" );
RichEdit1->Lines->Add( "*****\r*****" );
RichEdit1->Lines->Add( "*****\n*****" );

... DOBIĆEŠ DVE LINIJE U RISH EDIT - A NE JEDNU !!!


Dalje više nije potrebno objašnjavati zašto ne može RitchEdit za tu svrhu...
[ itf @ 26.11.2005. 14:20 ] @
OTKRIO SAM!!! :))
Stvar JEST u RichEditu. Kad ga koristim trebam unsigned char. Ali ako RichEdit zamjenim sa Memo stvar radi na oba kompjutera kako treba bez da ista mjenjam u kodu.

Ipak.... jako je cudno da na jednom kompjuteru daje jedan rezultat, a na drugom drugi... No sad sve radi :)

X Files, ne mozes kriptirati sa kljucem koji odgovara nekoj ascii vrijednosti nekog znaka u tekstu. Tad sa XOR dobijes 0 tj. '\0' i tud ti se znakovni niz prekida. Zato ne mozes kodirati sa npr. 120 jer je to znak 'x'.
[ X Files @ 26.11.2005. 17:14 ] @
Citat:

Stvar JEST u RichEditu. Kad ga koristim trebam unsigned char.


Naravno da ti treba "unsigned char", odmah sam ti rekao za to.

"unsigned char" je "cist" i savrsen tip od 0-255. Čist char, zna se, moze da kiksne
za brojeve vece od 128.

Citat:

Ali ako RichEdit zamjenim sa Memo stvar radi na oba kompjutera kako treba bez da ista mjenjam u kodu.


Mislim da si opet nesto prevideo...

Evo ti tekst:

Permission is hereby granted, free of charge, to any person (the "User")

(uzeo sam ga iz prvog readme.txt fajla na koga sam naisao)

Pa ga kriptuj sa 110 i sa TMemo.

Citat:

X Files, ne mozes kriptirati sa kljucem koji odgovara nekoj ascii vrijednosti nekog
znaka u tekstu.


Ja ti o tome celo vreme govorim. Mozes da kriptujes sa cime god hoces,
ali ne mozes da koristis NI JEDAN ASCII editor kao BUFFER preko
koga kriptujes, a da budes SIGURAN da ces dobiti ono od cega si posao.

Citat:

Tad sa XOR dobijes 0 tj. '\0' i tud ti se znakovni niz prekida.


Nije samo NULL.

TRichEdit je osteljiv jos na '\r' i '\n', jer ce tada PRELOMITI TEKST, a TMemo,
kao prostija kontrola je (koliko se secam) osetljiva na '\r'.

// u svakom slucaju izvrsi testove sa proverom nad kriptovanim tekstom:

Code:

void __fastcall TForm1::ProveraButtonClick(TObject *Sender)
{
   for ( int i=1; i<=R2->Text.Length(); i++ )
   {
      // r i 0 - samo za TMemo,  svi za TRichEdit
      if ( R2->Text[i] == '\r' ) ShowMessage( "Manje je od 32 - r" );
      if ( R2->Text[i] == '\0' ) ShowMessage( "Manje je od 32 - 0" );
      if ( R2->Text[i] == '\n' ) ShowMessage( "Manje je od 32 - n" );
   }
}

[ itf @ 26.11.2005. 20:05 ] @
Ajd molim te napisi mi primjer za takvo kodiranje. Ne razumijem bas dobro o cemu je rijec.
[ X Files @ 26.11.2005. 22:16 ] @
Evo ovako:

Koliko sam uočio, osnovna je greška što polaziš od pretpostavke da
će komanda Add():

R2->Lines->Add( AnsiString( pom2 ) );

... u editor (TRichEdit ili TMemo) 100% registrovati ono što si
joj prosledio. Već si primetio da *neće* ako string koji dodaješ
u sebi već sadrži NULL. A znaš i sam da je NULL sasvim legitimna
vrednost koja se može naći u nekom fajlu, na primer EXE-u.

Samo tvorci same ASCII komponente (TRichEdit, TMemo) znaju kako će
tretirati pojedini karakter iz seta koji je manji od 32. To je
isključivo njihovo pravo da li će za njih IZMISLITI neki grafički
simbol (a vrednost sačuvati) ili će ga totalno izbaciti. Na primer
vrednost:

007 BEL (Bell)

... je zvono. Samo tvorci TRichEdit-a ili TMemo znaju da li će taj
kod zaista:

- odsvirati i zabeležiti.
- odsvirati i odbaciti
- ignorisati i zabeležiti
- ignorisati i odbaciti.

Mala analogija:

Da li znaš da SAMO otvaranje i zatvaranje nego fajla sa fopen(),
bez ikakve operacije na njemu (fprintf) može da mu promeni veličinu!

Može ako fopen() umesto "w+b" (pisanje+binarno) ima "w+t"
(pisanje+tekst). Tada će se INTERNO svako:

"\n" pretvoriti u "\r\n". Slično je i sa TRichEdit i sa TMemo!!!

Tačno je da možeš sve to unapred da istestiraš i na osnovu iskustva
napraviš program. Ali time i dalje nisi gospodar situacije. U razvojnom
timu koji vodim NIKADA TAKVU POSTAVKU STVARI NE BIH DOZVOLIO.

Sadašnja verzija BCB6 koristi PRVU varijantu richedit-a 1.0, dok je
trenutna windows-ova verzija 3.0. Time dovodiš sebe u situaciju da
nakon upgrade-a bilo BCB-a bili Windows-a, tvoj kod MOŽDA više neće
raditi isto kao ranije.

Ja čak *znam* da IMA RAZLIKE u funkcionisanju TRichEdit-a u zavisnosti
koja verzija sistemskih:

riched20.dll
riched32.dll

... je instalirana na računaru (možda je u tome bio problem između
razlika u funkcionisanju na dva računara !?).

Ono što želim da kažem je da je izbor TRichEdit-a ili TMemo-a kao
prostora za podatke preko koga vršiš razmenu - loš izbor.

Bolje je da GLAVNO polazno i dolazno skladište bude najobičniji:


unsigned char POLAZNI_BUFFER[ NEKA_VELICINA ];
unsigned char DOLAZNI_BUFFER[ NEKA_VELICINA ];


... pa DOLAZNI_BUFFER ispiši u TRichEdit ako želiš grafičku
interpretaciju (pa šta ispadne).

Prethodno možeš uraditi rutinu za dodavanje koja će preskočiti
taj NULL (i sve ostale kodove koji se pokažu problematični) pre
dodavanja u TRichEdit-u.

Kada vršiš obrnuti proces koristi ponovo DOLAZNI_BUFFER da napraviš
POLAZNI_BUFFER, pa njega prikaži ponovo u TRichEdit.

Dakle radi sa POLAZNI_BUFFER i DOLAZNI_BUFFER kao *izvorom*
podataka, a grafičku interpretaciju vrši preko TRichEdit ili TMemo,
svejedno.

Kvalitet više bi bio da svaki karakter predstaviš u HEX formatu:

0 -> 00
...
255 -> FF

Ako ovako uradiš, nećeš morati da vodiš računa o NULL, niti i bilo
kome drugom rezultuatu kripcije. Program će ti raditi ya BILO KOJU
vrednost konstante za maskiranje.


Doduše, ako ćeš ISKLJUČIVO da kriptuješ običan TEKST, onda, sa
pažljivim izborom VREDNOSTI KONSTANTE za kripciju - nećeš imati
problema sa TRichEdit niti sa TMemo.


P.S.

Zbog čega ti sve ovo pričam. Jer imam veliko iskustvo u kriptovanju
i za neke firme sam razvio cele sisteme za licenciranje i zaštitu
softvera. Na primer ja KRIPTUJEM sve STRING TABELE u EXE-u. Napravio
sam poseban softver koji PROLAZI koz sve folder i sub-foldere od
nekog izabranog korenog foldera i KRIPTUJE sve STRING TABELE i
ostale RESURSE!!! ...






[Ovu poruku je menjao X Files dana 27.11.2005. u 09:07 GMT+1]
[ itf @ 28.11.2005. 15:14 ] @
Znaci, preko HEX-a pa ce raditi...
Inace, kako napraviti cast iz unsigned char-a u AnsiString? Zelim eventualno prikazati kriptirani kod. Uglavnom, skuzio sam sto si htio reci; NE KORISTITI MEMO I RICHEDIT KAO BUFFER!! :) vec sve direkt iz memorije.

[Ovu poruku je menjao itf dana 28.11.2005. u 16:29 GMT+1]
[ X Files @ 28.11.2005. 16:55 ] @
Citat:

Znaci, preko HEX-a pa ce raditi...


100%.

Citat:

Inace, kako napraviti cast iz unsigned char-a u AnsiString?


Snaći ćeš se - ne brini :) To nemoj da te buni... Uvek mozes da dodajes
podatke iz usigned char -> TStringList (richedit) bajt po bajt.

Citat:

Uglavnom, skuzio sam sto si htio reci; NE KORISTITI MEMO I RICHEDIT KAO BUFFER!! :) vec sve direkt iz memorije.


UPRAVO TO! Neka ti slobodno memo ili richedit budu neka vizuelna identifikacija,
ali nikako ne i izvor podataka. Dakle, sve radi direkno iz memorije.

Evo pogledaj kako izgleda moj standardni licencni kljuc:

Code:

# LICENSE CODE
# Created 13-Jul-2005
#
# Project:        Šivaće mašine
# Version:        1.0
# Build:          003
# License holder: Vladimir Stefanović
# License type:   Full version
# Host ID:        #T2#F4D61AA6#000343774584#0011097DF778
#
# Begin

4DA2C0BB6403A060EF6625D6BA57501B643A852E35CB624B8327290BA1236617
725059618E2FCD975BE65962A7FC5925586E158AB58BD56BF9FD238CDDC68BC4
DEE23F3AEF0F752AC096F5329A159B54E1D75DCC677E0E4E6AACD9D193DAE515
A59F03949D46B67C96572DE647350B09D90D55779D392C61C9D12436447C6BB9
27D884842F81C2F90B79EE3EE8B5E482154935A5FB78EE8ED25F20CFE35CB7B0
B14C7E2E9E5BEADC5F5B38BB53EC603A20F1CA750BDC833A98E86108AE835F2E
4614415664D93DDBC2CE2F1B2C77F524E09E4A33D3F0C449BCAF3EB557F0CD87
572779E0F607FA69F7ADB2FF59E61876768BCB43BE59C22B968053D3122717DB

# End


... e sad, ovaj deo gde su ona silna slova i brojevi, on je kriptovan, ali tako da ja
(da bih izbegao probleme sa kojima si se susreo), vrsim konvertovanje, npr:

Kada treba da upisem NULL ja ga pretvorim u '00', kada treba da upisem 13,
je upisem '0D', itd...