• All, I am currently in the process of migrating domain registrations. During this time there may be some intermittent outages or slowdowns. Please contact staff if you have any questions.
OpenBOR

OpenBOR 4.0 7556

No permission to download
LOL....

Fair enough... I guess I never shared the code because I didn't want anyone to compromise future PAKS...

Then I guess the answer to that question is NO... OpenBOR has not have plans for locking down PAKS. However, you could still provide a service where you can sell that source code (If you want it, just let me know), fund this website and once a unified build system is in place they can manage it on their own.
 
Then I guess the answer to that question is NO... OpenBOR has not have plans for locking down PAKS.

I'd like to, I just want it to be independent of our (meaning staff) intervention. I was looking at a bit shift cypher of sorts salted from user generated passphrase, but there's obviously some technical hurdles to that.

DC
 
I'd like to, I just want it to be independent of our (meaning staff) intervention. I was looking at a bit shift cypher of sorts salted from user generated passphrase, but there's obviously some technical hurdles to that.

DC
That's what it did originally.... but unless you employ an asynchronous encryption model (Public [read]/Private [write] Keys) it can always be hacked. Asynchronous encryption is the only REAL solution to ensure integrity and have the responsibilities fall under the creator. From a technical perspective it should be feasible, lock and sign the PAK and when read... openbor can unlock with public key and load into memory and work from there (minimizes performance it but makes it vulnerable to memory attacks) or (unlock the data being loaded per call (most secure but comes with a performance hit).

Here is a thought.... maybe I should start a service.... oh wait!!! I'm starting to remember how everyone wanted me to decrypt BonusJZ mod prior to the 1 year expiration.... it was a headache!
 
Last edited:
@SX I made some experiments with the remaining secure pak code. I was able to add some changes in the borpak, which allow me to lock it. There's some security issues yet that require engine changes to be improved, but the concept works and the user can handle it alone easily.

Currently there's other tools to lock paks too, like virtualization using Virtual Box format (some kind of new molebox tool). IMO it would be a lot better to have an official way to lock content instead of requiring third party tools for that.
 
@SX Securepak was not that secure - it was already break and content modified heavily.
There was a Golden Axe game - Golden Axe Myth - which used this pak and, for years, it was secure.

Then come some chinese "modders", cracked it up and things went downhill.

I agree with DC - it would be good to have some tool which doesn't depends on the engine devs to work.
 
hahaha... well like you said it was secure for years but like anything else it can be broken. Really this would require a closed source solution on the engine side and utilize asynchronous cryptography and a new packing structure since there are many of those who are familiar with how the PAK structure is constructed.

I'm actually quite happy that it even lasted that long all things considered.
 
those who are familiar with how the PAK structure is constructed
Exactly, this is the point where I stuck in. It can be certainly improved but we must make several changes on how the engine reads paks.
I added a custom rot13 in the borpak and it's cool, but still breakable without several engine changes.
 
Exactly, this is the point where I stuck in. It can be certainly improved but we must make several changes on how the engine reads paks.
I added a custom rot13 in the borpak and it's cool, but still breakable without several engine changes.
the two file formats would have to co-exist to not break backward compatibility. If I'm not mistake the signature of the file is located right in the beginning and so you could utilize function pointers to reassign the file loading behavior once the magic key has been identified.

That's what I did to support both spk and pak.
 
Last edited:
I'm think the simplest thing to do is to distribute an alternate Packer and Engine. We'd call it "OpenBOR Pro" or some such. The one and ONLY difference is they will have additional (obviously closed source) code to pack and run secure games.

If you want a secure module, then you download the pro versions, pack your game, and distribute it... done. Doing so with the knowledge that pack will not be opened again (so keep your original!). This leaves it completely in the creator's hands, and let's us concentrate on making it , well, secure.

The downside is possible confusion, but good gravy... at this point I am so done capitulating to people who won't bother reading labels.

DC
 
If I'm not mistake the signature of the file is located right in the beginning
Yes, I can confirm it. The change I made in the borpak allows the user to edit the dword before creating the pak.

The point is that some modified versions of the paxplode ignore several steps and unpack no matter what dword is added. We could fix it by changing how the borpak creates a pak's structure, but the engine must be changed too in order to match the same way of reading. However, like you mentioned, it will break the backward compatibility, which makes the DC's solution a good one.

I'm think the simplest thing to do is to distribute an alternate Packer and Engine. We'd call it "OpenBOR Pro" or some such. The one and ONLY difference is they will have additional (obviously closed source) code to pack and run secure games.

If you want a secure module, then you download the pro versions, pack your game, and distribute it... done. Doing so with the knowledge that pack will not be opened again (so keep your original!). This leaves it completely in the creator's hands, and let's us concentrate on making it , well, secure.

The downside is possible confusion, but good gravy... at this point I am so done capitulating to people who won't bother reading labels.

DC
Agreed, IMO this is a good way to go.
 
Agree. If back in 2005.... had I been well versed in cryptography I would have done it differently.... using certificates solves this issue and the pak file itself would be entirely encrypted and no change to the structure would be necessary.
 
Yeah separate pro or whatever version would be nice, but there arent THAT many original mods.... still, nothing really protects these creators from paxplode
 
Back
Top Bottom