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
Related
I have the .pyx file that has key string in its code.
Key string must be changed for their own version like real, alpha, beta and so on.
So, I want to change the "Key string" belongs to version when building process.
How can I do this within below process? (Using Jenkins for building the code.)
Make .so file with cython build
Make binary file with pyinstaller
I guess, use the "Active Choices parameter" in Jenkins is required to do this, if it is right then guide me how.
Thanks.
I solve this like below.
Create key storage directory.
Store the various key strings to it.
Use build scenario, and copy the specific key file.
Use --add-file option with pyinstaller, and modify a code that use the file.
I have inherited development of an iPhone app that was originally created overseas. The original developers are no longer available for questions. The app is currently available on the app store. So I assume the zip file that I received of the project is current and complete.
When I first open the project in xcode and do a build, I get hundreds of errors. They are all the same basic error. There are hundreds of .h files with one line:
../../../FBSDKCoreKit/FBSDKCoreKit/FBSDKCoreKit/Internal/ServerConfiguration/FBSDKServerConfiguration.h
I get the error "expected identifier or '(' on the first character of this line in every file.
I tried changing the line to:
#include "/../../../xxxxxxxxx"
and that worked. But as I said, there are several hundred of these files in the project. If this was a running app 'supposedly' from this source code, why should I need to go change hundreds of files and add #include to each line?
This project uses an old version of swift, and I had to go all the way back to xCode 7 to find a development environment that would support it. Is the .h syntax in these files some sort of deprecated syntax that stems from an even older version of xCode? Can some seasoned iPhone app developer tell me about this particular .h file syntax of including another .h file (and why it's failing for me now)?
Basically, if I need to change all of the .h files, then so be it. But I'm more than a bit concerned making this drastic a change to code that supposedly recently built a running app.
Suggestion? Enlightenments? Thanks.
Jerry
The "syntax" you described -- just a single line containing a file name (with a relative path)
../../../FBSDKCoreKit/FBSDKCoreKit/FBSDKCoreKit/Internal/ServerConfiguration/FBSDKServerConfiguration.h
has never ever been correct C/C++/Objective C (preprocessor) syntax. Either is some strange, proprietary custom preprocessing is running, or it's just garbage.
Using
#include "/../.."
is also nonsense: If you start a path with /, you start at the root directory, so navigating up with .. will lead you to root again, and xxxxxxxxx is expected exactly there in the root directory.
This was to the syntax. The semantics is hard to tell without the project.
Maybe it might just help if you completely remove those strange header files,
or comment out the erronous lines
or you need to adjust your include paths in the project to help Xcode find the files
How can I change a file type?
A year ago I wrote a few articles that should be viewed in any text type of program. however, I recently opened them and they are viewed in symbols and alphanumeric characters. In linux os, the 'file' is now in an archived folder type that contains .xml files. in windows os it is 'file' as type of file. it has no extension.
Is there any way to recover the original readable alpha-numeric information in these files?
My preference would be to salvage the original information than redo.
First off the extension doesn't actually mean anything for the information of the file, it's only purpose is as a hint to the OS for deciding which application should be used in opening the file. You can prove this by renaming something like an exe to have a txt extension which will then open in notepad as a lot of seemingly random characters; renaming it back to exe will allow it to run again.
Based on your description the files you mention are some form of binary file, the bad news with that is you need to know either what application was used to create the file in order to be able to open it or what the original file extension was (which would be a hint to the former).
If you don't know either of those pieces of information you can of course use trial and error by guessing what extension it might be, renaming it, then opening it with the associated application and seeing if it worked.
I have read a few tutorials about iOS's tools and processes for i18n/l10n, and am unpleasantly surprised with what I'm seeing. It seems there isn't a solid way of externalizing user-facing strings out of objective C files. Am I missing something?
Description of the problem:
There is a tendency to place English strings directly into the .m file, and the Apple documentation seems to encourage this. While this is also possible in Android, as least in Android there is a clear distinction between externalized and non-externalized strings. With iOS, on the other hand, code that calls for a string tends to look like this:
NSLocalizedString(#"There was an error loading the image.", nil)
In this case, "There was an error loading the image." is the key for this string resource. Therefore if I want to make another reference to the same string in some other place we have to again write code like this:
NSLocalizedString(#"There was an error loading the image.", nil)
But now I have to make sure that I spelled these two strings the same and there is no compile time check to help me confirm that. I could write a helper function called createErrorString, but that's not fun. And I could replace "There was an error loading the image." with a more sensible key like "ERROR_IMAGE_LOAD", but that does not seem to be a common practice, and Apple seems to discourage this sensible behavior. Here is what their documentation states:
"A common convention when developing applications is to use a key name
that equals the value in the language used to develop the
application."
It looks like Apple is recommending that you put the full English string in your source code. So I'll have to try to convince my colleagues to go against Apple's guidance.
Now that I've got all of these user-facing English strings (or keys) in the source code, Apple includes a tool called genstrings that parses the .m files, and spits out a Localizable.strings file that I can then send out for translation. This might work if you are only going to get your app localized one time, but in our company localization is an ongoing iterative process. Look at what the Apple documentation recommends:
"For subsequent runs, it is a good idea to save a copy of your current
strings files before running genstrings. You can then diff the new and
old versions to determine which strings were added to (or changed in)
your project. You can then use this information to update any already
localized versions of your strings files, rather than replacing those
files and localizing them again."
That doesn't seem very good. In Android and Windows8, you internationalize your source tree one time, and from that moment on your externalized strings are owned in the xml files where they belong; in iOS they are owned in source code (sort of) and then tabulated into some intermediate file (or is it?) by some crazy tool. Is the Localizable.strings file an intermediate file or should it be committed into git - we are still debating this at my company.
(And from what I can tell, this is only the beginning. In xib-land, which is where 90% of your user-facing strings live, there also seems to be an inefficient mechanism for l10n. Wil Shipley's article describes this at length.)
Does anyone have any suggestions on a good way to externalize strings in iOS? My main question concerns objective-C strings, but answers pertaining to xib files would also be much appreciated. Thanks!
I found the recommendation to name the key like the english string strange, too.
I name the keys, value e.g "Menu1SettingsTitle" = "Settings".
I dont need genstrings tool, just externalize manually.
And no, the string files is not an intermediate step, they should be in git.
However with that approach i noticed three drawbacks:
1) I detected duplicate names, but that can be moved to a common section for strings like "cancel, delete"
2) If you forget to put a string into that language file, it cannot be found and then the key is displayed, which looks very strange, of course. Otherwise with apples reccomendation, If the key is the english word, it looks "only english" but not worse.
3) The translation process is easier if english is always left, instead of "Menu1SettingsTitle". to solve that i put a comment above, but dont know if the translation service would be happy with that.
After a couple of hours searching I decided to use two different approaches: one for the storyboards and one for the text inside the .m files. The result are two files Localizable.strings for the Objective C text and the internationalized storyboard.
The update_storyboard_strings.sh can automatically extract translatable strings from storyboards and update strings files. The source code (by mikezang) can be found at:
http://forums.macrumors.com/showpost.php?p=16060008&postcount=4
For the objective C NLS I use another script around the xcode-tools by Frédéric Sagnes:
https://github.com/ndfred/xcode-tools
I had to call it for each language in order to get the desired results:
python scripts/xcode-tools/update_strings.py --import=MyProject/Base.lproj/Localizable.strings MyProject/Base.lproj/Localizable.strings
python scripts/xcode-tools/update_strings.py --import=MyProject/de.lproj/Localizable.strings MyProject/de.lproj/Localizable.strings
Now put both in one script and add it to your Xcode project as a last build phase.
J2ME lacks the java.util.Properties class. Although it is possible to put application settings in the JAD file this is not recommended for many properties. (Since, some platforms limits the size of JAD file.) I want to put a configuration file inside my jar file and parse it. And I do not want to go with XML because it will be overshooting for my case.
Question is, is there an already existing library for J2ME that can parse properties files or something similar such as INI file. Or would you recommend another method to solve the initial problem?
The best solution probably depends on what is going to be generating the properties files.
If you've got other non-JavaME projects using the same properties files, then stick with them, and write or find a parser. (There is a simple one from GoBible available on Google Code)
However you might find it just as easy to keep your configuration as static final String myproperty="myvalue"; in a Configuration.java file which you compile, and include in the jar instead, since you then do not need any special code to locate, open, read, and parse them.
You do then pick up a limitation on what you call them though, since you can no longer use the common dot separated namespacing idiom.