小编Fer*_*lez的帖子

我需要一个命令行工具来转储标准的Windows DLL版本信息,以便我可以通过bash脚本(Cygwin)处理它.

作为一名Java开发人员,我不太熟悉Microsoft开发工具(尽管我对Microsoft Visual Embedded C++ 4.0和Microsoft Visual Basic 6.0有一点经验).

适当的工具似乎是mt.exe,如SO所述.但是,我发现获得这个小应用程序的唯一机会是下载适用于Windows Server 2008和.NET Framework的Windows SDK的1.29 GB ISO .我无法相信这是唯一的方法.

我还在Internet上发现了一个名为PEView的小应用程序,但它显示的信息太多(在我的情况下无用)信息,它不是命令行应用程序.

捆绑在Cygwin中的标准objdump也可以转储有关DLL文件的一些信息,但我看不到转储DLL版本的选项.请注意,此工具(使用-p选项)转储的MajorImageVersion,MinorImageVersion和其他字段与自己的DLL版本无关.

关于该怎么做的任何替代方案？也许我错过了一些重要的objdump选项？mt.exe是我唯一的选择吗？如果是这种情况,是否可以将其与Windows SDK分开？

我们遇到了一个与在Advantech POS板上使用Via C3处理器在(相当旧的)FC3下运行的Java应用程序相关的问题.java应用程序有几个已编译的共享库,可通过JNI访问.

通过C3处理器应该是i686兼容.前段时间在使用相同处理器的MiniItx主板上安装Ubuntu 6.10之后,我发现之前的声明并非100%正确.由于缺少C3处理器中i686设置的一些特定和可选指令,Ubuntu内核在启动时挂起.在使用i686优化时,GCC编译器默认使用i686集的C3实现中缺少的这些指令.在这种情况下,解决方案是使用i386编译版本的Ubuntu发行版.

Java应用程序的基本问题是通过克隆另一台PC的HD映像来安装在HD上的FC3发行版,这次是Intel P4.之后,分发需要一些黑客才能让它运行,比如用i386编译的版本替换一些软件包(例如内核).

问题是,工作一段时间后系统完全挂起而没有任何痕迹.我担心一些i686代码会留在系统中的某个地方,并且可以随时随机执行(例如从暂停模式或类似的东西中恢复后).

我的问题是:

• 是否有任何工具或方法可以找出二进制文件(可执行文件或库)所需的特定体系结构扩展？file没有提供足够的信息.

通过标准DOM处理XML时,序列化后不保证属性顺序.最后,这就是我在使用标准java XML Transform API序列化输出时所实现的.

但是我确实需要保留订单.我想知道Java是否有任何可能性来保持通过DOM API处理的XML文件的原始属性顺序,或任何强制命令的方式(可能通过使用替代序列化API来设置此一种财产).在我的情况下,处理减少以改变具有一堆属性的相同元素的序列的一些属性(不是全部)的值,并且可以插入更多元素.

有没有"简单"的方法,还是我必须定义自己的XSLT转换样式表来指定输出并更改整个输入XML文件？

更新我必须感谢你的所有答案.答案似乎比我预期的更明显.我从未关注属性顺序,因为我之前从未需要它.

需要属性顺序的主要原因是生成的XML文件看起来不同.目标是一个包含数百个警报的配置文件(每个警报由一组属性定义).这个文件通常随着时间的推移几乎没有什么修改,但是保持它的顺序是很方便的,因为当我们需要修改它的东西时,它是手工编辑的.有时,一些项目需要对此文件进行轻微修改,例如将其中一个属性设置为客户特定代码.

我刚开发了一个小应用程序来合并原始文件(所有项目通用)和每个项目的特定部分(修改某些属性的值),因此特定于项目的文件获取基础文件的更新(新警报定义或某些属性)价值错误修正).我需要有序属性的主要动机是能够通过文本比较工具(例如Winmerge)检查应用程序的输出.如果格式(主要是属性顺序)保持不变,则可以很容易地发现差异.

我真的认为这是可能的,因为XML处理程序(如XML Spy)允许您编辑XML文件并应用一些排序(网格模式).也许我唯一的选择是使用其中一个程序来手动修改输出文件.

我认为这个问题对于shell脚本怪物来说相当容易.

我正在寻找通过bash shell脚本创建Unix共享库的符号链接的最优雅和最短的方法.

我需要的是从一个共享库文件列表开始,如"libmythings.so.1.1,libotherthings.so.5.11",获取创建的符号链接,如:

libmythings.so -> libmythings.so.1 -> libmythings.so.1.1
libotherthings.so -> libotherthings.so.5 -> libotherthings.so.5.11

库文件位于包含其他文件(如其他shell脚本)的目录中.

编辑:嗯,"ldconfig -nN." 可以正常工作,但是我还需要在".so"后面没有附加主要编号的链接,至少有一个库,因为一个或多个库是来自Java的JNI调用的入口点,所以当一个库通过System.loadlibrary("libraryname")实例化它需要一个名为"libraryname.so"的库,而不是"libraryname.so.X".

如果有一个Java部件的解决方法,只有ldconfig -nN的解决方案可以工作.

嗨我有一些关于在Android,Blackberry和J2ME上实现加密存储(加密文件系统类型)的问题(请阅读Doubts部分).密码学硕士,我需要你的建议.

我知道这个问题有点长,可能太冗长了,但是请尝试阅读它直到最后(我有很多相关的问题,我不能在几个帖子中将它们分开).如果您能就我的至少一个问题(怀疑部分)给我一些反馈,我将非常感激.

谢谢,

目的

我目前正在为多平台存储系统设计API,该系统将提供与以下支持的移动Java平台相同的接口和功能:

• J2ME.最低配置/配置文件CLDC 1.1/MIDP 2.0,支持一些必要的JSR(用于文件存储的JSR-75).
• Android.尚未确定最低平台版本,但很可能是API级别7.
• 黑莓.它将使用相同的J2ME基础源,但利用该平台的一些先进功能.尚未确定最低配置(可能为4.6,因为4.5上的RMS限制为64 KB).

基本上API会运行三种商店:

• 档案.这些将允许标准目录/文件操作(通过流,create,mkdir等读/写).
• 偏好.它是一个特殊的商店,处理通过键访问的属性(类似于普通的旧java属性文件,但支持一些改进,如不同的值数据类型,如Android平台上的SharedPreferences)
• 本地消息队列.该商店将提供基本的消息队列功能.

注意事项

受JSR-75启发,所有类型的商店都将通过符合RFC 1738惯例的URL以统一的方式访问,但具有自定义前缀(即"file://"表示文件,"prefs://"表示对于消息队列,首选项或"queue://").该地址将指的是每个移动平台实现将映射到物理存储对象的虚拟位置.只有文件才允许分层存储(文件夹)和访问外部存储卡(通过单元名称,与JSR-75相同,但不管底层平台如何都不会改变).其他类型只支持平面存储.

系统还应支持所有基本类型的安全版本.用户通过在URL上加"s"前缀来表示它(即"sfile://"而不是"file://").API 只需要一个PIN(仅引入一次)来访问任何类型的安全对象类型.

实施问题

为了实现明文和加密存储,我将使用底层平台上可用的功能:

• 档案.这些可在所有平台上使用(J2ME仅适用于JSR-75,但它对我们的需求是强制性的).除了解决问题之外,抽象文件到实际文件映射是直接的.
• RMS.在J2ME(和Blackberry)平台上可用的这种类型的存储对于Preferences和Message Queues来说很方便(虽然取决于性能或大小要求,这些可以通过普通文件实现).
• SharedPreferences.此类存储仅在Android上可用,将与首选项需求相匹配.
• SQLite数据库.这可以用于Android(也许是Blackberry)上的消息队列.

在加密方面,应满足一些要求:

• 为了简化实现,它将基于流(用于文件),RMS记录,SharedPreferences键值对,SQLite数据库列在读/写操作的基础上执行.每个底层存储对象都应使用相同的加密密钥.
• 加密商店的处理应与未加密的商店相同.访问加密存储的唯一区别(从用户的角度来看)是寻址.
• 用户PIN提供对任何安全存储对象的访问,但是更改它不需要解密/重新加密所有加密数据.
• 应尽可能使用底层平台的加密功能,因此我们将使用:
  • J2ME:SATSA-CRYPTO(如果可用)(非强制)或轻量级的BoncyCastle加密框架(适用于J2ME).
  • Blackberry:RIM Cryptographic API或BouncyCastle
  • Android:JCE与集成加密提供程序(BouncyCastle？)

我怀疑.求助于此

达到这一点后,考虑到平台的局限性,我对于哪种解决方案更方便感到震惊.这些是我的一些疑问:

• 数据加密算法.AES-128能够坚固且足够快吗？您会建议使用哪种替代方案？
• 加密模式.我已经读过ECB加密与CBC的弱点,但在这种情况下,第一个将具有随机访问块的优势,这对于文件的搜索功能很有意义.您会选择什么类型的加密模式？流加密适合这种情况吗？
• 密钥生成.可以为每个存储对象(文件,RMS RecordStore等)生成一个密钥,或者只为同一类型的所有对象使用一个密钥.第一个似乎"更安全",虽然它需要一些额外的设备空间.在您看来,每个人的权衡取舍是什么？
• 密钥存储.对于这种情况,使用标准JKS(或PKCS#12)KeyStore文件可能适合存储加密密钥,但我也可以定义一个较小的结构(加密转换/密钥数据/校验和),可以附加到每个存储库(即使用具有相同名称和特殊扩展名的附加文件用于普通文件或嵌入其他类型的对象(如RMS记录存储)中.你更喜欢什么方法？当使用具有多密钥生成的标准KeyStore时(假设这是您的偏好),使用每个存储对象的记录存储或仅保留所有密钥的全局KeyStore(即使用URL标识符)会更好吗？抽象存储对象作为别名)？
• 万能钥匙.使用主密钥似乎很明显.此密钥应受用户PIN(仅引入一次)的保护,并允许访问其余的加密密钥(它们将通过此主密钥加密).更改PIN只需要重新加密此密钥而不是所有加密数据.您会在哪里考虑到如果丢失了所有数据将无法进一步访问？我应该考虑哪些进一步的考虑因素？
• 平台加密支持 …

这个问题与另一个问题有关.我重新编译了Android框架并生成了一个新图像.我需要在原始框架中添加一些类,并通过添加进入/ system/framework的新jar来实现.我修改了BOOTCLASSPATH以考虑这些新罐子.

构建映像并闪烁到设备不起作用.必须在此之前运行一些优化,但我不知道该过程是如何进行的.

在生成映像之前我应该​​执行哪些构建步骤,或者我有什么其他替代方法,以便可以从应用程序访问扩展框架类？

我很难通过wsimport从WSDL生成WS.

WSDL是TMDD v3.0标准规范(可在此处找到WSDL和相关的XSD文件)

根据IBM的这篇文章, WSDL似乎是Document/literal格式.

为了获得编译的WSDL,我已经创建了一些绑定/调整但是我遇到了这个错误(它不会生成一个方法,因为操作有多个部分):

[WARNING] Ingoring operation "DlFullEventUpdateSubscription": more than one part
 bound to body
  line 17 of file:/O:/temp/wsdltest/TMDD-stripped.wsdl

为了简化,这是WSDL的精简版本,只有有趣的操作定义

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns:tns="http://www.tmdd.org/3/dialogs"
    xmlns:tmdd="http://www.tmdd.org/3/messages" xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:c2c="http://www.ntcip.org/c2c-message-administration" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    name="TMDDCenterServices" targetNamespace="http://www.tmdd.org/3/dialogs">
    <documentation>
    </documentation>
    <types>

        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
            <xs:import namespace="http://www.tmdd.org/3/messages"
                schemaLocation="TMDD.xsd" />
            <xs:import namespace="http://www.ntcip.org/c2c-message-administration"
                schemaLocation="C2C.xsd" />
        </xs:schema>
    </types>
    <message name="MSG_EventSubscription">
        <part name="c2cMsgAdmin" element="c2c:c2cMessageSubscription" />
        <part name="message" element="tmdd:eventRequestMsg" />
    </message>
    <!-- Common Messages -->
    <message name="MSG_ConfirmationReceipt">
        <!-- CONNECTION MANAGEMENT Messages -->
        <part name="message" element="c2c:c2cMessageReceipt" />
    </message> …

这个问题是我对在Java移动电话(J2ME,BlackBerry,Android)上实现小型加密文件系统的更广泛问题提出疑问的一部分.如果得到了收到的反馈意见,考虑到问题的密度,我决定将这些疑问分成小问题.

总而言之,我计划为移动电话"创建"加密文件系统(在BoucyCastle或JCE的子集的帮助下),提供一个API,以透明的方式访问它们.加密将基于文件(而不是块)进行.

我的问题是:

仅使用对称密钥(可能是AES-256)来加密所有文件(它们不会那么多,可能是数十个)并将此密钥存储在密钥库(由引脚保护)或您是否愿意使用存储在每个文件旁边的动态生成的密钥加密每个文件,使用存储在密钥库中的"主"密钥加密该密钥？

每种方法的好处/缺点是什么？