Firmware Extraction via UART (old SagemCom router)

[DarkLeksis]

Hello,

I've asked this question on two different reverse engineering forum but no one seems to care / have the capacities to respond. I'm trying here even thought it migth seems a little bit off topic.

I recently extracted the firmware (u-boot system) from an old Sagemcom router and analyzed it using the binwalk utility for a personal reverse engineering project.
Despite identifying a root filesystem (likely JFFS2 based on string analysis), binwalk was unable to recognize or extract it.
I know that the filesystem is JFFS by examining the boot info, and performing strings analysis on my dump. (You can check the git repo given further down)

Steps Taken:​

1. Initial Extraction with Binwalk:

• Binwalk was used to analyze the firmware, but it failed to identify the root filesystem.

2. Manual Binary Segmentation:

• Based on MTD (Memory Technology Device) partitions, I attempted to segment the binary using the dd command.
• Encountered overlapping addresses and excessive total pages exceeding 65536 (total memory size of 16MB divided by page size of 2048 bytes).

Challenges:​

• Translating MTD addresses to NAND offsets.
• Understanding the relationship between MTD partitions and NAND subsystems.
• Ensuring correct memory dumping and assembly.
• Extracting the JFFS2 rootfs

Additional Information:

• Utilized dd for binary segmentation.
• Cleaned .dmp files to remove Out-Of-Band (OOB) data and other unnecessary lines.

Memory Extraction steps:

• Script that i used on my git repo

1. dump from router throught UART : 'dump_nand_memory.py' ; use nand dump offset to dump nand page
2. assure no error in the file : assure_140_lines.py
3. clean .dmp file (dont keep oob) : clean_dmp.py
4. concatenante all .dmp file into .bin : concatenated_all_to_bin.py
5. Search for magic number in the binary for JFFS2 filesystem : check_for_JFFS2.py

Questions:

• How do I accurately convert MTD partition addresses into corresponding NAND offsets?
• Is MTD simply an abstraction layer for NAND, or is there more complexity involved ?
• Do i have correctly extracted memory, do i need to correct errors using OOB ?
• Where can i find more info about u-boot, embed system, ... (doc is pretty much non existent)

Thanks in advance for your help / responses.

[bdleonard]

From what I can see in the logs you posted, you've actually done fine. Your issue appears to be that most everything lives inside of ubi volumes. You can use something like the UBI reader python utility on your full nand binary to pull them out.

[DarkLeksis]

First of all, thank you for your reply. I have installed and used ubi reader from AUR. Unfortunately the analysis and extraction did not give convincing results.

Methodology :

1. Fist i've installed and extracted content with binwalk using : sudo binwalk -e firwmare.bin --run-as=root -> it gaves me a folder _firmware.bin.extracted/ older where you can see the tree structure here :

> tree -L 3 _firmware.bin.extracted/
├── C0000.ubi
├── C8D28.lzo
└── ubifs-root
    └── 0
        └── secondaryboot

4 directories, 2 files

It might seems at first good news seeing ubifs-roots subfolder however here's further analysis

2. I've used ubireader_display_info firmware.bin but no result

3. I've used ubireader_display_info _firmware.bin.extracted/C000.ubi result here on my repo

4. C8D28.lzo seem promising due to it's size of 127MB but extracion with lzop C8D28.lzo tell us that the header is corrupted

5. ubifs-root tree structure contain nothing but empty folder. It seems like it only extracted secondary boot volum from image 0 and not others.
   

   

Questions :

• What can i do ?
• Where can i find more info ?
• Is there a way for me to bypass / recover lzo headers ?

Thanks in advance for your responses

[bdleonard]

Nope. Just use ubireader on your full (decompressed) "nand-65535-bin". Leave binwalk out of it at this point. I just tried it myself and it worked fine. Note, this will not pull out the other non ubi mtd sections.

[DarkLeksis]

My bad you are totally right.
I've extracted a bunch of .ubifs from the image 0 and will perform more researches on them.
Thank you

[bdleonard]

No problem. An additional note, even though the tool has labeled the segments it had found as ubifs, they may not be. If they are ubifs, the ubi reader tools can also be used to extract the ubifs contents. For ones that are not, some manual analysis, or a tool like binwalk, will likely tell you what they are.

[DarkLeksis]

Thanks to your advices, I finally managed to extract the whole filesystem from the different partitions (operational & rescue).
Since my objective is to reverse engineer the router i've targeted /etc/passwd and ./etc/shadow files.
Unfortunately the contents of these files show me that the authentication system for root has been delegated to a system other than the default Linux system.
Is it common pratice for U-boot and does the password hash has been moved somewhere else ? Or may i assume that the router was probably configured via network by using LDAP, NIS, ... letting me nearly no hope for getting this password has ?
Thank as always for your response.

[bdleonard]

I can't really say I have any advice there, other than to say that sounds unusual, particularly for attempting to log in via a serial console. If you can't find those files you may want to check for an additional compressed filesystem packed with the kernel image.