Difference between my compiled GPL versus ASUS stock firmware

[Fitz Mutch]

After compiling the 382.18547 GPL source code for RT-AC68U, I noticed that it is 659,456 bytes smaller than the same firmware released by ASUS. Upon closer inspection the biggest size difference, I can see, is the BWDPI kernel modules found here: /usr/bwdpi.

Maybe someone forgot to strip the symbols? It's not automatic? Same thing with 382.18881. No issue with Asuswrt-Merlin here, just a heads up.

How to show file size differences between firmwares

binwalk -e FW_RT_AC68U_300438218547.trx
binwalk -e RT-AC68U_3.0.0.4_382_18547-g91c580f.trx
cd _FW_RT_AC68U_300438218547.trx.extracted ; du -abS --apparent-size >../a.txt ; cd ..
cd _RT-AC68U_3.0.0.4_382_18547-g91c580f.trx.extracted ; du -abS --apparent-size >../b.txt ; cd ..
diff a.txt b.txt >c.txt

 

[bsdsource]

Some prebuilt binaries could be missing from the source code. For instance when the first 382 build source code was released for the RT-AC3100 I had to recover some of the missing binaries from the installed 382 firmware. Here's my repository and some changes I had made:

https://github.com/azdps/asuswrt/commits/master

Sometimes the wrong binary blobs are released as well. I've compared the source code I built to what ASUS released and some of the binary md5 sum hashes didn't match.

arpstorm is a good example. It was not included in the ASUS RT-AC3100 source code but was in the released firmware. armstorm for instance could be excluded from the build and you will still end up with a working firmware.

To find out what was missing from the source code I first installed the released firmware and used the "find ." command from the shell prompt to get a complete directory structure and saved the results. Then did the same for firmware I built from the source code and compared the 2 results to see if anything was missing and to my surprise there were some binary files missing.

If you aren't missing anything you could always check the md5 sum hashes to see if they match up to yours. I use code compare with Windows 10 and it works great for comparing files.

I haven't had a chance to try your commands to compare differences but it looks like they could save some time.

 

[Fitz Mutch]

I've compared the source code I built to what ASUS released and some of the binary md5 sum hashes didn't match.

Your compiled programs will most always have a different md5sum, even when the source code is the same. It's your C compiler and linker that cause this.

It's quicker to compare the file sizes. If the size difference is > 40 bytes then you've probable got different source code.

Here's the most notable differences in my compiled 382.18547 GPL source code for RT-AC68U compared to ASUS' released firmware.

< 752191    /usr/bwdpi/tdts.ko
> 377388    /usr/bwdpi/tdts.ko

< 941206    /usr/bwdpi/tdts_udb.ko
> 235292    /usr/bwdpi/tdts_udb.ko

< 1232532    /usr/bwdpi/tdts_udbfw.ko
> 43776        /usr/bwdpi/tdts_udbfw.ko

< 366144    /lib/modules/2.6.36.4brcmarm/kernel/drivers/usb/Beceem_driver/drxvi314.ko
> 383220    /lib/modules/2.6.36.4brcmarm/kernel/drivers/usb/Beceem_driver/drxvi314.ko

< 24268   /lib/libengine_beceem.so
> 31335   /lib/libengine_beceem.so

< 456588    /lib/libxvi020.so.05.02.93
> 502347    /lib/libxvi020.so.05.02.93

< 168352    /lib/libeap_supplicant.so
> 197477    /lib/libeap_supplicant.so

 

[RMerlin]

Major size differences usually indicate that the file wasn't stripped. Strip it, then compare the size again.

Also make sure you compare files of the same architecture/SDK (i.e. ARM 7.14 with ARM 7.14).

 

[Fitz Mutch]

Strip it, then compare the size again.

After stripping the ASUS files, they are now smaller than my compiled ones. I just used arm-brcm-linux-uclibcgnueabi-strip *, without any special options.

                               ASUS   Stripped   Compiled
/usr/bwdpi/tdts.ko          752,191    289,636    377,388
/usr/bwdpi/tdts_udbfw.ko  1,232,532     29,080     43,776
/usr/bwdpi/tdts_udb.ko      941,206    160,568    235,292

 

[bsdsource]

I've compared the source code I built to what ASUS released and some of the binary md5 sum hashes didn't match.

Sorry didn't get a chance to revisit this earlier. My quote above wasn't what I meant to say. For clarity sake I compared the ASUS firmware binary blobs to the ASUS source code binary blobs that were released and some of the binary blob's md5sum's were different, and some blobs were missing.