How to read a password protected zip file
I have even managed to load files for irrklang from my archives, I mean sound files 
well, to store the password as a complete string isn't a good idea (obviously)... 
when I use passwords then I build up the password along the source code and I don't use obvious names...
example (the password shall be "ABCDEFG"):
I know this isn't realy save, too...
but it's more secure than storing the whole word at once...
this way you won't see the password with an hex editor, you'll have to trace the memory to get it and as it's just temporary created and deleted right after usage it's also not too easy to get the password...
when I use passwords then I build up the password along the source code and I don't use obvious names...
example (the password shall be "ABCDEFG"):
Code: Select all
stringc entityName("A"); // don't name the string "password" ;))
... some other code lines ...
entityName += "BC";
... some other code lines ...
entityName += "D";
... some other code lines ...
entityName += "E";
... some other code lines ...
entityName += "FG";
... some other code lines ...
// use the password now...
entityName = ""; // delete the password after usebut it's more secure than storing the whole word at once...
this way you won't see the password with an hex editor, you'll have to trace the memory to get it and as it's just temporary created and deleted right after usage it's also not too easy to get the password...
while(!asleep) sheep++;
IrrExtensions:
http://abusoft.g0dsoft.com
try Stendhal a MORPG written in Java
IrrExtensions:
http://abusoft.g0dsoft.com
try Stendhal a MORPG written in Java
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
The idea is to give all users complaining about lack of encryption support the ability to do what they think is nice. And the rest simply should think about it and do what they always did. Anyway, it's a nice feature that we will also extend to arbitrary encryption functions etc.
Acki: Debuggers can easily trace memory areas, so you just need to check changes to the address of the pw field. So your code will only prohibit some more script kiddies to access the zip file. Although exactly that's the idea I had in mind when making the pw member public. Another idea would be to define a salt value in IrrCompileConfig, and XOR the pw with that value. But I guess everyone needs to define his own level of security and obscurity.
Acki: Debuggers can easily trace memory areas, so you just need to check changes to the address of the pw field. So your code will only prohibit some more script kiddies to access the zip file. Although exactly that's the idea I had in mind when making the pw member public. Another idea would be to define a salt value in IrrCompileConfig, and XOR the pw with that value. But I guess everyone needs to define his own level of security and obscurity.
You see the line because you have the source code in your computer and ollydbg reads the PDB, if you give the exe without the PDB to other user it can't see the line, however the password will show in the dissasembly.Bate wrote:Isn't that a little too obvious?
Also, I don't understand why the exact source code is visible since the test exe was compiled in release mode (VC++ 2008) with all debug options disabled.
Sorry to bump this thread, but Im also seeking peoples opinion on this.
It is possible to protect the assests 100% problem is almost always there is a way to reveal the keys due to some exploit than to go in and rob the comapny safe
Ackis trick is quite good, but may be optimised by the compiler at compile time and the result string is still stored in the excutable... another way would be to do his trick with the variables assigned volatile so the compiler doesnt mess with the optimisation and has to do it in realtime.
Still anyone can use a mem dumper or diasm and work out the sequence of comamnds to generate the code.
Anyone have any ideas how to foolproof this problem? Hashing would be the same as acki's solution except it would be one way... meaning even if you have the hash you cant make the password but... the zip file needs the password to be decoded...
It is possible to protect the assests 100% problem is almost always there is a way to reveal the keys due to some exploit than to go in and rob the comapny safe
Ackis trick is quite good, but may be optimised by the compiler at compile time and the result string is still stored in the excutable... another way would be to do his trick with the variables assigned volatile so the compiler doesnt mess with the optimisation and has to do it in realtime.
Still anyone can use a mem dumper or diasm and work out the sequence of comamnds to generate the code.
Anyone have any ideas how to foolproof this problem? Hashing would be the same as acki's solution except it would be one way... meaning even if you have the hash you cant make the password but... the zip file needs the password to be decoded...
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
-
Lonesome Ducky
- Competition winner
- Posts: 1123
- Joined: Sun Jun 10, 2007 11:14 pm
If any of us here had a foolproof way of protecting assets, then we'd be rich by now. There's ways around everything. Even if you encrypt your meshes or textures in the most secure way possible, they could still be lifted from the graphics card. It's really only helpful to secure them in a small amount, so those with limited knowledge can't get them. But if someone knows what they're doing and they want it, they have plenty of ways of getting it.
-
Radikalizm
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
To protect my assets I use a home-made binary format which tries to obscure the data to anyone who does an attempt to parse the file on his/her own
I never use any form of password protection or hard encryption
To prevent people from modding my assets I use a simple magic number system and info about the file in the file header (which does not give away any info at all about the data it's storing), so the engine can do calculations about what it can expect about the data in the file
If this data does not match up with what the engine actually reads, the file will be ignored
I've let some people at it, and the conclusion was that it's pretty damn hard to get the engine to accept any external changes at all, let alone complex mods
This does not prevent people from hacking my asset files, modding them, or stealing information from them tho, it just makes it a lot harder so the little script kiddies stay away from it
I never use any form of password protection or hard encryption
To prevent people from modding my assets I use a simple magic number system and info about the file in the file header (which does not give away any info at all about the data it's storing), so the engine can do calculations about what it can expect about the data in the file
If this data does not match up with what the engine actually reads, the file will be ignored
I've let some people at it, and the conclusion was that it's pretty damn hard to get the engine to accept any external changes at all, let alone complex mods
This does not prevent people from hacking my asset files, modding them, or stealing information from them tho, it just makes it a lot harder so the little script kiddies stay away from it
