Safer report generation

[pabx06]

any idea on how to get debug logs from the unpacker ? so ican try to figure out what is going on with the unpacker ?

[dorpvom]

I'll have a look on the code tomorrow. From the top of my head I'd say easiest would be to run the extractor local (not inside a container) and use debug logging. But to be sure I have to check the code.

[pabx06]

[pabx06]

the firmware is packed inside this EXE:

[dorpvom]

I'll have a look, keep you posted

[dorpvom]

So a couple of observations here:

Our PJL extractor was written once specifically for HP printers (which your example matches) but looks for specific pjl commands that are not present in the given example. Specifically the extractor looks for the UPGRADE command and a SIZE that comes with that. Both are not present in the muscatel_vr3_pp_MCP2CN1910AR_nbx_signed.ful file.

Regarding debug information, I at least get the found PJL commands when I run the extractor from command line

"pjl_commands": [
        {
            "raw": "@PJL COMMENT ",
            "begin_offset": 9,
            "end_offset": 22,
            "type": "COMMENT",
            "value": null
        },
        {
            "raw": "@PJL ENTER LANGUAGE=FWUPDATE",
            "begin_offset": 29,
            "end_offset": 57,
            "type": "ENTER",
            "value": "LANGUAGE=FWUPDATE"
        },
        {
            "raw": "@PJL ENTER LANGUAGE=13",
            "begin_offset": 930682,
            "end_offset": 930704,
            "type": "ENTER",
            "value": "LANGUAGE=13"
        },
        {
            "raw": "@PJL ENTER LANGUAGE=PCL3GUI",
            "begin_offset": 931600,
            "end_offset": 931627,
            "type": "ENTER",
            "value": "LANGUAGE=PCL3GUI"
        },
        {
            "raw": "@PJL COMMENT=",
            "begin_offset": 2251507,
            "end_offset": 2251520,
            "type": "COMMENT=",
            "value": null
        },
        {
            "raw": "@PJL SET",
            "begin_offset": 23710012,
            "end_offset": 23710020,
            "type": "SET",
            "value": null
        },
        {
            "raw": "@PJL SE_T ",
            "begin_offset": 25360573,
            "end_offset": 25360583,
            "type": "SE_T",
            "value": null
        }
    ],

There might be an easy adjustment the extractor for supporting this seemingly different update format. Though I'd have to comb through more examples and do some reversing probably to figure it out.

If you have an idea or even a solution in place I'd be happy to integrate it (or you could do a Pull Request yourself). Otherwise I'd open an issue to at least add some information on why the extraction fails.

[pabx06]

I think that the size can be infered from the file content and be initialized with a value in case the @pjl size is not present ? However i am not yet familiar with the pjl format or upgrade commad. Opening a bug report would be good also may be comming out with some unit-test case ?

[pabx06]

i tried the extractor on a 4 more model firmware. it turns out that they do indeed use PJL commands. But not the 'upgrade' type of Command nor they have fingerprints string expression. pjl.py is only willing to extract the upgrade type and the Fingerprint string. it seems they have introduced a new set of command none of them are publicly documented .

may be adding 'extract_all_other_pjl_command()' right after pjl.py:28:extract_all_upgrades(file_binary, pjl_commands, tmp_dir) could be usseful ?

i know that the printer i am working on has at least two flash memory and at least two eproms... some of them doesnt have datasheet and those who do have datasheet have read protection/deletion and password protection and JTAG debug disabled

as for the Os my guess is µC/OS-II

[dorpvom]

Looking at some of the printer images that have been successfully been extracted with this, I've found that most of the magic is done after the initial pjl.py dumps the upgrade blobs. The update_stream.py then decompresses the containing parts. There we found some ThreadX OSs. I'll see if I can backwards my way to an adaption of the pjl.py. Might be some days till I get there though.

[dorpvom]

I've had a look and it turns out, the format differs in more ways than merely the keywords. I'll discuss this with @weidenba who wrote all the HP stuff. Maybe he has an idea towards solving this problem. Could be just another compression with truncated header information (as for the lzma streams), could also be some encryption, which would make life a lot harder for us.

[pabx06]

Was able to dump some serial i2c eeprom from the hardware motherboard. With an test clip. It coulde be an in application programming of either touchpannel mcu or the marvell arm processor... i can send it if anyone want it ...

[martinpriv-cyber]

el firmware está empaquetado dentro de este EXE:

Hello, you will have that file OJP6970_1910A.exe, you can pass it to me that I need it for my printer, since it was taken from the ftp server.

[martinpriv-cyber]

@pabx06 Hello, you will have that file OJP6970_1910A.exe, you can pass it to me that I need it for my printer, since it was taken from the ftp server.

[martinpriv-cyber]

Hi, someone has the file OJP6970_1910A.exe for the hp officejet pro 6970 printer, I need it to print

[pabx06]

there is a newer version at the url. i didnt keep the original exe i have an unpacked one