add command

function.md

@@ -1,34 +1,28 @@
-装填数据，发到jobqueue是他们的目地，我感觉重点是在这里
-sub_1032003B0 -> sub_1024803E4 -> sub_1024C6354 可能是统一入口
-sub_10237997C image_handler.cc
-sub_1023E73E8 text_handler.cc ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSERKS5_
-sub_102363BB0 file_handler.cc 
-sub_100400950 装填消息
-每次都是这个175ED5D10指针装填数据
-
-sub_10250D878 是整体的发消息入口有多个阶段来自这里
-StartSendMessageSerial sub_1024C4CB4
-CoSendMessageWithUploadInfo sub_1023E8108
-CoAddSendMessageToDb  sub_1023C09D0
-CoPrepareShowSendMessage  sub_1023BC4E0
+text_message_handler_10227A9C4 text_message_handler.cc ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSERKS5_
+sub_1033EF820 Req2BufImpl
+研究sub_104527E84 这个函数 /Users/bkdevops/.wconan2/mmnet/dce0e807_1764759442/mars-private/mars/protobuf/google/protobuf/wire_format_lite.cc
+protoWriteAllValue_10344FFEC 写protobuf的函数
+compress_103413610 compress函数进行压缩
 
 
 
-键盘事件触发
-sub_10064DD2C 里面有铭文的数据，看看怎么把这个数据传输到下层，估计是
-sub_100662CC4 处理消息的关键函数
-sub_100662CC4 -> sub_100668580 -> sub_10064DD2C
-sub_100662CC4 -> sub_10063F318 -> sub_1006DDDBC 处理发送消息结构体
-sub_1006DDDBC 消息体在这个函数 X1的第一个指针式utf16的发送值，X0不知道是啥,并且X1都是一个地址，追查一下地址 16FDFD688
-
-100179130 可以增加字段 和 sub_105A25B30 获取值的函数
-16FDFD6F0 指针
+```
+mar发送的格式
+task start long  
+short taskid:1067
+cmdid:522
+need_authed:true
+cgi:/cgi-bin/micromsg-bin/newsendmsg
+channel_select:3
+limit_flow:true
+channel_name:default-longlink
 
 
-真正的发送阶段
-sub_1024C7FB4 -> sub_102481CA0 -> sub_105268848
-sub_1024C7FB4 sendMessage 入口
-
-
-sub_1023BB1F0->sub_1023990EC->realSendMsg_10239B4C4 发消息的真正函数
-又调用了sendMsgCoroutine_105261924 进行一步操作但是这个好像是只有发消息才会走的核心coroutine
+taskid:1134, 
+cmdid:522, 
+need_authed:true, 
+cgi:/cgi-bin/micromsg-bin/newsendmsg, 
+channel_select:3, 
+limit_flow:true, 
+channel_name:default-longlink
+```

idapro/analysis_x.py

@@ -193,4 +193,4 @@ analyze_all_args()
 example_usage()
 """
 
-print_register_struct("X0", 128, 4)
+print_register_struct("X2", 128, 4)

idapro/cmp_true.py

@@ -0,0 +1,3 @@
+20 0D 00 54 B.EQ
+21 0D 00 54 B.NE
+