|
|
| Packed files in Allegro 4.9.x |
|
Max Savenkov
Member #4,613
May 2004
|
I understand that Allegro 4.9/5 no longer has its own packfile format/functions, but relies on PhysFS. The trouble is - PhysFS does not seem to support password-protected files, which is bad even for freeware games (sometimes author just does not want to give anyone easy access to all his resources...). So, what does one need to do to protect data archive with Allegro 4.9/5? Or may be I'm just missing something?
|
|
Thomas Fjellstrom
Member #476
June 2000
|
You can encrypt the data yourself if you like. But doing so has dubious value. The password itself must be stored in the binary someplace, so if people want your data, they are going to get it regardless of what you do. -- |
|
LennyLen
Member #5,313
December 2004
|
Does PhysFS work with password protected zip files?
|
|
Arthur Kalliokoski
Second in Command
February 2005
|
The password itself doesn't have to be plaintext. You could have a random string of bytes declared in a rand.c file (perhaps the sprintf()'ed output of rand()), use this rand.c as a module in another program which reads in a plaintext string from a third file and outputs the xor'ed values or whatever to be compiled into the final source file. Then the executable has to xor these two buffers together to get the "password" (possibly hundreds of bytes long). Perhaps the xor'ing could be done one int at a time in the middle of some initialization loop, far from where it's needed. It could still be cracked, but would add another layer of difficulty. They all watch too much MSNBC... they get ideas. |
|
Max Savenkov
Member #4,613
May 2004
|
This is regrettable, since making encrypted resource files is a common task in game development. OK, so I guess I'll have to find some other FS library which supports encryption and wrap it so Allegro could use it. Or write my own, but I'm probably too lazy to do it.
|
|
LennyLen
Member #5,313
December 2004
|
Max Savenkov said: This is regrettable, since making encrypted resource files is a common task in game development. It's becoming far less common however, as most studios have discovered that their attempts at hiding assets are usually undone within days of release.
|
|
Matthew Leverton
Supreme Loser
January 1999
|
It would be trivial to create your own password encryption. 1
2#include <allegro5/allegro.h>
3#include <stdio.h>
4
5const char *password = "allegro";
6const int password_len = 7;
7
8ALLEGRO_FILE_INTERFACE encrypted_io;
9
10/* need to remember these two functions */
11ALLEGRO_FILE *(*stdio_fopen)(const char *path, const char *mode);
12size_t (*stdio_fread)(ALLEGRO_FILE *f, void *ptr, size_t size);
13
14/* open a file using stdio and set the vtable to our interface */
15static ALLEGRO_FILE *eio_fopen(const char *path, const char *mode)
16{
17 ALLEGRO_FILE *f = stdio_fopen(path, mode);
18 f->vtable = &encrypted_io;
19 return f;
20}
21
22/* read the buffer via stdio, and then decrypt it */
23static size_t eio_fread(ALLEGRO_FILE *f, void *ptr, size_t size)
24{
25 int64_t pos = al_ftell(f);
26 size_t bytes_read = stdio_fread(f, ptr, size);
27
28 unsigned char *s = ptr;
29 const unsigned char *e = s + bytes_read;
30
31 while (s < e)
32 {
33 *s++ ^= password[pos++ % password_len];
34 }
35
36 return bytes_read;
37}
38
39int main()
40{
41 ALLEGRO_DISPLAY *display;
42 ALLEGRO_BITMAP *bmp;
43
44 al_init();
45 al_init_image_addon();
46
47 /* set up our super advanced encryption system */
48 memcpy(&encrypted_io, al_get_new_file_interface(), sizeof(ALLEGRO_FILE_INTERFACE));
49 stdio_fopen = encrypted_io.fi_fopen;
50 stdio_fread = encrypted_io.fi_fread;
51 encrypted_io.fi_fopen = eio_fopen;
52 encrypted_io.fi_fread = eio_fread;
53 al_set_new_file_interface(&encrypted_io);
54
55 display = al_create_display(457, 266);
56
57 bmp = al_load_bitmap("encrypted.png");
58 if (bmp)
59 {
60 al_clear_to_color(al_map_rgb(255,255,255));
61 al_draw_bitmap(bmp, 0, 0, 0);
62 al_flip_display();
63 al_rest(5);
64 }
65
66 return 0;
67}
1#include <stdio.h>
2#include <stdlib.h>
3#include <string.h>
4
5const char *password = "allegro";
6
7int main()
8{
9 FILE *fp1 = fopen("input.png", "rb");
10 FILE *fp2 = fopen("encrypted.png", "wb");
11
12 const int len = strlen(password);
13 int i = 0;
14
15 while (!feof(fp1))
16 {
17 int c = fgetc(fp1);
18 if (feof(fp1)) break;
19
20 fputc(c ^ password[i % len], fp2);
21 ++i;
22 }
23
24 fclose(fp2);
25 fclose(fp1);
26 return 0;
27}
Of course this is hardly secure at all, considering that the PNG header is known and that gives away the beginning of the password (or all of it, if it's too short). But nothing is going to be very secure. |
|
Max Savenkov
Member #4,613
May 2004
|
Hmmm, I, actually, don't need VERY secure anything
|
|
Dario ff
Member #10,065
August 2008
|
Max Savenkov said: I just wanted to store Player Profiles for my game in encrypted files so player could not easily edit them (without relying on hard-to-change custom binary format for profiles)
Heh, now you reminded me of a Kyodai Mahjong game where the high-score tables was in a .ini. My father was kind of competitive with it, so I just went and edited the .ini, annoying him with my humanly impossible scores. What I think is, that if your profile is going to be in binary format, you don't really need to encrypt it. People could just copy over a savefile from someone else and have their progress, there's really little point on protecting it. But Matthew already coded it for you, so you can just go with that. TranslatorHack 2010, a human translation chain in a.cc. |
|
Max Savenkov
Member #4,613
May 2004
|
Thing is, I don't want to use binary format for profiles, high score, etc. I'd rather use XML, but encode it. So, yes, I'll probably use what Matthew wrote... or something else.
|
|
Neil Roy
Member #2,229
April 2002
|
I prefer to password protect encrypted pacfiles for my high scores. It works rather well (well enough for the average gamer that will play MY games). I encrypt the password itself in my game to make it difficult to get it via a hex editor or such, then I run a simple function to decrpypt my password and then apply it to the packfile I use to save my high scores with. I don't want players editing the high scores at all, I also don't want anyone getting ahold of my data. Yes, it can be done with some work, but not everyone is going to go through THAT much trouble, and this will stop the majority (if not all) of the people interested in anything I can create. Sucks if you're not going to implement it in Allegro 5. --- |
|
Matthew Leverton
Supreme Loser
January 1999
|
Neil Roy said: Sucks if you're not going to implement it in Allegro 5. If somebody wants to port the A4 pack/data files to A5, then it would probably be added as an official add-on. But adding a password to the core of Allegro makes no sense. You can easily password protect your files. It's trivial to do at the user program level. Attached is a simple proof-of-concept library that is used as follows: xor_fi = create_xor_file_interface("secret password"); al_set_new_file_interface(xor_fi); config = al_create_config(); al_set_config_value(config, "resolution", "width", "640"); al_set_config_value(config, "resolution", "height", "480"); al_save_config_file("test.ini", config); al_destroy_config(config); It sits on top of the current file interface, and should work as long as it supports ftell(). |
|
GullRaDriel
Member #3,861
September 2003
|
Except if you are programming a game for the CIA or equal, don't bother to write password encrypted datafile. It's just a loss of time and my two cents BTW. "Code is like shit - it only smells if it is not yours" |
|
wiseguy
Member #44
April 2000
|
I did something similar for what I'm working on, using the solitaire encryption algorithm. It only works on all text phrases, but I may modify it to handle numbers and other characters as well. Thing is I didn't need anything really secure. I'm sure the same could be done pretty easily when reading and writing to the zipfile. (My program currently encrypts and decrypts before and after sending or receiving over the server/client connection.) WG |
|
|