最近闲来无事，发现flash id引发很多争议，所以突然起了点好奇心想看看这个软件工作原理，于是有了本文。
总体来说flash id做了两件事情：
1、通过deviceiocontrol与固态主控通信信息，将固态主控内部信息复制进内存以便操作。
2、通过主控信息自行判断部分固态信息（例如颗粒层数，tlc或qlc）并显示，此软件的原理和台风（内存颗粒识别软件）非常类似，均是通过现有数据自行逆推相关信息。
首先叠buff，逆向程序上纲上线的说是不合规且不道德的，本次逆向仅仅只是为了探究软件原理，因本人对主控硬件方面不熟悉，也不熟悉固件开发，无法验证作者判断颗粒的方式是否正确，只能从软件本身入手。而且本人已有10年没有正经写过代码或进行过逆向了，目前水平非常生疏，也归功于作者没有在软件防护上做太多文章，所以才能让本人顺利进行分析，尽管如此，限于水平问题，肯定也有很多不足之处，还望有经验的多指正。
本次以联芸maxio flash id为例，其他家颗粒识别原理应该是大同小异。
该程序应该为C/C++编写，未采取加壳等任何保护措施。首先查看程序的text锻，在text段落发现许多内置字符串变量，每个字符串都给出一个定义（define）
amicron
例如这个a26nm变量实际被定为成了26nm，代表制程，以此类推上面的amicron变量被定义成了micron，不再一一截图说明
甚至大家关心的颗粒类型TLC/MLC/SLC字样也是预先写在数据库的
软件获取硬盘信息的方法是通过deviceiocontrol函数与其进行通讯，在第二个参数中发送特定的控制码，获得主控返回的信息并复制进内存中，该部分信息在后续进行处理后显示。该控制码为16进制码而且是硬编码，并非微软在MSDN给出的那几个固定可选参数，因此猜测作者应该是通过某些手段得知了厂商主控开发手册或者也是通过逆向扒了厂商流出的开卡软件，得知了通信的机制，或者说利用了厂商的debug功能或者后门？曾经听主控厂的大佬谈起过，说固件本质上是一堆二进制，而且很多主控是ARM架构，可能确实不能直接兼容X86的参数，所以作者采用了硬编码，把对应的二进制变成了16进制代码发送过去（以上属于猜测，再次强调，本人没有任何主控和固件开发经验），主控收到了“暗号”就发回了信息，然后程序将信息复制进内存中并提取相关信息。
通过特定的iocontrolcode（硬编码2D1400h）与固态进行通信
计算后根据结果跳转至对应的程序段，显示对应的结果，例如结果为0x9b证明为ymtc，程序会跳转至相应的程序段并显示ymtc
也可以留意一下flash id的显示结果，在flash id前有一段十六进制代码，其中代码就包含了相关信息，程序通过和数据库匹配查询结果，例如0x9b代表ymtc。
在获得返回值后读取了进行一些数据操作，虽然本人能分析出相关算法，但是因为不了解主控及固件信息工作原理，无法判断该算法是否正确有效，感觉写出来意义也不大，最重要的事情是分析出flash id是通过一定数据处理后判断的。在处理之后，会根据返回值查找数据库匹配并显示出颗粒厂商、层数、nand string等等一系列信息，相关数据是从数据库提取出来的。
根据计算结果显示是镁光或海力士或三星
至于大家关心的tlc/qlc，flash id采用的应该是读取内存特定地址信息（也就是主控返回的信息）后根据其数字直接显示出来的（1代表slc，2代表2bit mlc，3代表tlc以此类推），表面上看是那回事，不过因为主控厂商没有公布其数据结构标准，依然无法证实其准确性。
在这里本人有个猜想，主控厂一般应该将颗粒类型编号等信息写进了固件中（例如1代表镁光，2代表海力士，a代表制程14nm，α代表slc，β代表2bit mlc等等这类）并按照一定结构进行存储，这点在流出的开卡工具中有所体现，那么flash id也可以通过读取相应的编号逆推出颗粒类型，这应该就是flash id的工作原理，当然前提是得知主控厂的数据存储方式。
在进行判断后在程序中显示出相应的判断信息
综上，程序将很多的字符串内置进程序本身（虽然非常原始，但是小容量数据直接写进程序本身对console application来说确实不算啥）充当数据库，通过判断读取的信息去一一调取对应字符串，需要强调的是程序是通过判断主控内部信息进行一定计算操作后，根据其结果调用相应的字符串，而非直接读取主控固件原生信息或者smart信息来显示厂商和颗粒类型。
所有的厂商、颗粒层数、制程信息均为程序内置数据库中调取，如果程序未更新，数据库版本落后，可能导致无法正确识别信息的情况（如果用老版本flash id去识别232l ymtc就无法识别，因为数据库中根本没有232l这个字符串所以显示不出来）。而且正因为不是直接根据主控原始信息显示，在无法保证作者的计算判断公式永远是正确的前提下，假如厂商的新主控更改了数据存储结构或方式（当然jedec有没有强制规定主控固件的数据结构本人不清楚，如果没有那理论上主控厂是可以随便改的），很可能造成错误识别或无法识别。
同时，通信是个技术活，因为作者发送的消息是硬编码，固态本质上也是一个小计算机，对固态进行操作，也会存在各种各样的风险，要么就是新款主控的通信方式不同，不吃flash id那一套，你发的是啥？暗号？我不懂，滚吧！主控就不会返回任何信息，导致啥都查不出来，第一步就进行不下去了（例如SM2320，用慧荣flash id无法查询颗粒信息就是在主控第一步通信时就死了）。要么虽然能识别，但固件上有些不同，导致在通信的时候主控不能按照作者的意图正常解析（也有可能是作者硬编码的原因，毕竟硬编码这个东东弊端还是有的，但考虑到flash id的特殊性好像也没有什么好办法），然后出错导致固态死机了，也就是掉盘，flash id读盘掉盘的事情时有发生应该是这个原因。
最后想强调的是，正因为软件是通过判断主控内部信息进行一定计算操作后，根据其结果查询数据库显示的结果，并非直接读取SMART或者主控发回信息明文显示了相关nand内容，在相关算法和对应关系无法明确确定的前提下，用flash id结果作为查询颗粒的确定证据是非常不合适的，因为没法证明程序的原理和合理性。打个不恰当的比方，你说hello，对方回应你好，大家都明白。但是问一个暴白或者暴黑“全世界最“牛逼”的游戏公司”，他回答动视暴雪，这里面的逻辑关系不明白内情的人是搞不明白的，flash id也差不多是这个道理。像本人这种十年没写过代码的，装模作样写个scanf然后printf（qlcXXXX）做成和flash id一样的界面也是没啥大问题的，反正不管读哪个盘显示都是一样的主控一样的qlc，也许碰巧查询结果和flash id显示的一样，不过两者却有本质上的不同，这里的区别大家应该也能理解。当然这也确实非常尴尬，许多qlc换tlc的厂商天天跳，就是拿他们没法。
虽然这款软件并非是完美的，但也帮助了许多存储爱好者，本人对这款软件并无批判的意思，反而很感谢作者和爱好者们不断完善这款软件。
总体来说flash id做了两件事情：
1、通过deviceiocontrol与固态主控通信信息，将固态主控内部信息复制进内存以便操作。
2、通过主控信息自行判断部分固态信息（例如颗粒层数，tlc或qlc）并显示，此软件的原理和台风（内存颗粒识别软件）非常类似，均是通过现有数据自行逆推相关信息。
首先叠buff，逆向程序上纲上线的说是不合规且不道德的，本次逆向仅仅只是为了探究软件原理，因本人对主控硬件方面不熟悉，也不熟悉固件开发，无法验证作者判断颗粒的方式是否正确，只能从软件本身入手。而且本人已有10年没有正经写过代码或进行过逆向了，目前水平非常生疏，也归功于作者没有在软件防护上做太多文章，所以才能让本人顺利进行分析，尽管如此，限于水平问题，肯定也有很多不足之处，还望有经验的多指正。
本次以联芸maxio flash id为例，其他家颗粒识别原理应该是大同小异。
该程序应该为C/C++编写，未采取加壳等任何保护措施。首先查看程序的text锻，在text段落发现许多内置字符串变量，每个字符串都给出一个定义（define）
amicron
例如这个a26nm变量实际被定为成了26nm，代表制程，以此类推上面的amicron变量被定义成了micron，不再一一截图说明
甚至大家关心的颗粒类型TLC/MLC/SLC字样也是预先写在数据库的
软件获取硬盘信息的方法是通过deviceiocontrol函数与其进行通讯，在第二个参数中发送特定的控制码，获得主控返回的信息并复制进内存中，该部分信息在后续进行处理后显示。该控制码为16进制码而且是硬编码，并非微软在MSDN给出的那几个固定可选参数，因此猜测作者应该是通过某些手段得知了厂商主控开发手册或者也是通过逆向扒了厂商流出的开卡软件，得知了通信的机制，或者说利用了厂商的debug功能或者后门？曾经听主控厂的大佬谈起过，说固件本质上是一堆二进制，而且很多主控是ARM架构，可能确实不能直接兼容X86的参数，所以作者采用了硬编码，把对应的二进制变成了16进制代码发送过去（以上属于猜测，再次强调，本人没有任何主控和固件开发经验），主控收到了“暗号”就发回了信息，然后程序将信息复制进内存中并提取相关信息。
通过特定的iocontrolcode（硬编码2D1400h）与固态进行通信
计算后根据结果跳转至对应的程序段，显示对应的结果，例如结果为0x9b证明为ymtc，程序会跳转至相应的程序段并显示ymtc
也可以留意一下flash id的显示结果，在flash id前有一段十六进制代码，其中代码就包含了相关信息，程序通过和数据库匹配查询结果，例如0x9b代表ymtc。
在获得返回值后读取了进行一些数据操作，虽然本人能分析出相关算法，但是因为不了解主控及固件信息工作原理，无法判断该算法是否正确有效，感觉写出来意义也不大，最重要的事情是分析出flash id是通过一定数据处理后判断的。在处理之后，会根据返回值查找数据库匹配并显示出颗粒厂商、层数、nand string等等一系列信息，相关数据是从数据库提取出来的。
根据计算结果显示是镁光或海力士或三星
至于大家关心的tlc/qlc，flash id采用的应该是读取内存特定地址信息（也就是主控返回的信息）后根据其数字直接显示出来的（1代表slc，2代表2bit mlc，3代表tlc以此类推），表面上看是那回事，不过因为主控厂商没有公布其数据结构标准，依然无法证实其准确性。
在这里本人有个猜想，主控厂一般应该将颗粒类型编号等信息写进了固件中（例如1代表镁光，2代表海力士，a代表制程14nm，α代表slc，β代表2bit mlc等等这类）并按照一定结构进行存储，这点在流出的开卡工具中有所体现，那么flash id也可以通过读取相应的编号逆推出颗粒类型，这应该就是flash id的工作原理，当然前提是得知主控厂的数据存储方式。
在进行判断后在程序中显示出相应的判断信息
综上，程序将很多的字符串内置进程序本身（虽然非常原始，但是小容量数据直接写进程序本身对console application来说确实不算啥）充当数据库，通过判断读取的信息去一一调取对应字符串，需要强调的是程序是通过判断主控内部信息进行一定计算操作后，根据其结果调用相应的字符串，而非直接读取主控固件原生信息或者smart信息来显示厂商和颗粒类型。
所有的厂商、颗粒层数、制程信息均为程序内置数据库中调取，如果程序未更新，数据库版本落后，可能导致无法正确识别信息的情况（如果用老版本flash id去识别232l ymtc就无法识别，因为数据库中根本没有232l这个字符串所以显示不出来）。而且正因为不是直接根据主控原始信息显示，在无法保证作者的计算判断公式永远是正确的前提下，假如厂商的新主控更改了数据存储结构或方式（当然jedec有没有强制规定主控固件的数据结构本人不清楚，如果没有那理论上主控厂是可以随便改的），很可能造成错误识别或无法识别。
同时，通信是个技术活，因为作者发送的消息是硬编码，固态本质上也是一个小计算机，对固态进行操作，也会存在各种各样的风险，要么就是新款主控的通信方式不同，不吃flash id那一套，你发的是啥？暗号？我不懂，滚吧！主控就不会返回任何信息，导致啥都查不出来，第一步就进行不下去了（例如SM2320，用慧荣flash id无法查询颗粒信息就是在主控第一步通信时就死了）。要么虽然能识别，但固件上有些不同，导致在通信的时候主控不能按照作者的意图正常解析（也有可能是作者硬编码的原因，毕竟硬编码这个东东弊端还是有的，但考虑到flash id的特殊性好像也没有什么好办法），然后出错导致固态死机了，也就是掉盘，flash id读盘掉盘的事情时有发生应该是这个原因。
最后想强调的是，正因为软件是通过判断主控内部信息进行一定计算操作后，根据其结果查询数据库显示的结果，并非直接读取SMART或者主控发回信息明文显示了相关nand内容，在相关算法和对应关系无法明确确定的前提下，用flash id结果作为查询颗粒的确定证据是非常不合适的，因为没法证明程序的原理和合理性。打个不恰当的比方，你说hello，对方回应你好，大家都明白。但是问一个暴白或者暴黑“全世界最“牛逼”的游戏公司”，他回答动视暴雪，这里面的逻辑关系不明白内情的人是搞不明白的，flash id也差不多是这个道理。像本人这种十年没写过代码的，装模作样写个scanf然后printf（qlcXXXX）做成和flash id一样的界面也是没啥大问题的，反正不管读哪个盘显示都是一样的主控一样的qlc，也许碰巧查询结果和flash id显示的一样，不过两者却有本质上的不同，这里的区别大家应该也能理解。当然这也确实非常尴尬，许多qlc换tlc的厂商天天跳，就是拿他们没法。
虽然这款软件并非是完美的，但也帮助了许多存储爱好者，本人对这款软件并无批判的意思，反而很感谢作者和爱好者们不断完善这款软件。
12铢
