I have private pdb file and I have to convert it to a public one. Is there tool for it?
Use PDBCopy.
pdbcopy is part of the Debugging Tools for Windows which is available through the Windows SDK
You can create a stripped pdb file that doesn't contain; Type information, Line number information, Per-object file CodeView symbols such as those for functions, locals, and static data. See the /PDBSTRIPPED compiler option.
EDIT: There does appear to be a utility that is part of the DDK that can convert a full symbol file to a stripped symbol file it is called BinPlace the forum I found the information on suggested there might be problems with certain versions of the utility so be warned (forum article).
Related
I have a legacy Windows project using the legacy 32 Bit C++ compiler. For various reasons I need to use the Windows 8+ function PathCchCanonicalizeEx. C++Builder seems to provide the header and some module definition file for that, but I can't find any library to link against:
[ilink32 Error] Error: Unresolved external 'PathCchCanonicalizeEx' referenced from C:\[...]\WIN32\DEBUG\TMP\FILE.OBJ
How am I supposed to fix this? Do I need to add a Windows 8.1 SDK? Is the necessary lib simply named differently and I can't find it? Something completely different?
According my tests, one has two options:
IMPLIB/MKEXP
I'm developing/testing a some Windows 10 21H2, which provides an implementation for PathCchCanonicalizeEx in some DLL already. So if that source DLL is known, one can use IMPLIB or MKEXP to create an import library manually. I did that and after adding the created library from IMPLIB to my project, the linker errors were instantly gone.
Though, it's not that easy to know where PathCchCanonicalizeEx is placed in. One pretty easily finds the api-ms-win-core-path-l1-1-0.dll, but that thing is NOT an actual file on the disk and therefore can't be used by IMPLIB or MKEXP. That name is only a virtual concept for the library loader to address the same named API set of modern Windows, the extension .dll doesn't mean it's a file at all.
You can use an API set name in the context of a loader operation such as LoadLibrary or P/Invoke instead of a DLL module name to ensure a correct route to the implementation no matter where the API is actually implemented on the current device. However, when you do this you must append the string .dll at the end of the contract name. This is a requirement of the loader to function properly, and is not considered actually a part of the contract name. Although contract names appear similar to DLL names in this context, they are fundamentally different from DLL module names and do not directly refer to a file on disk.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets#api-set-contract-names
What you really need to work with is KernelBase.dll, which is even documented by MS.
implib "KernelBase x86.lib" C:\Windows\SysWOW64\KernelBase.dll
implib "KernelBase x86-64.lib" C:\Windows\System32\KernelBase.dll
Module Definition File
The downside of manually creating LIB files is that one needs to maintain those with the project. Things depend on if the target is 32 or 64 Bit, DEBUG or RELEASE, so paths might become a bit complex, one might need to create relative paths for libraries in the project settings using placeholders for the target and stuff like that.
It seems that all of this can be avoided with Module Definition Files, which's purpose is to provide IMPORT and EXPORT statements to either consume exported functions by other DLLs or make that possible for others with own functions. I've successfully resolved my linker problems by simply creating a file named like my app using the extension .def alongside my other project files. That file needs to be added to the project, though.
dbxml.cbproj
dbxml.cbproj.local
dbxml.cpp
dbxml.def
dbxml.res
[...]
The following content made the app use the correct function from the correct DLL. Though, what didn't work was using the API set name, which resulted in an error message by the linker.
IMPORTS
KernelBase.PathCchCanonicalizeEx
IMPORTS
api-ms-win-core-path-l1-1-0.PathCchCanonicalizeEx
[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.
[ilink32 Error] Fatal: Error processing .DEF file
The latter is after restarting C++Builder, so I guess the format of the file is simply wrong because of the API set name.
I'm trying to setup the files from LuaBinaries (specifically Lua 5.2.4 64-bit), and there are a few things I'm confused about.
There are two zip files provided, the binaries: lua-*_Win*_bin.zip and the libraries: lua-*_Win*_*_lib.zip
So, these are my questions:
For the libraries, two versions are provided, static and dynamic. What's the difference?
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
For the libraries, two versions are provided, static and dynamic. What's the difference?
The static library can be embedded into your own program. While the dynamic library is linked to your program, so the system will search for it when running your program. If the search for the dynamic library failed, the system won't be able to run your program correctly.
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
The lua*.dll under lua-*_Win*_bin.zip is the dynamic link library(.dll) used by lua.exe and luac.exe. An error will be thrown by Windows if you run lua.exe after deleting it.
Which one should you use? It depends on your purpose. Usually you want to use the static library in you project.
Running different versions of Lua bytecode (e.g., runs the bytecode created by luac v5.1.4 with lua v5.2.4) is forbidden (by checking the header of bytecode files).
Lua sometimes brings breaking changes upon upgrading, and some public APIs vary between different versions. If you build and install Lua from source code, only the binaries and the static library are produced.
Lua is a very tiny language (the static library under Linux is about 356K(v5.1.4) or 440K(v5.3.3), measured by du -sh liblua.a), so embedding the static library with your program is fine for many high-end devices.
If you feel familiar with make command, you can build Lua from source code and load it into your project. Or, just use the static library in your project. (I don't think most Windows users have a lua*.dll in their enviroment.)
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
No, the libxxx.a and libxxx.so is the static and dynamic library naming conventions under *nix systems, like Linux and FreeBSD.
the app where I am working on was audited and the security team has a concern that consists in: so, for some reason if I extract the .ipa's payload I am able to identify which CI/CD tool was used to generate it. For example:
Terminal:
cd MyApp.app <- payload
strings * > ~/Desktop/file.txt
Inside the file I can find that we are using jenkins
/Volumes/jenkins-workspace/MyApp-Generic/MyApp/MyApp/SomeViewModel.swift
Has anyone faced this problem (if we can call it a problem)? Is there a way to obfuscate or completely remove this kind of references from the IPA?
Thanks
Does that file have a fatalError() call in it? If so, the file and line number will be reported when it runs. Here's a way to fix that if you really need the fatalError call.
If any of your source files have #file compiler directives in them, they will record the path to the file in the executable.
Swift 5.3 introduces a #fileID identifier which produces a shorter
string than #file. The #fileID string contains the filename and module
name, but leaves out the rest of the path to the file; this saves
space, improves performance, and avoids accidentally embedding private
information like the developer’s home directory name in binaries.
Compiler-generated error messages (like force-unwraps) and standard
library assertions like precondition and fatalError now use #fileID
strings, and we recommend you use them instead of #file in production
code. (SE-0285, 65514304)
This pretty much sums my problem. I am using the #file identifier in some methods (mostly for logs) and every file that calls that methods will appear embedded in the app binary.
Ref: https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes
I have a map file created by delphi compiler and I need to use it to analyze DMP file.
I converted the map file to dbg file, using Map2dbg.
The problem is that the process has a different signeture then the symbols.
I tried to use chkmatch to match the signeture, but I'm getting:
Error: Debug information not found in the executable
I guess this is because it is a delphi process.
Does anyone know how to match the signatures?
I made a minidumpreader some time ago:
https://asmprofiler.googlecode.com/svn/trunk/MiniDumpReader/ViewMinidump.exe (old link)
https://github.com/andremussche/asmprofiler/tree/master/Releases/ViewMinidump.exe (new link)
It is written in Delphi with jclDebug.pas so it supports all delphi debug symbols.
And because of this it has line number support (which map2dbg or tds2pdb don't have).
Note: I haven't made map2dbg or tds2pdb myself, just hosting it so other can easily find it
I got an API for a lib file.
With that lib file .h files were supplied.
Now i want to call the lib file within the Delphi, and use its functionality.
how does the lib file get connected to the Delphi?
update: ok allot of work around is needed, what if i get a dll? how do i link that into the Delphi?
You can't use a lib file to link to a DLL from Delphi. The .lib file would be used by C or C++ clients of the DLL.
In Delphi you need to manually translate the .h header file into a Pascal import unit using the external keyword. An example of this of the Windows.pas unit in the Delphi source. The fact that you can't use the .lib file is actually not a big issue because you have to translate the .h file no matter what.
In certain cases it is possible to extract members of a .lib file using tools like the object file converter from Agner Fog (see http://www.agner.org/optimize/?e=0,34,36) to .obj files.
The syntax is
objconv.exe libname.lib -lx
to extract all members.
By extracting all members you can ensure that there are no members missing. However, if there are further dependencies (to other .lib files) these won't be resolved and must be resolved manually.
Also translating the header files is still required.
Note: The object file format can also be converted. Delphi only understands OMF, while Intel compilers (for exampl) spit out only COFF. Thus a conversion is required, which can be done by the tool as well.
As said this only works in certain cases and it surely need some expertise in this area, because the compiler won't help much with error messages (often the messages are irritating and misleading).