4 ms·
Does anybody know the .dylib or binary file where this function resides on OSX? I can't find libsecurity_ssl on my system. It should relatively simple to NOP o
by steeve 13y ago
Does anybody know the .dylib or binary file where this function resides on OSX? I can't find libsecurity_ssl on my system.
It should relatively simple to NOP out the 2nd goto, if the rest of the function hasn't been optimised away.
- nteon 13y agoI would be really surprised if the rest of the function was still there - this seems like the perfect example for a dead code elimination compiler pass.
- apaprocki 13y agoThe static function that has the bug will most likely be inlined into the other static function which will then be inlined into the outer public symbol that calls it. I believe you can dump the assembly of the entire function like this: otool -t -p _SSLProcessServerKeyExchange \ -V /System/Library/Frameworks/Security.framework/Versions/A/Security | less edit: I believe this could be the offending instruction: 0000000000086df6 jmp 0x86e0d edit2: That is actually in SSLVerifySignedServerKeyExchangeTls12(). Trying to track down the real one.. edit3: Looks like the compiler did optimize it out if I'm reading it correctly now. The code is around 0x86c97. It does the last if() call and then immediately calls SSLFreeBuffer() and jumps to the end. :(
- steeve 13y agoConfirmed here too :( 0000000000086c80 callq *%r14 ; SSLHashSHA1.update(&hashCtx, &signedParams)) 0000000000086c83 movl %eax, %ebx 0000000000086c85 testl %ebx, %ebx 0000000000086c87 jne 0x86c9c 0000000000086c89 leaq 0xffffffffffffff38(%rbp), %rdi 0000000000086c90 leaq 0xffffffffffffff58(%rbp), %rsi 0000000000086c97 callq *%r14 0000000000086c9a movl %eax, %ebx 0000000000086c9c leaq 0xffffffffffffff08(%rbp), %rdi 0000000000086ca3 callq _SSLFreeBuffer