`
RednaxelaFX
  • 浏览: 3067659 次
  • 性别: Icon_minigender_1
  • 来自: 海外
社区版块
存档分类
最新评论

[脚本分析] Quartett!的二进制脚本分析

阅读更多
我前两天在NetOA方面确实是有点懈怠了。不为别的,正是为了这篇将提到的脚本的分析。虽然没把分析做彻底,不过我觉得现在已经足够使用,顺便拿出来说说。

上个周末,汉公突然跟我提起FFDSystem的话题,然后有人联系我做Quartett!的汉化。自从跟汉公和明大合作参与汉化以来,我基本上就是做脚本处理的相关工作比较多;汉公解决破解的棘手问题,而明大主要完成打包问题,也兼做脚本编辑器,视具体分工而定。这次也不例外,汉公主攻了资源文件的破解和资源抽取,资源的打包还没做,脚本这块就暂时交给了我。一般,如果脚本是没经过处理的文本,那也就没我什么事了;这次遇到的果然还是经过处理了的二进制脚本。

一拿到已经从Script.dat中提取出来的脚本文件,我吓了一跳:文件名居然都是MD5……汉公那边果然还没把资源破解完善。不过没关系,只要文件内容是对的就能开工。可以确认的是,脚本(准确说是给到我手上的脚本)的后缀名是tkn。

打开其中的第一个文件,0a69b4afebd6d64527a21e3f1aa993f9.tkn。内容如下:
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00000000   54 4F 4B 45 4E 53 45 54  64 00 00 00 76 08 00 00   TOKENSETd...v...
00000010   0C 00 00 00 85 23 00 0C  00 00 00 81 62 61 73 65   ....?.....|ase
00000020   5F 70 61 74 68 00 0C 00  00 00 83 2E 2E 2F 00 16   _path.....?./..
00000030   00 00 00 85 23 00 16 00  00 00 81 69 6E 63 6C 75   ...?.....(nclu
00000040   64 65 00 16 00 00 00 83  53 63 72 69 70 74 2F 42   de.....ゴcript/B
00000050   61 73 65 49 6E 73 74 72  75 63 74 69 6F 6E 2E 74   aseInstruction.t
00000060   78 74 00 20 00 00 00 81  6D 6F 74 69 6F 6E 00 20   xt. ...[otion. 
00000070   00 00 00 81 4D 61 69 6E  00 20 00 00 00 85 28 00   ...`ain. ...?.


读起来似乎很郁闷(?),其实看到有那么多ASCII字符我已经很开心了。可以辨认出最开头的TOKENSET(但此时还无法判断那个d是什么)、ase_path、nclude等等。进一步观察可以发现那些看似被剪掉了的字符都在,前面的base_path、include就是如此。编辑器里显示不出来只是因为大于0x7F的字节被解释成双字节字符编码(DBCS)中一个双字节字符的首字节,也就是例如说0x81把base_path中的b(0x62)给“吃”了。
在上述截图范围内,我总共识别出了这些:base_path、include、Script/BaseInstruction.txt、motion、Main等字串。观察它们前后的规律:这些字串总是以0结尾,是标准的C string;这些字串的前面总是有一个大于0x7F的字节(留意到0x81和0x83),而在那个字节之前似乎总是有3个00字节,前面又是一个非00的字节。
为了方便分析,我写了一个小程序来抽取出我感兴趣的信息,辅助分析。
对应上面内容而提出出来的内容:
(格式是:字符串起始地址 一个奇怪的数字 字符串之前的那个字节 字符串内容)
0x1C 0xC 0x81 base_path
0x2B 0xC 0x83 ../
0x3B 0x16 0x81 include
0x48 0x16 0x83 Script/BaseInstruction.txt
0x68 0x20 0x81 motion
0x74 0x20 0x81 Main

经观察,发现字符串之前的那个字节似乎是某种操作码或者类型,而再前面的那个似乎是个什么奇怪的数字,会连续有好几个相同的,然后又增大一点。

接下来,突然发觉原来0x85也是个重要的数值;也有以这个数值打头的字符串,但一般都是长度为一的符号,所以先前被忽略了。想了想,干脆把0x80开始到0x88开头的,其之前是三个00的东西全部都扫描一遍。于是在之前的程序上修改了一下判断条件,得到下面代码:
opcode_analysis.cs:
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;

namespace FFDSystemAnalysis
{
    sealed class Analyzer
    {
        private static readonly byte[ ] SIGNATURE = {
		    ( byte )0x54, ( byte )0x4F, ( byte )0x4B, ( byte )0x45,
		    ( byte )0x4E, ( byte )0x53, ( byte )0x45, ( byte )0x54,
		    ( byte )0x64, ( byte )0x0,  ( byte )0x0,  ( byte )0x0
        };

        static void Main( string[ ] args ) {
            if ( !args[ 0 ].EndsWith( ".tkn" ) ) return;
            if ( !File.Exists( args[ 0 ] ) ) return;

            string infile = args[ 0 ];
            string outfile = infile + ".txt";

            Encoding utf16le = new UnicodeEncoding( false, true );
            Encoding jis = Encoding.GetEncoding( 932 );

            using ( BinaryReader reader = new BinaryReader( File.OpenRead( infile ), jis ) ) {
                using ( BinaryWriter writer = new BinaryWriter( File.Create( outfile ), utf16le ) ) {
                    byte[ ] sig = reader.ReadBytes( SIGNATURE.Length );
                    if ( !Equals( sig, SIGNATURE ) ) {
                        Console.WriteLine( "Wrong signature" );
                        return;
                    }

                    // write UTF-16LE BOM
                    writer.Write( ( ushort ) 0xFEFF );

                    Queue<byte> queue = new Queue<byte>( 3 );
                    queue.Enqueue( reader.ReadByte( ) );
                    queue.Enqueue( reader.ReadByte( ) );
                    queue.Enqueue( reader.ReadByte( ) );

                    byte lastOpcode = 0;
                    while ( reader.BaseStream.Position < reader.BaseStream.Length ) {
                        byte currentByte = reader.ReadByte( );
                        if ( currentByte == 0x080
                            || currentByte == 0x081
                            || currentByte == 0x082
                            || currentByte == 0x083
                            || currentByte == 0x084
                            || currentByte == 0x085
                            || currentByte == 0x086
                            || currentByte == 0x087
                            || currentByte == 0x088 ) {
                            if ( MatchQueueData( queue ) ) {
                                long position = reader.BaseStream.Position;
                                string line = ReadCString( reader );
                                Entry e = new Entry( ) {
                                    position = position,
                                    opcode = currentByte,
                                    lastOpcode = lastOpcode,
                                    line = line
                                };
                                writer.Write(
                                    utf16le.GetBytes(
                                        string.Format( "{0}{1}",
                                            e.ToString( ),
                                            Environment.NewLine )
                                        )
                                    );
                            } // if
                        } // if

                        // re-initialize
                        lastOpcode = queue.Dequeue( );
                        queue.Enqueue( currentByte );
                    } // while
                } // using
            } // using
        } // Main

        static bool Equals( byte[ ] a, byte[ ] b ) {
            int len = a.Length;
            if ( len != b.Length ) return false;
            for ( int i = 0; i < len; i++ ) {
                if ( a[ i ] != b[ i ] ) return false;
            }
            return true;
        }

        static bool MatchQueueData( Queue<byte> queue ) {
            byte[ ] array = queue.ToArray( );
            return Equals( zeros, array );
        }

        static string ReadCString( BinaryReader reader ) {
            StringBuilder builder = new StringBuilder( );
            char c = '\0';

            while ( ( c = reader.ReadChar( ) ) != '\0' ) {
                builder.Append( c );
            }

            return builder.ToString( );
        }

        static readonly byte[ ] zeros
            = new byte[ ] { 0, 0, 0 };
    }

    struct Entry
    {
        public long position;
        public string line;
        public byte opcode;
        public byte lastOpcode;

        public override string ToString( ) {
            return string.Format( "0x{0:X} 0x{1:X} 0x{2:X} {3}",
                this.position, this.lastOpcode, this.opcode, this.line );
        }
    }
}

这段代码本身没什么稀奇,只有第57行到62行的内容有点诡异:居然把变量赋值给自己了?
不不,再怎么说我也不可能犯这种错误。这其实是C# 3.0里的一个有趣语法,initializer。可以通过initializer,在使用new关键字构造新实例的时候指定其中一些字段的值;等号左边的是字段名,右边则是字面量或者变量名(或者表达式)。编译器能够正确识别出看似是同名字的token之间的区别,因而能够正确赋值。好吧我承认这不是好的编程习惯,大家看到了千万不要学,要引以为戒……
另外,那个if里一大堆对currentByte的判断后来也重构到外面一个单独的MatchOpcode()方法里去了。像上面这样写实在太恶心……也要引以为戒哦

虽然没什么稀奇,还是说下这个文件里的流程:
1、检查作为参数文件是否存在,并且是否后缀为tkn。检查不通过则退出程序。
2、获取一个Shift-JIS和一个UTF-16LE字符集的Encoding实例,并使用它们创建Shift-JIS的输入流和UTF-16LE的输出流。
3、校验脚本文件的特征码(signature)。这里假设头12个字节都是特征码。
4、校验成功后,给输出流写出一个字节序标记(BOM,Byte Order Mark)。这本来应该不需要手工做的,但我一直没弄清楚为什么我明明在创建utf16le时指定要BOM系统却不帮我自动做……
5、创建一个队列来记录最近的三个字节。使用一个变量(lastOpcode)来记录最近的第四个字节。
6、扫描文件直到遇到文件结束。如果遇到了连续的3个00,则读入其后的一个字节,并判断是否在[0x80, 0x88]的范围内;满足的话则读入一个C string并输出记录。
7、程序结束。

于是我得到了更新版的记录:
(格式与前面相同)
0x15 0xC 0x85 #
0x1C 0xC 0x81 base_path
0x2B 0xC 0x83 ../
0x34 0x16 0x85 #
0x3B 0x16 0x81 include
0x48 0x16 0x83 Script/BaseInstruction.txt
0x68 0x20 0x81 motion
0x74 0x20 0x81 Main


于是我恍然大悟:那“奇怪的数字”居然是脚本源文件行号!而被认为是操作码或者类型的那个字节,则用于指定后面字符串的类型:可以是符号、十进制数字、十六进制数字、标识符、字符串、符号等。形象点看,如下图:
(红色的是行号,黄色的是类型,绿色的是字符串内容)


但位于脚本的0xC到0xF的那个数字(上图紫色部分)是什么意思还让我伤了下脑筋。观察了一下,发现从0a69b4afebd6d64527a21e3f1aa993f9.tkn提取出来的“东西”一共有1237个,而那意义不明的数字是0x876 = 2166,还差了不少。但总觉得它们应该有关系。突然想起我前面是用了个很糟糕的办法来提取记录,有连续的3个00字节才满足条件。但假如行号超过了0xFF = 255行的话这个条件就不成立了。赶紧把程序修改为第三版,按照新的理解去读入“行号”和“类型”两个数据,确认那个数字确实就是文件里总的token数。

然后我才理解了signature里那TOKENSET的含义……这看似是二进制的脚本其实根本没有编译过的二进制脚本之魂。
编译的前端至少有两部,scan和parse。Scan阶段处理词法分析,会把源文件切分成一个个token,而parse阶段处理文法分析,会根据上下文无关文法来尝试“理解”这些token,构造语法树(进而构造抽象语法树)。但这里我所看到的脚本只对脚本源文件做了scan,然后直接把scan的结果保存成“二进制脚本”了。真够OTL的。

简单点说,这个“二进制脚本”完整保留了脚本源文件的文本信息,而且还多加了些行号、类型等信息进去。缺少的是被去除了的注释。

那就很好办了不是么。于是把所谓的反编译程序写了出来:
ScriptDecompiler.cs
// ScriptDecompiler.cs, 2007/12/18
// by RednaxelaFX

/*
 * Copyright (c) 2007 着作权由RednaxelaFX所有。着作权人保留一切权利。
 * 
 * 这份授权条款,在使用者符合以下三条件的情形下,授予使用者使用及再散播本
 * 软件包装原始码及二进位可执行形式的权利,无论此包装是否经改作皆然:
 * 
 * * 对于本软件源代码的再散播,必须保留上述的版权宣告、此三条件表列,以
 *   及下述的免责声明。
 * * 对于本套件二进位可执行形式的再散播,必须连带以文件以及/或者其他附
 *   于散播包装中的媒介方式,重制上述之版权宣告、此三条件表列,以及下述
 *   的免责声明。
 * * 未获事前取得书面许可,不得使用RednaxelaFX之名称,
 *   来为本软件之衍生物做任何表示支持、认可或推广、促销之行为。
 * 
 * 免责声明:本软件是由RednaxelaFX以现状("as is")提供,
 * 本软件包装不负任何明示或默示之担保责任,包括但不限于就适售性以及特定目
 * 的的适用性为默示性担保。RednaxelaFX无论任何条件、
 * 无论成因或任何责任主义、无论此责任为因合约关系、无过失责任主义或因非违
 * 约之侵权(包括过失或其他原因等)而起,对于任何因使用本软件包装所产生的
 * 任何直接性、间接性、偶发性、特殊性、惩罚性或任何结果的损害(包括但不限
 * 于替代商品或劳务之购用、使用损失、资料损失、利益损失、业务中断等等),
 * 不负任何责任,即在该种使用已获事前告知可能会造成此类损害的情形下亦然。
 */

using System;
using System.Collections.Generic;
using System.IO;
using System.Text;

namespace FFDSystemAnalysis
{
    enum TokenType
    {
        Decimal = 0x080,
        Identifier = 0x081,
        Hexadecimal = 0x082,
        String = 0x083,
        Operator = 0x085
    }

    sealed class ScriptDecompiler
    {
        private static readonly byte[ ] SIGNATURE = {
		    ( byte )0x54, ( byte )0x4F, ( byte )0x4B, ( byte )0x45,
		    ( byte )0x4E, ( byte )0x53, ( byte )0x45, ( byte )0x54,
		    ( byte )0x64, ( byte )0x0,  ( byte )0x0,  ( byte )0x0
        };

        static void Main( string[ ] args ) {
            if ( !args[ 0 ].EndsWith( ".tkn" ) ) return;
            if ( !File.Exists( args[ 0 ] ) ) return;

            string infile = args[ 0 ];
            string outfile = Path.GetFileNameWithoutExtension( infile ) + ".txt";

            Encoding utf16le = new UnicodeEncoding( false, true );
            Encoding jis = Encoding.GetEncoding( 932 );

            using ( BinaryReader reader = new BinaryReader( File.OpenRead( infile ), jis ) ) {
                using ( BinaryWriter writer = new BinaryWriter( File.Create( outfile ), utf16le ) ) {
                    byte[ ] sig = reader.ReadBytes( SIGNATURE.Length );
                    if ( !Equals( sig, SIGNATURE ) ) {
                        Console.WriteLine( "Wrong signature" );
                        return;
                    }

                    // write UTF-16LE BOM
                    writer.Write( ( ushort ) 0xFEFF );

                    // process each token
                    int lineNum = 1;
                    int lastLineNum = 1;
                    TokenType tokenType = TokenType.Operator;
                    TokenType lastTokenType = TokenType.Operator;
                    int tabCount = 0;
                    int tokenCount = reader.ReadInt32( );
                    for ( int tokenNum = 0; tokenNum < tokenCount; ++tokenNum ) {
                        // deal with line numbers, insert empty new lines if needed
                        lineNum = reader.ReadInt32( );
                        if ( lastLineNum < lineNum ) { // should write on a newline
                            // write empty lines
                            for ( int i = lastLineNum; i < lineNum; ++i ) {
                                writer.Write( utf16le.GetBytes( Environment.NewLine ) );
                            }
                            // write tabs as indent
                            for ( int tabs = 0; tabs < tabCount; ++tabs ) {
                                writer.Write( utf16le.GetBytes( "\t" ) );
                            }
                            // put a dummy value into tokenType
                            lastTokenType = TokenType.Operator;
                        }

                        // get token tokenType
                        tokenType = ( TokenType ) ( reader.ReadByte( ) & 0x0FF );

                        // get token value
                        string tokenString = ReadCString( reader );

                        // deal with different token types
                        if ( !( lastTokenType == TokenType.Operator
                            || lastTokenType == TokenType.String
                            || lastTokenType == TokenType.Decimal
                            || lastTokenType == TokenType.Hexadecimal ) ) {
                            writer.Write( utf16le.GetBytes( " " ) );
                        }
                        switch ( tokenType ) {
                        case TokenType.Decimal:
                        case TokenType.Identifier:
                        case TokenType.Hexadecimal:
                            writer.Write( utf16le.GetBytes( tokenString ) );
                            break;

                        case TokenType.String:
                            writer.Write(
                                utf16le.GetBytes( string.Format( "\"{0}\"", tokenString ) ) );
                            break;

                        case TokenType.Operator:
                            switch ( tokenString ) {
                            case "#":
                            case "%":
                            case "-":
                            case "@":
                                writer.Write( utf16le.GetBytes( tokenString ) );
                                break;
                            case "{":
                                ++tabCount;
                                writer.Write( utf16le.GetBytes( tokenString ) );
                                break;
                            case "}":
                                --tabCount;
                                writer.BaseStream.Position -= 2; // delete the last tab
                                writer.Write( utf16le.GetBytes( tokenString ) );
                                break;
                            case "(":
                            case ",":
                            case ";":
                            case "=":
                                writer.Write(
                                    utf16le.GetBytes( string.Format( "{0} ", tokenString ) ) );
                                break;
                            case ")":
                                writer.Write(
                                    utf16le.GetBytes( string.Format( " {0}", tokenString ) ) );
                                break;
                            } // switch tokenString
                            break;

                        default:
                            Console.WriteLine( "Unexpected token type {0} at 0x{1}.",
                                tokenType.ToString( "X" ),
                                reader.BaseStream.Position.ToString( "X" ) );
                            return;
                        } // switch tokenType

                        // re-initialize
                        lastLineNum = lineNum;
                        lastTokenType = tokenType;
                    } // for
                }
            }
        }

        static bool Equals( byte[ ] a, byte[ ] b ) {
            int len = a.Length;
            if ( len != b.Length ) return false;
            for ( int i = 0; i < len; i++ ) {
                if ( a[ i ] != b[ i ] ) return false;
            }
            return true;
        }

        static string ReadCString( BinaryReader reader ) {
            StringBuilder builder = new StringBuilder( );
            char c = '\0';

            while ( ( c = reader.ReadChar( ) ) != '\0' ) {
                builder.Append( c );
            }

            return builder.ToString( );
        }
    }
}

中间有些代码是为了插入缩进的,忽略那部分吧……

得到的脚本看起来像是这样:










#base_path "../"









#include "Script/BaseInstruction.txt"









motion Main (  )


中间是有很多空行没错。那些原本应该是有注释的地方,或者本身就是空行(为了让代码好看)。这里我只是把原始脚本的状态尽量复原了出来而已。

==========================================================

暂时来说,这样就够用了。这个脚本处理已经让我们能做很多事。要进一步做的话,我可以把文法分析也做出来,方便对脚本更仔细的分析。但这两天肯定是没时间做那种事情咯……

Until then...

==========================================================

P.S. 上述代码皆以BSD许可证的形式发布。请有兴趣的人在遵循BSD许可证的前提下自由使用这些代码。

P.S.S. 其实上面代码值得吐槽的地方N多。例如说我完全没使用try-catch语句来处理可能出现的异常,又例如我在第一份代码里把一个Queue转变成数组再做相等性比较(极其恶心,本来自己写个循环数组就解决了)。……这些都是所谓的“原型代码”,目标是尽可能快的写出代码来验证自己的一些设想是否正确。偷懒不加异常处理、宁可别扭的使用标准库里的容器也不自己封装一个,都是出于同一原因。看倌们请多多包涵这些地方 XD

P.S.S.S. 唉,不过我偷懒也真是过分了。后一份代码里居然没把BinaryWriter改回用StreamWriter……
分享到:
评论
3 楼 lwwin 2007-12-23  
偶的意思是说,这些 天分 是有爱………………
2 楼 RednaxelaFX 2007-12-21  
跟天分大概没什么关系,不过经验肯定是有关的 ^ ^
1 楼 lwwin 2007-12-20  
经验啊经验,破解的东西果然还是靠天分的罢?

相关推荐

    Quartett!文本插入程序

    "Quartett!文本插入程序"是一个用于在特定文件中插入文本的工具,它主要处理tkn格式的文件。这个程序可能对程序员或系统管理员非常有用,因为它允许他们自动化一些文本处理任务,例如批量添加注释、修改配置文件或者...

    quartett-app

    "quartett-app" 是一个基于Java开发的项目,它是一个响应式的网页游戏,灵感来源于经典的超级Trumpf游戏。这个游戏的特色在于它结合了蒂罗尔地区城市的文化元素,为玩家提供了一种新颖且富有地方特色的卡牌游戏体验...

    毕业设计选题 -未来生鲜运输车设计.pptx

    毕业设计选题 -未来生鲜运输车设计.pptx

    基于樽海鞘算法优化的极限学习机回归预测及其与BP、GRNN、ELM的性能对比研究

    内容概要:本文详细探讨了基于樽海鞘算法(SSA)优化的极限学习机(ELM)在回归预测任务中的应用,并与传统的BP神经网络、广义回归神经网络(GRNN)以及未优化的ELM进行了性能对比。首先介绍了ELM的基本原理,即通过随机生成输入层与隐藏层之间的连接权重及阈值,仅需计算输出权重即可快速完成训练。接着阐述了SSA的工作机制,利用樽海鞘群体觅食行为优化ELM的输入权重和隐藏层阈值,从而提高模型性能。随后分别给出了BP、GRNN、ELM和SSA-ELM的具体实现代码,并通过波士顿房价数据集和其他工业数据集验证了各模型的表现。结果显示,SSA-ELM在预测精度方面显著优于其他三种方法,尽管其训练时间较长,但在实际应用中仍具有明显优势。 适合人群:对机器学习尤其是回归预测感兴趣的科研人员和技术开发者,特别是那些希望深入了解ELM及其优化方法的人。 使用场景及目标:适用于需要高效、高精度回归预测的应用场景,如金融建模、工业数据分析等。主要目标是提供一种更为有效的回归预测解决方案,尤其是在处理大规模数据集时能够保持较高的预测精度。 其他说明:文中提供了详细的代码示例和性能对比图表,帮助读者更好地理解和复现实验结果。同时提醒使用者注意SSA参数的选择对模型性能的影响,建议进行参数敏感性分析以获得最佳效果。

    2025年中国生成式AI大会PPT(4-1)

    2025年中国生成式AI大会PPT(4-1)

    无刷直流电机双闭环调速系统的Simulink建模与参数优化

    内容概要:本文详细介绍了基于Simulink平台构建无刷直流电机(BLDC)双闭环调速系统的全过程。首先阐述了双闭环控制系统的基本架构,即外层速度环和内层电流环的工作原理及其相互关系。接着深入探讨了PWM生成模块的设计,特别是占空比计算方法的选择以及三角波频率的设定。文中还提供了详细的电机参数设置指导,如转动惯量、电感、电阻等,并强调了参数选择对系统性能的影响。此外,针对PI控制器的参数整定给出了具体的公式和经验值,同时分享了一些实用的调试技巧,如避免转速超调、处理启动抖动等问题的方法。最后,通过仿真实验展示了系统的稳定性和鲁棒性,验证了所提出方法的有效性。 适用人群:从事电机控制研究的技术人员、自动化工程领域的研究生及科研工作者。 使用场景及目标:适用于需要深入了解和掌握无刷直流电机双闭环调速系统设计与优化的人群。主要目标是帮助读者学会利用Simulink进行BLDC电机控制系统的建模、仿真和参数优化,从而提高系统的稳定性和响应速度。 其他说明:文章不仅提供了理论知识,还包括了许多实践经验和技术细节,有助于读者更好地理解和应用相关技术。

    西门子S7-1200 PLC与施耐德变频器Modbus通讯实现及调试技巧

    内容概要:本文详细介绍了西门子S7-1200 PLC与施耐德ATV310/312变频器通过Modbus RTU进行通讯的具体实现步骤和调试技巧。主要内容涵盖硬件接线、通讯参数配置、控制启停、设定频率、读取运行参数的方法以及常见的调试问题及其解决方案。文中提供了具体的代码示例,帮助读者理解和实施通讯程序。此外,还强调了注意事项,如地址偏移量、数据格式转换和超时匹配等。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是那些需要将西门子PLC与施耐德变频器进行集成的工作人员。 使用场景及目标:适用于需要通过Modbus RTU协议实现PLC与变频器通讯的工程项目。目标是确保通讯稳定可靠,掌握解决常见问题的方法,提高调试效率。 其他说明:文中提到的实际案例和调试经验有助于读者避免常见错误,快速定位并解决问题。建议读者在实践中结合提供的代码示例和调试工具进行操作。

    基于FPGA的Verilog实现IIC主从机驱动及其应用

    内容概要:本文详细介绍了如何使用Verilog在FPGA上实现IIC(Inter-Integrated Circuit)主从机驱动。主要内容包括从机和主机的设计,特别是状态机的实现、寄存器读取、时钟分频策略、SDA线的三态控制等关键技术。文中还提供了详细的代码片段,展示了从机地址匹配逻辑、主机时钟生成逻辑、顶层模块的连接方法以及仿真实验的具体步骤。此外,文章讨论了一些常见的调试问题,如总线竞争、时序不匹配等,并给出了相应的解决方案。 适合人群:具备一定FPGA开发基础的技术人员,尤其是对IIC协议感兴趣的嵌入式系统开发者。 使用场景及目标:适用于需要在FPGA平台上实现高效、可靠的IIC通信的应用场景。主要目标是帮助读者掌握IIC协议的工作原理,能够独立完成IIC主从机系统的开发和调试。 其他说明:文章不仅提供了理论讲解,还包括了大量的实战经验和代码实例,有助于读者更好地理解和应用所学知识。同时,文章还提供了一个思考题,引导读者进一步探索多主设备仲裁机制的设计思路。

    C#开发的拖拽式Halcon可视化抓边抓圆控件,提升机器视觉测量效率

    内容概要:本文介绍了一款基于C#开发的拖拽式Halcon可视化抓边、抓圆控件,旨在简化机器视觉项目中的测量任务。该控件通过拖拽操作即可快速生成测量区域,自动完成边缘坐标提取,并提供实时反馈。文中详细描述了控件的工作原理和技术细节,如坐标系转换、卡尺生成、边缘检测算法封装以及动态参数调试等功能。此外,还讨论了一些常见问题及其解决方案,如坐标系差异、内存管理等。 适合人群:从事机器视觉开发的技术人员,尤其是熟悉C#和Halcon的开发者。 使用场景及目标:适用于需要频繁进行边缘和圆形特征测量的工业自动化项目,能够显著提高测量效率并减少编码工作量。主要目标是将复杂的测量任务转化为简单的拖拽操作,使非专业人员也能轻松完成测量配置。 其他说明:该控件已开源发布在GitHub上,提供了完整的源代码和详细的使用指南。未来计划扩展更多高级功能,如自动路径规划和亚像素级齿轮齿距检测等。

    西门子200Smart与维纶触摸屏在疫苗车间控制系统的应用:配液、发酵、纯化及CIP清洗工艺详解

    内容概要:本文详细介绍了西门子200Smart PLC与维纶触摸屏在某疫苗车间控制系统的具体应用,涵盖配液、发酵、纯化及CIP清洗四个主要工艺环节。文中不仅展示了具体的编程代码和技术细节,还分享了许多实战经验和调试技巧。例如,在配液罐中,通过模拟量处理确保温度和液位的精确控制;发酵罐部分,着重讨论了PID参数整定和USS通讯控制变频器的方法;纯化过程中,强调了双PID串级控制的应用;CIP清洗环节,则涉及复杂的定时器逻辑和阀门联锁机制。此外,文章还提到了一些常见的陷阱及其解决方案,如通讯干扰、状态机切换等问题。 适合人群:具有一定PLC编程基础的技术人员,尤其是从事工业自动化领域的工程师。 使用场景及目标:适用于需要深入了解PLC与触摸屏集成控制系统的工程师,帮助他们在实际项目中更好地理解和应用相关技术和方法,提高系统的稳定性和可靠性。 其他说明:文章提供了大量实战经验和代码片段,有助于读者快速掌握关键技术点,并避免常见错误。同时,文中提到的一些优化措施和调试技巧对提升系统性能非常有帮助。

    计算机网络结课设计:通过思科Cisco进行中小型校园网搭建

    计算机网络课程的结课设计是使用思科模拟器搭建一个中小型校园网,当时花了几天时间查阅相关博客总算是做出来了,现在免费上传CSDN,希望小伙伴们能给博客一套三连支持

    芋道(yudao)开发技术文档

    《芋道开发指南文档-2023-10-27更新》是针对软件开发者和IT专业人士的一份详尽的资源集合,旨在提供最新的开发实践、范例代码和最佳策略。这份2023年10月27日更新的文档集,包含了丰富的模板和素材,帮助开发者在日常工作中提高效率,保证项目的顺利进行。 让我们深入探讨这份文档的可能内容。"芋道"可能是一个开源项目或一个专业的技术社区,其开发指南涵盖了多个方面,例如: 1. **编程语言指南**:可能包括Java、Python、JavaScript、C++等主流语言的编码规范、最佳实践以及常见问题的解决方案。 2. **框架与库的应用**:可能会讲解React、Vue、Angular等前端框架,以及Django、Spring Boot等后端框架的使用技巧和常见应用场景。 3. **数据库管理**:涵盖了SQL语言的基本操作,数据库设计原则,以及如何高效使用MySQL、PostgreSQL、MongoDB等数据库系统。 4. **版本控制**:详细介绍了Git的工作流程,分支管理策略,以及与其他开发工具(如Visual Studio Code、IntelliJ IDEA)的集成。 5. **持续集成与持续部署(CI/CD)**:包括Jenkins、Travis CI、GitHub Actions等工具的配置和使用,以实现自动化测试和部署。 6. **云服务与容器化**:可能涉及AWS、Azure、Google Cloud Platform等云计算平台的使用,以及Docker和Kubernetes的容器化部署实践。 7. **API设计与测试**:讲解RESTful API的设计原则,Swagger的使用,以及Postman等工具进行API测试的方法。 8. **安全性与隐私保护**:涵盖OAuth、JWT认证机制,HTTPS安全通信,以及防止SQL注入、

    基于信息间隙决策的综合能源系统优化调度模型及其应用

    内容概要:本文介绍了一种先进的综合能源系统优化调度模型,该模型将风电、光伏、光热发电等新能源与燃气轮机、燃气锅炉等传统能源设备相结合,利用信息间隙决策(IGDT)处理不确定性。模型中引入了P2G(电转气)装置和碳捕集技术,实现了碳经济闭环。通过多能转换和储能系统的协同调度,提高了系统的灵活性和鲁棒性。文中详细介绍了模型的关键组件和技术实现,包括IGDT的鲁棒性参数设置、P2G与碳捕集的协同控制、储能系统的三维协同调度等。此外,模型展示了在极端天气和负荷波动下的优异表现,显著降低了碳排放成本并提高了能源利用效率。 适合人群:从事能源系统优化、电力调度、碳交易等相关领域的研究人员和工程师。 使用场景及目标:适用于需要处理多种能源形式和不确定性的综合能源系统调度场景。主要目标是提高系统的灵活性、鲁棒性和经济效益,减少碳排放。 其他说明:模型具有良好的扩展性,可以通过修改配置文件轻松集成新的能源设备。代码中包含了详细的注释和公式推导,便于理解和进一步改进。

    毕业设计的论文撰写、终期答辩相关的资源.m

    毕业设计的论文撰写、终期答辩相关的资源

    机器学习(预测模型):专注于 2024 年出现的漏洞(CVE)信息数据集

    该是一个在 Kaggle 上发布的数据集,专注于 2024 年出现的漏洞(CVE)信息。以下是关于该数据集的详细介绍:该数据集收集了 2024 年记录在案的各类漏洞信息,涵盖了漏洞的利用方式(Exploits)、通用漏洞评分系统(CVSS)评分以及受影响的操作系统(OS)。通过整合这些信息,研究人员和安全专家可以全面了解每个漏洞的潜在威胁、影响范围以及可能的攻击途径。数据主要来源于权威的漏洞信息平台,如美国国家漏洞数据库(NVD)等。这些数据经过整理和筛选后被纳入数据集,确保了信息的准确性和可靠性。数据集特点:全面性:涵盖了多种操作系统(如 Windows、Linux、Android 等)的漏洞信息,反映了不同平台的安全状况。实用性:CVSS 评分提供了漏洞严重程度的量化指标,帮助用户快速评估漏洞的优先级。同时,漏洞利用信息(Exploits)为安全研究人员提供了攻击者可能的攻击手段,有助于提前制定防御策略。时效性:专注于 2024 年的漏洞数据,反映了当前网络安全领域面临的新挑战和新趋势。该数据集可用于多种研究和实践场景: 安全研究:研究人员可以利用该数据集分析漏洞的分布规律、攻击趋势以及不同操作系统之间的安全差异,为网络安全防护提供理论支持。 机器学习与数据分析:数据集中的结构化信息适合用于机器学习模型的训练,例如预测漏洞的 CVSS 评分、识别潜在的高危漏洞等。 企业安全评估:企业安全团队可以参考该数据集中的漏洞信息,结合自身系统的实际情况,进行安全评估和漏洞修复计划的制定。

    建模大赛入门指南:从零基础到实战应用.pdf

    内容概要:本文档作为建模大赛的入门指南,详细介绍了建模大赛的概念、类型、竞赛流程、核心步骤与技巧,并提供实战案例解析。文档首先概述了建模大赛,指出其以数学、计算机技术为核心,主要分为数学建模、3D建模和AI大模型竞赛三类。接着深入解析了数学建模竞赛,涵盖组队策略(如三人分别负责建模、编程、论文写作)、时间安排(72小时内完成全流程)以及问题分析、模型建立、编程实现和论文撰写的要点。文中还提供了物流路径优化的实战案例,展示了如何将实际问题转化为图论问题并采用Dijkstra或蚁群算法求解。最后,文档推荐了不同类型建模的学习资源与工具,并给出了新手避坑建议,如避免过度复杂化模型、重视可视化呈现等。; 适合人群:对建模大赛感兴趣的初学者,特别是高校学生及希望参与数学建模竞赛的新手。; 使用场景及目标:①了解建模大赛的基本概念和分类;②掌握数学建模竞赛的具体流程与分工;③学习如何将实际问题转化为数学模型并求解;④获取实战经验和常见错误规避方法。; 其他说明:文档不仅提供了理论知识,还结合具体实例和代码片段帮助读者更好地理解和实践建模过程。建议新手从中小型赛事开始积累经验,逐步提升技能水平。

    protobuf-6.30.1-cp310-abi3-win32.whl

    该资源为protobuf-6.30.1-cp310-abi3-win32.whl,欢迎下载使用哦!

    大数据环境构建:从虚拟机创建到Ambari集群部署的技术指南

    内容概要:本文档详细介绍了基于Linux系统的大数据环境搭建流程,涵盖从虚拟机创建到集群建立的全过程。首先,通过一系列步骤创建并配置虚拟机,包括设置IP地址、安装MySQL数据库等操作。接着,重点讲解了Ambari的安装与配置,涉及关闭防火墙、设置免密登录、安装时间同步服务(ntp)、HTTP服务以及配置YUM源等关键环节。最后,完成了Ambari数据库的创建、JDK的安装、Ambari server和agent的部署,并指导用户创建集群。整个过程中还提供了针对可能出现的问题及其解决方案,确保各组件顺利安装与配置。 适合人群:具有Linux基础操作技能的数据工程师或运维人员,尤其是那些需要构建和管理大数据平台的专业人士。 使用场景及目标:适用于希望快速搭建稳定可靠的大数据平台的企业或个人开发者。通过本指南可以掌握如何利用Ambari工具自动化部署Hadoop生态系统中的各个组件,从而提高工作效率,降低维护成本。 其他说明:文档中包含了大量具体的命令行指令和配置细节,建议读者按照顺序逐步操作,并注意记录下重要的参数值以便后续参考。此外,在遇到问题时可参照提供的解决方案进行排查,必要时查阅官方文档获取更多信息。

    MATLAB中基于LMS算法的一维时间序列信号降噪技术及其实现

    内容概要:本文详细介绍了如何在MATLAB R2018A中使用最小均方(LMS)自适应滤波算法对一维时间序列信号进行降噪处理,特别是针对心电图(ECG)信号的应用。首先,通过生成模拟的ECG信号并加入随机噪声,创建了一个带有噪声的时间序列。然后,实现了LMS算法的核心部分,包括滤波器阶数、步长参数的选择以及权重更新规则的设计。文中还提供了详细的代码示例,展示了如何构建和训练自适应滤波器,并通过图形化方式比较了原始信号、加噪信号与经过LMS处理后的降噪信号之间的差异。此外,作者分享了一些实用的经验和技术要点,如参数选择的影响、误差曲线的解读等。 适用人群:适用于具有一定MATLAB编程基础并对信号处理感兴趣的科研人员、工程师或学生。 使用场景及目标:本教程旨在帮助读者掌握LMS算法的基本原理及其在实际项目中的应用方法,特别是在生物医学工程、机械故障诊断等领域中处理含噪信号的任务。同时,也为进一步探索其他类型的自适应滤波技术和扩展到不同的信号处理任务奠定了基础。 其他说明:尽管LMS算法在处理平稳噪声方面表现出色,但在面对突发性的强干扰时仍存在一定局限性。因此,在某些特殊场合下,可能需要与其他滤波技术相结合以获得更好的效果。

    基于TMS320F2812的光伏并网逆变器设计与MATLAB仿真及DSP代码实现

    内容概要:本文详细介绍了基于TMS320F2812 DSP芯片的光伏并网逆变器设计方案,涵盖了主电路架构、控制算法、锁相环实现、环流抑制等多个关键技术点。首先,文中阐述了双级式结构的主电路设计,前级Boost升压将光伏板输出电压提升至约600V,后级采用三电平NPC拓扑的IGBT桥进行逆变。接着,深入探讨了核心控制算法,如电流PI调节器、锁相环(SOFGI)、环流抑制等,并提供了详细的MATLAB仿真模型和DSP代码实现。此外,还特别强调了PWM死区时间配置、ADC采样时序等问题的实际解决方案。最终,通过实验验证,该方案实现了THD小于3%,MPPT效率达98.7%,并有效降低了并联环流。 适合人群:从事光伏并网逆变器开发的电力电子工程师和技术研究人员。 使用场景及目标:适用于光伏并网逆变器的研发阶段,帮助工程师理解和实现高效稳定的逆变器控制系统,提高系统的性能指标,减少开发过程中常见的错误。 其他说明:文中提供的MATLAB仿真模型和DSP代码可以作为实际项目开发的重要参考资料,有助于缩短开发周期,提高成功率。

Global site tag (gtag.js) - Google Analytics