[C++] inlezen pkcs#12 *

[beany]

Ik ben bezig om in C(++) een PKCS#12 file te kunnen inlezen, echter dit lukt niet echt. Ik probeer een voorbeeld progje van openssl te compilen. Dit lukt, echter een fout treed op. De code:

C++:

    FILE *fp;
    PKCS12 *p12;

    SSLeay_add_all_algorithms();
    ERR_load_crypto_strings();
    
    if (!(fp = fopen("f:\\test.p12", "rb"))) {
        fprintf(stderr, "Error opening file %s\n", argv[1]);
        exit(1);
    }

    p12 = d2i_PKCS12_fp(fp, NULL);

De routine d2i_PKCS12_fp faalt, wat ik ook doe. En bovenstaand stukje code komt uit een voorbeeldje die meegeleverd wordt met de openssl source code. De foutmelding die ik krijg: 'Unhandled exception at 0x77f92373 in pkcs12test.exe: 0xC0000005: Access violation writing location 0x00000010'. En ja, de file f:\test.p12 bestaat en is een geldig p12 file. Ik kan hem zo in IE6 importeren, zonder problemen.

Op Internet is weinig te vinden over het inlezen van een pkcs#12 bestand. Ik heb wel de specs gevonden bij RSA, echter dat is een hoop mambo-jambo waar ik niet echt wijzer uit wordt. Verders vind je op internet aan code eigenlijk alleen maar het bovenstaande. Ik ben ook in de openssl code gaan tracen, maar ik kan de fout niet echt vinden.

Ik gebruik Visual Studio .Net 2003, Visual C++. OpenSSL versie 0.9.7b. Dit alles op Windows 2000 SP4.

Ik vermoed dat het een Windows -> Linux probleempje is. De openssl source is bedoelt voor linux. De win32 libraries lijken het verder wel gewoon te doen.

Heeft iemand dit gebeuren van openssl werkend gekregen? Of heeft er iemand een andere suggestie om pkcs#12 bestanden in te lezen(private key + certs)?

[MSalters]

Wat is 0x77f92373? Ik neem aan dat dat de functie d2i_PKCS12_fp() is? Heb je een stack trace van de AV? Wat is de tweede parameter van d2i_PKCS12_fp()? Mag die 0 zijn? Wat zou de functie moeten doen?

[Verwijderd]

Hmm, dat de source al compiled onder Windows zegt al heel wat.
Maar auteurs zeggen dat 'ie niet onder Windows werkt, dan tsja

Verder zou je altijd je eigen class kunnen schrijven voor 't inlezen van die bestanden, als 't niet een al te complex formaat is.

[beany]

@MSalters:
De functie zou een p12 structuur moeten aanmaken, vanuit het .p12 bestand. De 2e parameter zou naar mijn idee NULL moeten zijn. Stond zo in het voorbeeldje, en ik heb nog nergens gezien dat die functie werd ingevuld. Bovenstaande code komt is dus de een stukje uit het voorbeeldje, alleen de bestandsnaam heb ik even voor het gemak aangepast. Hij vindt het bestand wel, dat heb ik gestest(fread erachter).

Met de p12 structuur kan je de data uitlezen met andere functies. Maar zover kom ik dus al niet, omdat de struct niet gevuld kan worden.

@Anjelen:
Hij wordt geleverd in een .tar.gz file. Echter is OpenSSL toch op windows te vinden? Dus ik gok dat het duo is. Maar dan blijft de vraag: weet er iemand een andere manier om met die pkcs12 bestanden om te gaan?

En zelf inlezen: de specs van RSA zijn echt niet lollig. Heel abstract. Geen voorbeeldjes of wat dan ook. Zelfs geen lengte's van veldjes...

[The End]

Ik weet iig voor 100% zeker dat de OpenSSL library zonder problemen op Windows draait.
Kijk eens in de debugger bij welke functie hij crashed.

[madwizard]

Een stacktrace zou leuk zijn maar ik denk dat dit wordt veroorzaakt door een niet of op 0 geinitaliseerde critical section.
Op een win2kSP4 systeem valt 77f92373 in ntdll.dll, en wel in RtlpWaitForCriticalSection. Hij crasht op het wegschrijven van debug info in de CRITICAL_SECTION structure, omdat de eerste waarde daarbinnen (een pointer naar de debug info) op 0 staat.
Deze functie wordt gebruikt door RtlEnterCriticalSection en dat is precies dezelfde functie als de welbekende API EnterCriticalSection in kernel32.dll. De volgende code geeft exact dezelfde crash:

C++:

CRITICAL_SECTION sec = {0};
EnterCriticalSection(&sec);

Dus ik weet niet waar het precies fout gaat, maar ergens is denk ik een InitializeCriticalSection vergeten.. Of wat ook kan is dat de CRITICAL_SECTION structure op 1 of andere manier overschreven is maar dat lijkt me wat sterk.

edit
Net even de source doorzocht maar lijken geen critical sections in voor te komen.. Wel mutexes en die gebruiken hoogstwaarschijnlijk intern weer critical sections, maar ik denk niet dat daar in de source een bug zit.. Heb je de goede runtime gebruikt (dat is, dezelfde waarmee de library compiled is)? Dat zou ook goed het probleem kunnen veroorzaken (zie ook hier).

[ Voor 22% gewijzigd door madwizard op 28-07-2003 17:48 ]

[beany]

Hmmm, de juiste runtimes... Dat zou het wel eens kunnen zijn. Zit momenteel niet op mijn werk, dus ik kan het niet testen, maar het klinkt erg goed

Wat betreft die critical sections e.d. Die worden in de voorbeeld code niet gebruikt, en tijdens het doorbladeren van de openssl lib aangaande de pkcs code kwam ik het ook niet tegen, maar het zou op een dieper niveau kunnen liggen. Maar dan zou er dus een bug in de openssl code moeten zitten, want ik gebruik alleen maar openssl code + openssl example. Ik ga er morgen nog eens voor zitten... Ik laat het weten! Thankx voor de info!

edit: op die faq van openssl

your program will crash, typically on the first BIO related read or write operation

Klopt als een bus. Tijdens het debuggen knalt op een bio functie. 95% zeker dat dit het is. Stom dat ik die faq heb gemist Dan lijkt het een onoverkomelijk probleem, dan post je het op got en blijkt het toch iets simpels te zijn

[ Voor 25% gewijzigd door beany op 28-07-2003 18:13 ]

[MSalters]

0x77f92373 < 0x80000000, dus het is in USER-space. Welke DLL waar staat hangt af van je OS, en andere DLLs. Dus op basis van een systeem voorspellen hoe een ander systeem z'n geheugen mapt werkt niet. Wat wel werkt is een stack trace op de machine in kwestie, met debug symbolen voor de systeem DLLs. Dan heb je de echte naam.

Dat een CriticalSection dezelfde fout geeft is niet onwaarschijnlijk, een AV in de buurt van 0 is heel gangbaar. Dat komt door een onterechte null-pointer, vandaar dat ik me afvroeg wat de NULL in het example betekende. Als de TS dat al niet weet geef ik 'm weinig kans om zo'n port te doen.

PS. BIO functie is geen gebruikelijke term. Wat betekent dat?

[madwizard]

MSalters schreef op 28 July 2003 @ 18:59:
0x77f92373 < 0x80000000, dus het is in USER-space. Welke DLL waar staat hangt af van je OS, en andere DLLs. Dus op basis van een systeem voorspellen hoe een ander systeem z'n geheugen mapt werkt niet. Wat wel werkt is een stack trace op de machine in kwestie, met debug symbolen voor de systeem DLLs. Dan heb je de echte naam.

0x80000000+ is kernel space, maar systeem DLLs worden gewoon in user space geladen hoor, kernel32, user32, en ook ntdll worden allemaal op addressen lager dan 0x80000000 geladen. En natuurlijk zijn de adressen niet gegarandeerd, je kan altijd hebben dat ze gerelocate worden maar de base adressen van systeem DLLs worden vrijwel nooit door andere DLLs gebruikt (als die uberhaupt al niet op het default 0x10000000 zijn blijven staan). Je moet ook nooit van harde adressen uitgaan ofzo maar aangezien ik hier precies dezelfde windows versie heb draaien was het geen slechte gok om het adres gewoon op te zoeken.. En ik ben er ook nagenoeg zeker van dat het om hetzelfde stuk code gaat, ook omdat de crashende regel is:

code:

77F92373: FF 40 10      inc [eax+10]

eax is 0, eax + 10 geeft een access violation op adres 10. Als je de boel terug traced kom je uit dat eax de eerste dword van de CRITICAL_SECTION is en dat *hoort* een pointer te zijn naar een of andere debug structure.

Dat een CriticalSection dezelfde fout geeft is niet onwaarschijnlijk, een AV in de buurt van 0 is heel gangbaar. Dat komt door een onterechte null-pointer, vandaar dat ik me afvroeg wat de NULL in het example betekende. Als de TS dat al niet weet geef ik 'm weinig kans om zo'n port te doen.

Het zal niet direct aan een critical section liggen, maar deze wordt wel ergens gebruikte. Het feit dat ie crasht kan komen doordat ie niet geinitialiseerd is, maar dat zou echt een bug zijn, of dat de structure beschadigd is. Dat laatste is niet ondenkbaar als je verschillende runtimes gebruikt, omdat bij het doorgeven van data onderling dan wel eens wat pointertjes scheef zouden kunnen staan.

PS. BIO functie is geen gebruikelijke term. Wat betekent dat?

Misschien binary I/O ofzo (weet het ook niet hoor maar een gokje..)

[beany]

@madwizard:

Begrijp ik je nou verkeerd, of heb je de openssl zitten doorkijken?

[madwizard]

beany schreef op 28 July 2003 @ 23:16:
@madwizard:
Begrijp ik je nou verkeerd, of heb je de openssl zitten doorkijken?

Hij crasht niet in openssl maar in ntdll, van daaruit heb ik verder gekeken naar wat de oorzaak was.. Een foute CRITICAL_SECTION (hoe dat dan ook veroorzaakt mag zijn), daarna heb ik even naar de source van openssl gekeken ja (niet gecompiled) of ik daar iets zag van critical sections maar verder niet echt naar gekeken. Is dat wat je bedoelt?

[beany]

Nope, het is niet de runtime instelling.... Heb wel de output van de stack trace:

code:

>   NTDLL.DLL!77f92373()    
    KERNEL32.DLL!7c4e73e5()     
    msvcrt.dll!78001532()   
    NTDLL.DLL!77f922f8()    
    msvcrt.dll!7800efdf()   
    msvcrt.dll!78022f30()   
    msvcrt.dll!780014cf()   
    libeay32.dll!10033f48()     
    libeay32.dll!100324c7()     
    libeay32.dll!10048613()     
    libeay32.dll!100328f1()     
    libeay32.dll!1004859a()     
    libeay32.dll!10048541()     
    libeay32.dll!100484ea()     
    libeay32.dll!10075285()     
    pkcs12test.exe!main(int argc=4, char * * argv=0x007b4d98)  Line 36 + 0xb    C++
    pkcs12test.exe!mainCRTStartup()  Line 398 + 0xe C
    KERNEL32.DLL!7c4e87f5()

Wat ik alleen niet begrijp is waar die libeay32.dll vandaan komt. Ik gebruik toch de .lib

Ik heb trouwens verschillende runtime's getest, geen van allen werkt. Bij elke poging een clean gedaan.

[MSalters]

Ja - en nou met symbols names graag.
Die DLL komt omdat je de .lib stub hebt gelinkt. Kijk eens hoe klein die is, daar kan nooit alle functionaliteit inzitten.

[beany]

De lib is 535kb.

Hoe krijg ik in Visual Studio.net 2003 de symbols erbij dan?

Ik ben momenteel bezig om alles overnieuw te doen. Ben openssl opnieuw aan het compileren... Heb het idee dat er ergens 'ouwe troep' rond hangt...

[beany]

Het werkt!

Ik heb OpenSSL opnieuw gecompileerd, en ALLE libeay32.dll 's op mijn machine vervangen. Er stonden er namelijk een paar Weet niet precies waar ze vandaan komen. Het risico is dus dat er andere applicaties niet goed kunnen werken: so be it.

Dank aan allen voor de hulp!!

[madwizard]

Als een DLL geladen wordt, is de volgorde waar ie gezocht wordt:

code:

1. directory waar je programma staat
2. de huidige directory
3. systeem directory (system32)
4. 16-bit systeem directory (system)
5. windows directory
6. PATH directories

Dus als de *goede* dll gewoon in de map van je programma staat moet het werken.. Onafhankelijk van alle andere versies die geinstalleerd zijn.

[beany]

madwizard: ik geloof je meteen, en het zal ook zo zijn. Toch had ik er ruzie mee, wat er in resulteerde dat ik alle dll's maar heb vervangen. Wazig...

[MSalters]

beany schreef op 29 July 2003 @ 10:20:
De lib is 535kb.

Hoe krijg ik in Visual Studio.net 2003 de symbols erbij dan?

Zorgen dat je de .PDB file bij de .DLL hebt, in dezelfde directory.