Encodage base64, c'est du Chinois !

[jmg49]

Bonjour,

auriez vous une explication simple sur ce phénomène étrange qui concerne l'encodage Base64 et l'unicode,

un exemple vaut mieux qu'un discours :

Code : Tout sélectionner

Exemple$ = "KERNEL32"
 
  
 
  Encoded$ = Space(1024) 
    
  Base64Encoder(@Exemple$, StringByteLength(Exemple$), @Encoded$, 1600)
  MessageRequester("hi", Encoded$ )

result = SOVSTkVMMzl=

activons donc la prise en charge de l'unicode ;


même code , result = 睓䙂䙁䅉杔䙂䕁䅷睍祁䅁䅁


hum,hum ....

[nico]

J'ai fouillé un peu sur le web et visiblement, on pourrait encoder une chaîne au format UTF8, ce qui veut dire que soit la fonction n'est pas prévu pour fonctionner en unicode (conversion utf8 en interne dans la fonction), soit il y a un bug.

[nico]

Normalement, pour que ça marche, il faudrait que purebasic convertisse la chaîne unicode en utf8 format web, ce qui donnerait par exemple pour "Ceci est une chaîne !":

Le résultat suivant: Ceci est une cha\xc3\xaene !

Soit a peu près la même chose que urlencoder mais en remplaçant % par \x sans conversion des espaces
Ceci%20est%20une%20cha%C3%AEne%20!

[nico]

Pour tester, j'ai utiliser ce service web et python:
http://uttool.com/encryption/base64/default.aspx#

Ce qui donne un result de : Q2VjaSBlc3QgdW5lIGNoYcOubmUgIQ==


En compilation ascii, on retrouve bien notre chaîne de départ, si on l'affiche en utf8:

Decoded$ = Space(1024)
Encoded$ = "Q2VjaSBlc3QgdW5lIGNoYcOubmUgIQ=="
Debug Base64Decoder(@Encoded$, StringByteLength(Encoded$), @Decoded$, 1024)
Debug PeekS(@Decoded$, -1, #PB_UTF8); Affiche bien : Ceci est une chaîne !

[nico]

Post au dessus édité, preuve que la fonction ne fonctionne pas en unicode alors que ça pourrait le faire.

[Fred]

Base64Encoder utilise un buffer, pas un string. On peut utiliser un string comme buffer, mais alors son interpretation variera. Cet example sera peut etre plus clair:

Code : Tout sélectionner

  Exemple$ = "KERNEL32"

  #BufferSize = 1024
  *Buffer = AllocateMemory(#BufferSize)
   
  Base64Encoder(@Exemple$, StringByteLength(Exemple$), *Buffer, #BufferSize)
  MessageRequester("hi", PeekS(*Buffer, #PB_All, #PB_Ascii))

A noter que le resultat varie entre unicode et ascii, ce qui est normal vu que Base64Encoder() encode un buffer binaire, donc "KERNEL32" en ASCII est different de "KERNEL32" en unicode.

[jmg49]

Merci pour vos réponses, il y a un petit malin qui a su exploiter ce comportement pour faire des appels d'API "en toute discrétion"

Code : Tout sélectionner

Global szVirtualAllocEx.s = "杖灂䡁䅉䅤ㅂ䝁䅅䅢䉂䝁䅷䅢療䝁䅍兒㑂䅁䅁"; szVirtualAllocEx.s = "VirtualAllocEx"
Global szWriteProcessMemory.s = "睖祂䝁䅫䅤求䙁䅁杣療䝁䅍党穂䡁䅍兔求䝁䄰睢祂䡁䅫䅁㵁"; szWriteProcessMemory.s = "WriteProcessMemory"

[Fred]

Je vois pas comment ca peut marcher..

[jmg49]

ben oui, mais pourtant , result du code = KERNEL32

Code : Tout sélectionner

Decoded$ = Space(1596)

Exemple$ = "睓䙂䙁䅉杔䙂䕁䅷睍祁䅁䅁"




 Base64Decoder(@Exemple$, StringByteLength(Exemple$), @Decoded$, 1600)
 
 MessageRequester("hi", Decoded$ )

alors pour Global szWriteProcessMemory.s = "睖祂䝁䅫䅤求䙁䅁杣療䝁䅍党穂䡁䅍兔求䝁䄰睢祂䡁䅫䅁㵁"; szWriteProcessMemory.s = "WriteProcessMemory"

CallFunction(hKernel32, PB_Base64DecodeString(szWriteProcessMemory),...... fonctionne bien.

[Fred]

Évidemment, passer un buffer aléatoire à CallFunction(), c'est vraiment chercher les ennuis ! . Je ne vois pas ou est "le petit malin" là dedans..

[jmg49]

la personne qui a codé ça avait un but qui est atteint, un anti virus qui surveille les appels d'api ne détecte rien, d'où " le petit malin",

la première version que j'ai eu datait de 2011 (pb 4.60) , complètement indétectée, maintenant ce n'est plus le cas malgré la modif et le portage du code pour 5.31 trouvée sur du forum russe.
détecté 10/35 antivirus dont certains très connus et payants

nouveaux langages = nouvelles menaces , il n'y a pas que des codeurs bien intentionnés

[djes]

Ce n'est pas la faute du langage, mais de l'OS, à mon avis.

[nico]

Ok, merci Fred pour les précisions.

Donc si on compile en ascii, le buffer est au format BASE64 Ascii
et si on compile en unicode, le buffer est au format BASE64 UTF16

Cela mérite quelques précisions dans l'aide.

[Fred]

Non, le format est toujours au format ASCII. Encore une fois, cette fonction n'est pas liée au strings, donc le flag unicode n'a aucun impact dessus.

[nico]

Je sais qu'il est toujours au format ascii mais l'encodage est différent puisqu'on obtient pas le même résultat; j'ai bien compris que c'est un buffer et non une chaîne mais le résultat est utilisable dans une page web normalement, non?