Open jlennox opened 4 years ago
mrjameshamilton
commented
3 years ago Hi @jlennox, thanks for the report!
Are you able to share some minimal version of the mapping that causes the problem? Maybe you could search & replace sensitive names? Maybe a small snippet from the mapping that can reproduce the problem?
jlennox
commented
3 years ago @mrjameshamilton
This code allows matches that lack a line number to have multiple matches. What happens is because proguard re-uses the scrambled identifiers, that when there's no line number information the obfuciated identifier could be multiple things -- but the problem I'm having is proguard will reuse scrambled identifiers as something it already was, causing the duplication seen above. For example, on lines 1-2 a means foo, then on 3-4 a means bar, then on 5-6 a means foo again. This would cause the ReTrace to print out that it could be foo bar or foo the latter most foo being the issue I'm reporting. At least, this is the problem as I understand it to be.
The consumer, of the above code is https://github.com/Guardsquare/proguard/blob/master/retrace/src/proguard/retrace/FrameRemapper.java#L160 needs a hashset that prevents it from hitting those duplicated reuses.
This is a psudo-diff (not tested)
+ Set<string> seenFrames = new Set<string>()
while (methodInfoIterator.hasNext())
{
MethodInfo methodInfo = methodInfoIterator.next();
if (methodInfo.matches(obfuscatedLineNumber,
originalType,
originalArguments))
{
// Do we have a different original first line number?
// We're allowing unknown values, represented as 0.
int lineNumber = obfuscatedFrame.getLineNumber();
if (methodInfo.originalFirstLineNumber != methodInfo.obfuscatedFirstLineNumber)
{
// Do we have an original line number range and
// sufficient information to shift the line number?
lineNumber = methodInfo.originalLastLineNumber != 0 &&
methodInfo.originalLastLineNumber != methodInfo.originalFirstLineNumber &&
methodInfo.obfuscatedFirstLineNumber != 0 &&
lineNumber != 0 ?
methodInfo.originalFirstLineNumber - methodInfo.obfuscatedFirstLineNumber + lineNumber :
methodInfo.originalFirstLineNumber;
}
+ FrameInfo frame = new FrameInfo(methodInfo.originalClassName,
+ sourceFileName(methodInfo.originalClassName),
+ lineNumber,
+ methodInfo.originalType,
+ obfuscatedFrame.getFieldName(),
+ methodInfo.originalName,
+ methodInfo.originalArguments)
+
+ // When no line number is present, skip adding duplicates.
+ if (seenFrames.add(frame.toString())) {
+ continue;
+ }
+
+ originalMethodFrames.add(frame);
- originalMethodFrames.add(new FrameInfo(methodInfo.originalClassName,
- sourceFileName(methodInfo.originalClassName),
- lineNumber,
- methodInfo.originalType,
- obfuscatedFrame.getFieldName(),
- methodInfo.originalName,
- methodInfo.originalArguments));
}
}Sorry but I do not feel ok sharing any portion of a mapping/stack because I do not know what vectors for outside parties that would make available, but I believe my explanation to be sufficient for someone inhouse to reproduce the issue. Using a regex that does not get line numbers should reproduce this easily. This is always the case on Tombstone crashes.
Version: ReTrace 7.0 from the Releases page. Command:
java -jar retrace.jar -regex '(?:.*?/data/app/.+ \(%c\.%m\+.*?)' -verbose mapping-1271.txt tombstone-fancyrgb.txtFiles: Unfortunate I can not publically provide a mapping for privacy/security reasons.Issue: There's massive duplication in the output. It should be evident below.
Input file:
I get output that looks like this: