📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.








Flag: Tornado! Hurricane!

Blogs >> sp's Blog

Created: Wednesday, November 16 2005 15:43.18 CST Modified: Wednesday, November 16 2005 15:43.18 CST
This is an imported entry. View original. Printer Friendly ...
Is F4I in violation of the LGPL? - Part III
Author: sp # Views: 1452

"Frank" posted the following comment to my last update.

"What does this code fragment do? It accesses data that is well-defined by an open specification. There is little leeway for a software developer to do things differently. So far, this may be coincidence, or a case of developers being "inspired" by looking at other source code -- like the famous "stolen" Unix code fragments in Linux. This is an invitation for more research, yes, but I dont see a smoking gun just yet."

This is a valid concern and I wanted to address this anyway, so lets do it right here. I think its important enough to write a new update instead of just replying to Frank.

Ive produced a complete annotated disassembly of the function in question. It matches the function from the LAME code 99%. I say 99% because there are differences which can be reasonably explained by common compiler optimization techniques. Ive mentioned these techniques in the annotated disassembly where appropriate.

If the 99%/100% match of a 90 lines C function is a coincidence it goes beyond what Im capable to detect using my tools.

Click here for the LAME source code.
.
.
.
Click here for the annotated disassembly.
.
.
.

Edit: I want to ask the people familiar with the LAME function in question something. Look at the following four lines from the LAME source code:

	if( buf[0] != VBRTag[0] && buf[0] != VBRTag2[0] ) return 0;    / fail /
	if( buf[1] != VBRTag[1] && buf[1] != VBRTag2[1]) return 0;    /* header not found*/
	if( buf[2] != VBRTag[2] && buf[2] != VBRTag2[2]) return 0;
	if( buf[3] != VBRTag[3] && buf[3] != VBRTag2[3]) return 0;

This piece of code attempts to check if buf contains Xing or Info. I dont know about the underlying data structures but the way it checks looks wrong to me. This piece of code passes if buf is a combination of Xing and Info, like Iing or Xnfo which is probably not the desired functionality. Can anybody confirm that this is a bug or is not a bug? Because if its a bug its also part of the F4I code. This would solidify the assumption that the code was stolen from LAME even more.

Edit: OK guys, Im going to proclaim victory now as Ive found undeniable proof that this match is not a coincidence. I just took the the functions GetVbrTag and ExtractI4 from the LAME code and compiled them myself using the freely available Visual C++ 2003 commandline tools. The only compiler parameter I used is /Ox to turn on maximum optimizations. The resulting code is byte for byte the code from the F4I OCX file. Including all my correctly predicted compiler optimizations (function inlining, if-clause merging, operation re-ordering, ...).

Click here to see the disassembly of my own compiled version of the LAME code. It matches the disassembly posted earlier perfectly. Note that I didnt bother to re-name variables or to insert comments.


If you wish to comment on this blog entry, please do so on the original site it was imported from.

There are 31,328 total registered users.


Recently Created Topics
[help] Unpacking VMP...
Mar/12
Reverse Engineering ...
Jul/06
let 'IDAPython' impo...
Sep/24
set 'IDAPython' as t...
Sep/24
GuessType return une...
Sep/20
About retrieving the...
Sep/07
How to find specific...
Aug/15
How to get data depe...
Jul/07
Identify RVA data in...
May/06
Question about memor...
Dec/12


Recent Forum Posts
Finding the procedur...
rolEYder
Question about debbu...
rolEYder
Identify RVA data in...
sohlow
let 'IDAPython' impo...
sohlow
How to find specific...
hackgreti
Problem with ollydbg
sh3dow
How can I write olly...
sh3dow
New LoadMAP plugin v...
mefisto...
Intel pin in loaded ...
djnemo
OOP_RE tool available?
Bl4ckm4n


Recent Blog Entries
halsten
Mar/14
Breaking IonCUBE VM

oleavr
Oct/24
Anatomy of a code tracer

hasherezade
Sep/24
IAT Patcher - new tool for ...

oleavr
Aug/27
CryptoShark: code tracer ba...

oleavr
Jun/25
Build a debugger in 5 minutes

More ...


Recent Blog Comments
nieo on:
Mar/22
IAT Patcher - new tool for ...

djnemo on:
Nov/17
Kernel debugger vs user mod...

acel on:
Nov/14
Kernel debugger vs user mod...

pedram on:
Dec/21
frida.github.io: scriptable...

capadleman on:
Jun/19
Using NtCreateThreadEx for ...

More ...


Imagery
SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit