PboX cannot unpack OWP_Mi8

[AiRbLaDE]

Hi, Im new to the boards and I thought this would be a good place to start my first topic.  I'd just like to say im an operation flashpoint adict just as many of you probally are.

But there has been one thing really bothering me... and that is the OWP_Mi8 addon.  You might say "OH AIRBLADE HOW CAN YOU SAY SUCH A THING?"  Well its not an actual problem with the addon.

I have been attempting to unpbo this addon for the longest time without sucess.  Has anyone here been able to unpbo this addon?

I want to do this so I can use one of their helicopters to replace the BIS Mi17.  And so I can recompress the addon so it will take up less space on my computer.

The strange thing is, I have used the hex editor and changed the convert.bin into convert.xyz in the pbo decryptor and I have still not been able to unpbo it.  I tried using total commander with the correct plugins.  I even tried using pbox v1.0 without any luck.

Any help is appreciated.  Dont be shy to post anything !

[Snake_Man]

I tested the lowres version with PboX v1.0 and indeed it will not unpack it. Thanks for letting us know.

[AiRbLaDE]

No problem.

I do know there is some way this addon can be uncompressed.  A few people in the OWP_Mi8 topic at the BIS forums said they were able do to this.  And they even posted screenshots of viewing the OWP helicopter models in the o2 viewer.

and also: i dont know if this would help anyone with being able to decompress the addon, but inside the OWP_mi8.pbo there is a file named SIS and this is what is extracted when I attempt to unpack it.

and I asked the people who were able to uncompress it if they would tell me how to do it, but they simply told me NO.

[vektorboson]

and also: i dont know if this would help anyone with being able to decompress the addon, but inside the OWP_mi8.pbo there is a file named SIS and this is what is extracted when I attempt to unpack it.

The "SIS" is not a file, but it is the end of "Cold War Crisis". It's a product entry, and PboX doesn't know about product entries. You may try Mikero's DePboDll which interprets this entry correctly.
Another thing is: You have to take a HexEditor and search for filenames that end with ".***" (without commas). Change the .*** into .hpp; I haven't tried to open it, as I have no interest in that addon, so perhaps there are other traps.

[AiRbLaDE]

Yes there were also files with .*** on them. So I will try what you said and then i'll post my results here if I get anything. Thanks.

[Mike]

If you provide me a url that points to this beast I'll have a look at it for you.

there are several 'undocumented features' with Resistance format pbo's but as Vektorbosen has already mentioned, my dll hasn't had any trouble with them.

There is of course a silly crippler in Amalfi's depbo1.5 which intentionally will not decode pbo's which have convert.bin inside them.

I'm always interested in this stuff, so a url would be appreciated. Thanks.

[AiRbLaDE]

no problem.  heres the link
http://www.flashpoint1985.com/cgi-bin/i ... =4;t=49547

edit: I tried using mike's depbodll and I could not even get it to start.  Whenever I clicked on the .exe files for this program they would come up for a second then close itself.  And yes I did install the dll in my windows/system folder.

and I reopened the OWP_mi8.pbo to view what is inside it with pbox, and I saw some files with (C) in front of them.  Is there some way I can remove these (C) things with the hex editor or will they effect anything at all?

[Snake_Man]

with pbox, and I saw some files with (C) in front of them.  Is there some way I can remove these (C) things with the hex editor or will they effect anything at all?

The (C) is to let you know that the pbo is compressed.

[vektorboson]

edit: I tried using mike's depbodll and I could not even get it to start.  Whenever I clicked on the .exe files for this program they would come up for a second then close itself.  And yes I did install the dll in my windows/system folder.

It's a command line program; try to drag&drop the PBO on the Exe.

[AiRbLaDE]

It's a command line program; try to drag&drop the PBO on the Exe.

Ok I did this and it did work.  But the extractpbo.exe will only create one folder with a texture file that is 0mb in size.  So ovbiously it is still being blocked.

anyone else like to share what they have tried?  :D

edit: I found out some of the people who were able to unpack this addon said they used the hex editor. They did not mention any other programs. So this is what should be concentrated on...

[Mike]

@Vektorboson

obviously you're using "D" programming language


[s]have had a look at this interesting pbo and there are, as you say entries

blibblabcfgvehicles.***

among others.

the config.cpp for this addon states

#include "OWP_Mi8configcfgPatches.***"

among other things. And, try as I might to create a quick 'n dirty addon using this style of include ends in failure, ofp engine wise.

i've tried the usual suspects like .hpp, .anythiing , (dot) spaces but still errors. so i don't know what to make of it.

my dll of course is happy with the pbo but it refuses point blank to make such a folder or name, which is fair enough.

clearly our comrades have uncovered an engine quirk and are exploiting it to prevent decryption, but, i'm not happy with the idea of wildcards at all, and think the entire thing is exceptionally dangerous so might give this a miss.
[/s]

[Mike]

@AirBlade


here you go MikePbo

(for you [s]to two[/s] too VektorBoson)

[vektorboson]

@Vektorboson

obviously you're using "D" programming language

You took a look at my source?  ;)

Hehe, my bin2cpp extracted the config.cpp without problems (didn't have to modify anything, thanks to your complete PBO-documentation); therefore I saw that they used #include <...***>
I've got to admit, to use invalid filename characters is a nice way to "protect" their addon; but it's nothing new, as fWatch does use ':' for its functions (exploting the same filename lookup from OFP).

[Mike]

>exploting the same filename lookup from OFP

in technospeak, any reference by the engine beginning "blobblabblib" is a pbo reference a call to something held in memory and hence the normal file system rules of the OS don't apply. On the other hand, any reference by the engine to "blibblabblob" is a FILE reference. You can see this effect on any addon where the filename of the addon is actually and mostly inconsequential. PinkGiraffes.pbo is called internally "myGreatSoldierblibblob" in the classname of the pbo and it is the classname that the reference refers to (masqueraded as a filename)

Our comrades as you say have come up with a new way of protecting their intellectual property. they arbtirarily name specific files as something.*** some of them are p3d files, some of them are hpp files. Which ones. are arbitrary in the sense that they deicded to hash some p3d's and leave others alone.

Mikepbo mentioned above will correctly extract this stuff but flags such files as something.zzz since the content isn't known at the time of extraction (be it a text file or an ODOL). It doesn't help Joe Grunt going further and then examinaing things in say WrpTool or WrpEdit or OdolExplorer. He has to manually rename the zzz files to whatever they should be called, and even then, the internal references in other files will be wrong.

so all in all, nice one comrades.

[AiRbLaDE]

Yes, this is a new way to protect addons.  But I discovered how to uncompress it.  Its very simple actually.

Open the file up in hex editor.  Look at the very top line of code in the file.  You will see something that says Protect.  You must change every letter in the word Protect to those square boxes using the 00 code line.

[Mike]

I have no idea what you think you're fixing there Airblade, that entry is nothing more, and nothing less, than the standard pbo : resistance file format where the first three entries are product strings. But that does nothing for the *** files other than the fact that in your current poor choice of pbo tool you will now be able to view their names, and, depending on the tool, it will allow you to view the content, but extracting them to a file is a different matter and can't be done in the 'normal' fashion.

all the same it was a good spot airblade, nice one, because they've been very naughty and put the word 'protect' in the size and reserved fields.

[AiRbLaDE]

well then after you get rid of the protect at the top of the file, you must also change all the files with *** in hex editor to either p3d or hpp depending on the type.  Then it works fine.  And after you decompress it, you have to go through all the hpp and script files in the decompressed addon and the change *** to p3d or hpp.

[Dalai_Lamar]

Hey Airblade...Any chance on bumming the decrypted file from you...or at least pointing me in the direction of the hex editor you used...all the freeware versions i dlded were not powerful enough....Any help would be appreciated!

Best,

Lamar

[Mike]

http://www.andrew.nf/OFP/Tools/ExtractPboV1.1.zip

enjoy

[Dalai_Lamar]

Wow...Bungle...Ty very much....That worked like a champ! Very generous of you!

Lamar

[Dalai_Lamar]

Well Dangit....It was working hehe...I got to the cpps...You have to change them fromm zzz files to cpps, but the Sqs files are jumbled and blank as are the paa and Pac files...wierd....can't figure out how to get those to decompress....Still thank you for getting us this far!

Lamar

[Mike]

Any 'file' name XYZ.*** is autoconverted to zzz by the exe in order to scribble it to the hard drive.

there is no rhyme or reason *which* files are treated in this manner, some are paa files, some are sqms, what our Russion comrades did was arbitrarily select any random files to mistreat in this manner by renaming them from object.paa (eg) to object.zzz just prior to creating a pbo with their special tool.


>blank as are the paa and Pac files

SOME only are blank. not all. I can assure you, that *is* the way they were pre-packaged into the pbo. There's nothing additional, extra, or clever, that recovers any data in an 'empty' file because there isn't any data for it to begin with. This is *before* that file is packed into a pbo. It's empty to start with.

why it is empty, and how it is empty. no-one's bothered yet to decode. The important bit is, it has nothing to do with the pbo it comes in. On this, I can assure you on that, and I can garantee for you the data and files being extracted from the pbo are 'correct'. Nothing courrupted, nothing missing, and nothing extra.

[Dalai_Lamar]

Nevermind...You're a genious...figured it all out thanks to you.....Wierd...they threw in some red herring files in there.....If I'd been more careful in my inspection I would have see them....Thanks again for all your help!

Lamar

[Mike]

Thank you for your kind comments. If you ever do figure out the meaning of the zero length files (as in how do the p3d models actually get their data under that circumstance, please let me know and I will add that knowledge to the write-up at Ofpec. (and credit you)

thanks.