迅维网

标题: SONY VAIO One Time Password OTP 解密软体代码 [打印本页]

作者: hotrain88    时间: 2010-11-15 21:59
标题: SONY VAIO One Time Password OTP 解密软体代码
SONY VAIO  One Time Password OTP 解密软体代码 ,懂编程的高手,有兴趣的下载打包咯,是代码!!!不是可执行文件。

sony.rar

3.4 KB, 下载次数: 87, 下载积分: 下载分 -2 分, 下载 1 次

SONY VAIO One Time Password OTP 解密软体代码


作者: dujunsan    时间: 2010-11-15 22:48
什么破东西,骗人
作者: dujunsan    时间: 2010-11-15 23:28
我是程序员,这个代码是求反函数的,和VAIO的密码毫不相关
作者: dujunsan    时间: 2010-11-15 23:31
温度转换,华氏度转摄氏度
== Real-world examples ==
For example, let ? be the function that converts a temperature in degrees [[Celsius]] to a temperature in degrees [[Fahrenheit]]:
:<math> f(C) = \tfrac95 C + 32 ; \,\!</math>
then its inverse function converts degrees Fahrenheit to degrees Celsius:
:<math> f^{-1}(F) = \tfrac59 (F - 32) . \,\!</math>

Or, suppose ? assigns each child in a family its birth year. An inverse function would output which child was born in a given year. However, if the family has twins (or triplets) then the output cannot be known when the input is the common birth year. As well, if a year is given in which no child was born then a child cannot be named. But if each child was born in a separate year, and if we restrict attention to the three years in which a child was born, then we do have an inverse function. For example,
:<math>\begin{align}
f(\text{Alan})&=2005 , \quad & f(\text{Brad})&=2007 , \quad & f(\text{Cary})&=2001 \\
f^{-1}(2005)&=\text{Alan} , \quad & f^{-1}(2007)&=\text{Brad} , \quad & f^{-1}(2001)&=\text{Cary}
\end{align}
</math>

作者: dujunsan    时间: 2010-11-15 23:33
骗你没商量
作者: hotrain88    时间: 2010-11-15 23:43
回复 dujunsan 的帖子

How to protect better: Secure BIOS Passwords for Laptops
Since I get a lot of visitors from within the networks of computer vendors (hi guys!), I might as well just give you some hints on how to implement a laptop password in a more secure way. I understand that a lot of your customers forget their passwords and that it's just too expensive for you and your customers to swap the mainboards each time this happens. Also, you are prone to use the lame password implementations of the BIOS vendors. Don't - do your own stuff. Here are a few advices free of charge on how to do better:

Use better hashing functions for the passwords. CRC16, CRC32, etc. are a bad choice - they are invertible, and even if they weren't, a modern machine can find a hash collision within seconds because the keyspace is only 2^32 in size. Various implementations of better algorithms such as MD5 and SHA1 are readily available.
Use the machine's serial number in conjunction with the MAC address of the network card to salt the password before hashing it. If the password isn't set, just use both of these to check a hash stored in your 'NVRAM' anyway. This makes it a bit harder to just clone an EEPROM, FlashROM, or any other chip.
Try to calculate some portions of the algorithm not on the main CPU, but on the keyboard controller.
If the password can't be verified, generate a random number from the RTC the third time an invalid password has been entered. Salt it heavily with serial numbers (laptop, MAC, CPU, etc.). Then hash it to generate a one-time password (OTP). Use public-key cryptography on the OTP, e.g. elliptic curves. DO NOT STORE THE PRIVATE KEY IN THE BIOS. Output the result to the screen, making sure that it is properly encoded ('O' vs '0', checksums). Do not save the one-time password anywhere. In fact, wipe it from the memory just after it has been encrypted. Make sure that it's really zero'd out everywhere (CPU cache).
When a customer calls the support and asks for a password reset, verify that he is indeed the owner of the laptop. Let him read the encrypted and encoded OTP to you, then calculate the OTP by decoding and decrypting it using your private key.
Do not hand out service tools to your service team which contain the private key. Instead, run a central password service on a server which is secured and can only be accessed with proper authentication. Actively monitor each and every access.
Do not charge customers for resetting a password. That's just lame.
So.. I'm eager to see something more advanced than your current lame attempts at password protection
作者: hotrain88    时间: 2010-11-15 23:46
回复 dujunsan 的帖子

Since I get a lot of visitors from within the networks of computer vendors (hi guys!), I might as well just give you some hints on how to implement a laptop password in a more secure way. I understand that a lot of your customers forget their passwords and that it's just too expensive for you and your customers to swap the mainboards each time this happens. Also, you are prone to use the lame password implementations of the BIOS vendors. Don't - do your own stuff. Here are a few advices free of charge on how to do better:

Use better hashing functions for the passwords. CRC16, CRC32, etc. are a bad choice - they are invertible, and even if they weren't, a modern machine can find a hash collision within seconds because the keyspace is only 2^32 in size. Various implementations of better algorithms such as MD5 and SHA1 are readily available.

CRC16, CRC32
http://en.wikipedia.org/wiki/Inverse_function

作者: hotrain88    时间: 2010-11-15 23:49
回复 dujunsan 的帖子

Use the machine's serial number in conjunction with the MAC address of the network card to salt the password before hashing it. If the password isn't set, just use both of these to check a hash stored in your 'NVRAM' anyway. This makes it a bit harder to just clone an EEPROM, FlashROM, or any other chip.
Try to calculate some portions of the algorithm not on the main CPU, but on the keyboard controller.
If the password can't be verified, generate a random number from the RTC the third time an invalid password has been entered. Salt it heavily with serial numbers (laptop, MAC, CPU, etc.). Then hash it to generate a one-time password (OTP). Use public-key cryptography on the OTP, e.g. elliptic curves. DO NOT STORE THE PRIVATE KEY IN THE BIOS. Output the result to the screen, making sure that it is properly encoded ('O' vs '0', checksums). Do not save the one-time password anywhere. In fact, wipe it from the memory just after it has been encrypted. Make sure that it's really zero'd out everywhere (CPU cache).
When a customer calls the support and asks for a password reset, verify that he is indeed the owner of the laptop. Let him read the encrypted and encoded OTP to you, then calculate the OTP by decoding and decrypting it using your private key.
Do not hand out service tools to your service team which contain the private key. Instead, run a central password service on a server which is secured and can only be accessed with proper authentication. Actively monitor each and every access.
Do not charge customers for resetting a password. That's just lame.
So.. I'm eager to see something more advanced than your current lame attempts at password protection.

Use public-key cryptography on the OTP, e.g. elliptic curves. DO NOT STORE THE PRIVATE KEY IN THE BIOS.
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography
作者: 552152750    时间: 2010-11-16 10:59
就看你们在上面拽英文了。。。。。。每看见解决问题的。。。。
作者: 联想的海    时间: 2010-11-17 13:07
期待,基地软件高手奉献。
作者: 王凡林    时间: 2010-11-20 12:43
基地硬件高手很多,但是编程高手可就少了,这是一个硬件维修网站论坛,有关软件很少涉及




欢迎光临 迅维网 (https://www.chinafix.com/) Powered by Discuz! X3.4