Salve a tutti  , da python 3 vi è una distinzione molto rigida tra stringhe e bytes, ad esempio, prima di mandare dati utilizzando il modulo socket, su python 3 dobbiamo effettuare un casting a bytes con codifica "utf-8".
Volevo dunque decriptare "l'archivio" Login Data di Google Chrome, allora la porzione di codice che ho utilizzato per recuperare la chiave è la seguente:

[codice]
prova = risultato[2]
chiave = win32crypt.CryptUnprotectData(prova, None, None, None, 0)[1]
[/codice]

Su python 2 funziona tranquillamente, mentre su python 3 sapevo che per il motivo sopracitato, non avrebbe dato il risultato sperato...
L'errore è giustamente il seguente:
pywintypes.error: (-2146893813, 'CryptProtectData', 'Chiave non utilizzabile nello stato specificato.')

La codifica del "risultato[2]" è in "ISO-8859-1", così ho pensato di decodificarla a stringa, per poi ricodificarla a utf-8 e darla in pasto a "CryptUnprotectData", in questo modo:

[codice]
decoded = risultato[2]
decoded = risultato[2].decode("ISO-8859-1")
decoded = bytes(decoded,"utf-8")
        
chiave = win32crypt.CryptUnprotectData(decoded, None, None, None, 0)[1]
[/codice]

Ma questa volta mi viene restituito:
chiave= win32crypt.CryptUnprotectData(decoded, None, None, None, 0)[1]
pywintypes.error: (13, 'CryptProtectData', 'Dati non validi.')
Potreste chiarirmi questa cosa?  

> La codifica del "risultato[2]" è in "ISO-8859-1"
e tu di questo sei totalmente assolutamente profondamente incrollabilmente certo, sì?

> decoded = bytes(decoded,"utf-8")  
e chi ti dice che utf-8 sia proprio la codifica giusta da passargli? Il problema è che queste cose in py2 tendevano a passare sotto silenzio, ma in py3 tutto va messo in discussione. Bisognerebbe vedere il sorgente, e capire quello che fa. Comunque immagino che la chiamata python sia solo un wrap intorno alla chiamata delle primitive di windows... e se siamo su windows, "utf-8" non è cittadino di prima classe. Proverei come minimo "utf-16", "utf-16-le", perfino "cp1252"... boh?

In generale, tenderi a semplificare, separando i problemi. Prima fai qualche prova solo con le librerie (parti da stringhe note, criptale e decriptale verificando a ogni passaggio se sono stringhe o bytes, e in che codifica sono). Una volta che hai capito, aggiungi chrome al problema.

Non sono totalmente sicuro che la codifica sia "ISO-8859-1", ma insieme a "ISO-8859-2", è l'unico modo per decodificare senza ricevere un errore, per togliere ogni dubbio, questa è la chiave codificata che mi spunta:

b'x01x00x00xh00xd0x8cx9dxdfx01x15xd1x11x8czx00xc0Oxc2x97xebx01x00x00x00=x10~xbax05Axbaxf5ASxbbDNex00x00x00x00x02x00x00x00x00x00x10fx00x00x00x01x00x00 x00x00x00^xfabM(xf91H3xc8xc5*xafxfc}x16x9d5x8fx7f*@x8a2x08C0sx1f$Qx8e*xe1x00x00x00x00x0ex80x00x00x00x02x00x00 x00x00x00|x04x12xfd4xa8xddLcxa8xddx17xe7^xa4%xd2xf3wIY&xba^xa5xc1Kxc9xefx8axf0px10x00x00x007xb3xd59xacx92xcb:xc1x9fOxa9Jxcfx86j@x00x00x00xaakL8x89x96;xe8x83x8fx9dxc1qxf9xffxd0exd6Lxd6tLxc8xb7xffHvx1b"xb9x97x07xc3x155xf3x97xe7x04x027x87xecx82hxdfax93xc3ixf8HL_xaehx18x82cx96Rx93fx7fqxa1'

Ho fatto una serie di tentativi con le codifiche che mi hai suggerito, sempre dati non validi, purtroppo.
Questo è invece l'intero sorgente:

import sqlite3, win32crypt
from os import getenv

conn = sqlite3.connect("C:Login Data")#C:Users"nome user"AppDataLocalGoogleChromeUser DataDefaultLogin Data
cursor = conn.cursor()

cursor.execute('SELECT action_url, username_value, password_value FROM logins')
for risultato in cursor.fetchall():
        
        decoded = risultato[2]
        #ecoded = risultato[2].decode("ISO-8859-1")#decodifica anche con "ISO-8859-2"
        #print(decoded)
        #decoded = bytes(decoded,"utf-8")
        
        chiave = win32crypt.CryptUnprotectData(decoded, None, None, None, 0)[1]

        if chiave:
                print('Sito: ' + risultato[0] + '/nUsername: ' + risultato[1] + '/nPassword: ' + password.strip().decode('utf-8'))

Non so se questo modo di codificare e decodificare sia totalmente esatto
Probabilmente avranno ottenuto un beneficio di qualche tipo a creare problemi che in py2 non c'erano, però...

Ah. Ti pareva che mancava qualcosa, finora.

Avevi trascurato il piccolo dettaglio (piccolo, eh?) che stai leggendo questi valori da un database sqlite.

Uhm.


E chissà come diavolo sono conservate le password in un database sqlite? A occhio, direi in un campo BLOB. Ma siccome tutti abbiamo Chrome installato, tanto vale controllare. Apro il db in questione, e sì, in effetti le password sono dei BLOB dentro il database.
Ok, e facciamo un passo avanti. Usi sqlite3 per leggere da python il db... e quindi sqlite3, come converte i BLOB? E qui ecco che arriva la fregatura: in python2, i BLOB sono restituiti come "oggetti buffer". In python 3, invece, i BLOB sono restituiti come bytes. https://docs.python.org/2/library/sqlite3.html#sqlite-and-python-types (switchare tra la versione 2.x e la versione 3.x della documentazione per vedere la differenza).

Uhm.
Ora, in python 2 esisteva appunto la funzione built-in buffer() che convertiva per esempio una stringa in un oggetto buffer. In python 3 questa funzione non esiste più. Ora, è vero che il tipo "bytes" dovrebbe supportare il protocollo buffer, ma comunque un oggetto bytes non è un oggetto buffer.
Da quello che mi dici, pare che win32crypt.CryptUnprotectData nella versione per python 2 si aspetta di ricevere appunto un buffer (e tu non te ne sei mai accorto, perché gli passavi direttamente quel che leggevi dal database, senza chiederti nulla).
La stessa funzione, nella versione per python 3, che cosa si aspetterà? Va a sapere, ma probabilmente un buffer o oggetto analogo. E qual è l'oggetto analogo a un buffer in python 3? E che ne so?   Forse un memoryview...

Morale.
Primo, se ci raccontavi tutta la storia fin dall'inizio, forse non facevi perdere tempo a un po' di gente.
Secondo, vedi il primo punto.
Terzo, vedi ancora il primo punto.
Quarto, dubito a questo punto che sia un problema di encoding. (e del resto, col senno di poi, l'errore  'Chiave non utilizzabile nello stato specificato' non sembra in effetti un problema di encoding).
Quinto, ti sei probabilmente ficcato in un ginepraio di api non documentate e complicate. E' possibile che qualcuno più in gamba di me con i buffer, le memoryview etc. ti sappia dire qualcosa di più. Intanto, potresti provare un po' alla brutta a convertire semplicemente in memoryview il tuo valore, così come lo leggi dal db, e passarlo alla funzione di decrittazione senza niente altro. Magari se hai fortuna funziona.

Io ti ringrazio enormemente per avermi chiarito questa cosa, ma prima che io legga tutti quei punti. Ti invito a leggere il titolo della discussione stessa:
"Decriptare il LOGIN DATA di chrome".
Mi hai aiutato tanto, e non vorrei sembrare scortese,ma visto che tu con tutti quei punti non ti sei creato proprio il problema, allora ti informo che il file "Login Data" È un database sqlite, per carità, magari non lo sapevi e avrei dovuto, per sicurezza, specificarlo, e di questo mi dispiace, ma non ho omesso niente nel topic.
Proverò comunque quanto detto, grazie 

Eh sì, avresti dovuto.
Altrimenti, la prossima volta il rischio è che ti sorprendi che su questo forum non ci sono dei telepati in grado di capire le tue domande (suvvia, mi sembra ovvio quel che volevo dire! un po' di lettura del pensiero, che sarà mai).
Il punto è che fare una domanda è sempre affare di 5 minuti. Dare una risposta, anche se non sembra, richiede tempo, attenzione, scrupolo di coscienza. Non ti esponi mai a fare una domanda, ma se dai una risposta del c*, ci fai una figura di m*. Quindi, controlli e ricontrolli tre volte. Costa tempo e fatica (ovvio, poi ci sono i casi in cui semplicemente sai la risposta - ma sono rari). Per dire, il post qui sopra mi è costato 30 minuti buoni di ricerca. 30 minuti, contali, non sono pochi. Contali - davvero però, contali: resta esattamente 30 minuti senza fare assolutamente nulla. Giusto per renderti conto.
Quindi, la minima richiesta è: postate il codice, non nascondete le cose, dateci gli elementi per aiutarvi senza dover fare ogni volta la caccia al tesoro.
Comunque, ehi, nessun problema - resta sempre la possibilità di lamentarsi della scarsa qualità delle risposte di questo forum.

Non capisco, né accetto, tutto questo accanimento, neanche avessi postato l'intero sorgente dopo 10 pagine di discussione... è chiaro e visibile dopo ben un messaggio, quale caccia al tesoro?
Se non sapevi che il Login Data di Chrome fosse un database sqlite (perché giustamente i dati sensibili di chrome sarebbero stati dentro un txt), non potevi iniziare con il chiederti cosa fosse il fantomatico Login Data, ovvero l'oggetto principale del topic stesso?
Mi hai voluto concedere tu 30 minuti del tuo tempo "perso", nonostante io non ti abbia chiesto nulla, me lo vuoi far pesare ancora?
Non fraintendiamo, ti ho ringraziato più volte, in ogni mio messaggio, ma piuttosto che sorbirmi i tuoi messaggi frustrati, alla quale sto contando e ricontando fino a 10 prima di risponderti, preferisco che questo topic chiuda.
e no, non "resta sempre la possibilità di lamentarsi della scarsa qualità delle risposte di questo forum", mi pare di non essermi mai lamentato di questo forum, anzi, ne rimango sempre enormemente soddisfatto.
Ciao, e più che chiedere "scusa", altro non posso fare.

eseguire in parallelo il "vecchio" programma e il nuovo assicurandosi che il contenuto nell'oggetto decodificato sia lo stesso in entrambi i casi.

sappiamo già che non è così. In python2, sqlite3 mappa i blob con i buffer, mentre in python3 li mappa in bytes. Di qui in poi, le strade si biforcano, ancora prima di coinvolgere le win32.

A logica visto che buffer è un'interfaccia dovrebbe essere sufficiente un bytes.

Uhm, non credo.
Se (e ripeto: se) l'op in python 2 fa quello che credo che faccia, ovvero leggere un blob dal db tramite sqlite3 e passarlo direttamente alla funzione decriptante, senza nessuna operazione in mezzo, allora quello che lui sta passando è un "buffer object vecchio stile" come viene gentilmente chiamato nella documentazione https://docs.python.org/2/c-api/buffer.html#old-style-buffer-objects.
C'è differenza tra un "oggetto buffer" e una "interfaccia buffer".
In python 3, invece, lo stesso codice (senza operazioni in mezzo) passerebbe bytes. E l'op ci dice che non funziona passare bytes alla funzione decriptante.

Ora, andando a naso: questo è un "errore" di sqlite3, che ha cambiato la sua api da python2 a python3 sul modo di restituire i blob. win32crypt non avrebbe alcuna ragione di cambiare la sua api per accettare bytes invece di oggetti buffer, e non credo che lo abbia fatto: dopo tutto, è solo un wrapper rispetto alle primitive windows, e perché quelle dovrebbero cambiare?
Quindi mi aspetto che anche in python3 la funzione decriptante accetti "la cosa più simile a un oggetto buffer che si trova in python3": e visto che i buffer non ci sono più in python3, direi che la cosa più simile è un memoryview.
Direi anche, già che ci siamo, che toccherebbe a sqlite3 correggere il suo errore e mappare i blob con i memoryview, in python3: lo troverei più consistente. Ma forse c'è una ragione, non ho voglia adesso di andare a documentarmi.

Tutto questo, ripeto, andando a naso perché non ho le win32 installate (sorpresa... per uno che sviluppa su windows... lo so, ma non mi servivano mai...). Quindi il mio suggerimento sarebbe certamente quello di provare le due versioni passo-passo e controllare a ogni stadio i tipi dei valori passati... ma in python3, proverei a trasformare i bytes in memoryview prima di passarli alla funzione decriptante.
(una digressione interessante poi sarebbe questa: siccome i memoryview sono stati backportati anche in python2, sarebbe interessante provare a usare i memoryview anche in python2 per vedere se win32crypt li digerisce lo stesso).

E se non funziona, che cosa vuol dire? Non lo so, ripeto, non sono così ferrato su buffer e memoryview e win32. Ci vorrebbe un esperto, ma:
1) potrebbe darsi che buffer e memoryview siano diversi in qualcosa di determinante, e che win32crypt semplicemente non li accetti. Questo però sarebbe un baco di win32crypt nella versione per python3.
2) l'op potrebbe non aver convertito i bytes in memoryview nel modo che piace a win32crypt
3) potrebbe essere completamente un problema diverso (alla fine, magari l'encoding c'entra davvero in qualche modo, va a sapere)
4) potrebbe essere che ci sono altre condizioni al contorno che non sappiamo. Eh.

Dopo ore di sbattimento e spulciamenti, ho confrontato il codice del win32crypt di py2 con quello di py3.
Ed ho trovato cosa effettivamente cambia:
L'errore "win32crypt (pywintypes.error: (-2146893813, 'CryptProtectData')" per py2 è già gestito con relativa eccezione, mentre nel mio py3 non è gestito automaticamente nella mia versione di win32crypt, così ho aggiunto semplicemente un try con eccezione [codice]chiave = ""[/codice] nel codice di python 3.
Purtroppo ancora non funzionava (però l'errore ovviamente era scomparso), sono andato a spulciare quindi nella cartella:
"..AppData/Roaming/Microsoft/Crypto", qui ho cambiato nome alla cartella, e per farlo si deve prima spostare sul cestino, e ripristinarla da un altro percorso per poi cambiare il nome in "CryptoOld".
Il programma per grazia divina ha iniziato a funzionare su python3  .
Morale?
Vogliono gli stessi dati, e il parametro non è un buffer o memoryview, è di tipo bytes, mi ha fregato quell'errore da una parte gestito, e dall'altra no.
Comunque buffer e memoryview non sono compatibili al 100%, qui ho chiarito un po' di cose, se può essere utile:
http://python3porting.com/differences.html
Spulciando però negli esempi di win32crypt (utilizzo python 3.4):
[codice]import unittest
import win32crypt
from pywin32_testutil import str2bytes # py3k-friendly helper


class Crypt(unittest.TestCase):
    def testSimple(self):
        data = str2bytes("My test data")
        entropy = None
        desc = "My description"
        flags = 0
        ps = None
        blob = win32crypt.CryptProtectData(data, desc, entropy, None, ps, flags)
        got_desc, got_data = win32crypt.CryptUnprotectData(blob, entropy, None, ps, flags)
        self.failUnlessEqual(data, got_data)
        self.failUnlessEqual(desc, got_desc)

    def testEntropy(self):
        data = str2bytes("My test data")
        entropy = str2bytes("My test entropy")
        desc = "My description"
        flags = 0
        ps = None
        blob = win32crypt.CryptProtectData(data, desc, entropy, None, ps, flags)
        got_desc, got_data = win32crypt.CryptUnprotectData(blob, entropy, None, ps, flags)
        self.failUnlessEqual(data, got_data)
        self.failUnlessEqual(desc, got_desc)

if __name__ == '__main__':
    unittest.main()[/codice]
Salta nell'occhio la scritta "from pywin32_testutil import str2bytes # py3k-friendly helper"
il cast a str2bytes() restituisce un buffer binario, potrebbe essere uno strumento utile ogni qual volta non si capisca il problema (come nel mio caso, anche se ho risolto diversamente) fra le versione 2.x e 3.x, da qui quelle "biforcazioni" potrebbe essere colmate.
Esiste anche un str2memory()
Spero questo topic possa tornare utile a chi ha un problema di questo tipo.

@RicPol, quando faremo la pace ti offrirò un caffè