Can someone help me port my code from
void * uzFile = unzOpen("zip filename");
to use the unzOpenCurrentFilePassword from minizip ?
I want to protect my zip file with a password.
I tried many times but I failed using it. Thanks
extern int ZEXPORT unzOpenCurrentFilePassword OF((unzFile file,
const char* password));
/*
Open for reading data the current file in the zipfile.
password is a crypting password
If there is no error, the return value is UNZ_OK.
*/
Before you compile zlib, remove the definition of NOUNCRYPT in unzip.c. Then "unzOpenCurrentFilePassword will be enabled".
unzip.c Line 72:
#ifndef NOUNCRYPT
//#define NOUNCRYPT Comment this line, so unzip protected files will be enabled
#endif
Why? Among other things, the definition of NOUNCRYPT causes an absurd return in unzOpenCurrentFilePassword function.
extern int ZEXPORT unzOpenCurrentFile3 (unzFile file, int* method,
int* level, int raw, const char* password)
[...]
# ifndef NOUNCRYPT
char source[12];
# else
if (password != NULL)
return UNZ_PARAMERROR;
# endif
Related
I have ordinrary text file with settings, which is generated by java application. Inside this file, there is a key db.url, which has value db.URL=jdbc\:mysql\://192.168.0.101\:3306/dbuser. I parse this file with QSettings class in QSettings::Native mode, everything is ok, but this db.URL gets messed up if I read it via value() method. Whatever I do (if I transform it into QString or QUrl), I get same result: jdbcmysql//192.,168.0.1013306/user. Why this key gets messed up?? I am using Qt 5.4 on Kubuntu 14.10 with kernel Linux desktop001 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:06:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux. Here is a simple method that wrongly reads value of key:
QString UePOSSesttings::ueReadDbUrl() const
{
// QVariant dbUrl=this->value(UeDefaults::UeDbKeys::KEY_DB_URL);
return this->value(UeDefaults::UeDbKeys::KEY_DB_URL).toString();
}
and constants:
#ifndef UEDEFAULTS
#define UEDEFAULTS
#include <QString>
namespace UeDefaults
{
namespace UeDbKeys
{
static const QString KEY_DB_DRIVER="db.driver";
static const QString KEY_DB_PASSWORD="db.password";
static const QString KEY_DB_URL="db.URL";
static const QString KEY_DB_DRIVER_LIB="db.driverlib";
static const QString KEY_DB_ENGINE="db.engine";
static const QString KEY_DB_USER="db.user";
}
}
#endif // UEDEFAULTS
QSettings clears up the string from unsupported escape sequences, in this case \:. Remove \ slashes before reading the value or don't use QSettings for parsing unsupported file formats.
Perhaps not the most optimal solution but you could processes the settings file to escape all \: before reading it with QSettings.
QFile oldSettings("settings.txt");
oldSettings.open(QIODevice::ReadOnly);
QString data = QString::fromAscii(oldSettings.readAll().constData());
oldSettings.close();
data.replace("\\:", "\\\\:");
QFile newSettings("/tmp/settings.txt");
newSettings.open(QIODevice::WriteOnly);
newSettings.write(data.toAscii(), data.size());
newSettings.close();
I did it:
void UePOSSesttings::ueParseData(const QString& filename)
{
QFile settingsFile(filename);
QString data;
settingsFile.open(QIODevice::ReadOnly);
data=QString::fromLatin1(settingsFile.readAll().constData());
data.replace("\\:",
":");
this->ueSetParsedData(data);
qDebug() << this->ueParsedData();
settingsFile.close();
}
and now I get this url:
db.URL=jdbc:mysql://192.168.0.101:3306/dbuser
which is ok!
I am implementing a simple caeser cipher on WrapFS to store encrypted data and decrypt while reading. For that purpose I made minor changes to wrapfs_read() and wrapfs_write() functions provided in the source code to encrypt and decypt the data. My decryption is working fine, but due to my encryption code I am getting an error on write as follows bash: echo: write error: bad address. Any help regarding handling it would be really appreciated.
void caeser_encrypt(char __user *encrypted, size_t count)
{
int i;
for(i=0;i<(unsigned int)count;i++)
encrypted[i]=encrypted[i]+3;
printk(KERN_INFO "%s",encrypted);
return;
}
static ssize_t wrapfs_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
int err = 0;
struct file *lower_file;
struct dentry *dentry = file->f_path.dentry;
char *encrypted = NULL;
lower_file = wrapfs_lower_file(file);
/*Added by me*/
encrypted=kmalloc(sizeof(buf),GFP_USER);
memcpy(encrypted,buf,count);
printk(KERN_INFO "%d %d",(int)sizeof(buf), (int)count);
caeser_encrypt(encrypted,count);
err = vfs_write(lower_file, encrypted, count, ppos);
/*Added by me*/
//err = vfs_write(lower_file, buf, count, ppos);
/* update our inode times+sizes upon a successful lower write */
if (err >= 0) {
fsstack_copy_inode_size(dentry->d_inode,
lower_file->f_path.dentry->d_inode);
fsstack_copy_attr_times(dentry->d_inode,
lower_file->f_path.dentry->d_inode);
}
/*Added by me*/
kfree(encrypted);
return err;
}
I would say that "const char __user *buf" is user space address and vfs_write expects user space address and you are passing kernel space address to it. Also you cannot directly copy user space address to kernel space address. You can try using copy_from_user and copy_to_user functions. I hope you are aware that caeser cipher is insecure.
I have a program which goes through the directory structure and concatenates the files present in the path to szFile . I have used dirent here to get the directory entries. It is dumping core in the strcat function inside the for loop only in SunOS . It goes through fine in HP and AIX machine .
#include <stdio.h>
#include <string.h>
#include <dirent.h>
#include <limits.h>
#include <sys/types.h>
int main()
{
DIR *pDirHand;
char szFile[1024];
struct dirent pdirent ;
struct dirent *pResult = NULL;
char *sDir = "fullpath"; /* fullpath can be /make/users/path */
strncpy (szFile, sDir, sizeof(szFile)-1);
szFile[sizeof(szFile)-1] = '\0';
if (NULL == (pDirHand = opendir(szFile)))
{
return -1;
}
for(readdir_r(pDirHand, &pdirent, &pResult); pResult != 0;readdir_r(pDirHand, &pdirent, &pResult))
{
FILE *fp;
fp=fopen("debug.log","a+");
strcpy (szFile, sDir);
strcat (szFile, "/");
strcat (szFile, pdirent.d_name);
}
if (pDirHand) closedir (pDirHand);
return 0;
}
I dont have any files currently in the path that I assign to sDir. It has "." and ".." directory entries in it but I get a core dump in the line
strcat (szFile, pdirent.d_name);
I had used dbx to find out the value of szFile , during the second iteration the value is exceeding the memory allocated for it . The value comes as
"fullpath/../fullpath/../fullpath/../fullpath/../fullpath/..fullpath/..fullpath/../../../../../../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/..fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/../fullpath/.." ...
I have tried using strlcat , but the concatinated value of szFile is not coming properly.
Anybody faced this problem in SunOS or can help ?
My code
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
void getData(short int *number, char *string)
{
printf("\nPlease enter a number greater than zero: ");
scanf("%hd", number);
printf("Please enter a character string: ");
scanf("%s", string);
}
void echoPair(short int *number, char *string)
{
printf("Number: %hd Character(s): %s\n", *number, string);
}
int main()
{
short int *number = 0;
char string[32] = {0};
printf("This program will ask you to enter a number greater than zero and \na character string with less than 32 characters \ninput.");
getData(&number, &string);
echoPair(&number, &string);
return(0);
}
The code works fine, but I receive these compiler warnings
warning: passing argument 1 of ‘getData’ from incompatible pointer type
warning: passing argument 2 of ‘getData’ from incompatible pointer type
warning: passing argument 1 of ‘echoPair’ from incompatible pointer type
warning: passing argument 2 of ‘echoPair’ from incompatible pointer type
If do this
getData(number, string);
echoPair(number, string);
The warnings go away, but the program gets a "Segmentation fault: 11" after I enter the first number in the getData function.
Anyone know how to remove the warnings and keep the program working?
Thanks
There are a number of problems here.
First, the line:
short int *number = 0;
should be:
short int number = 0;
Because you used the former, it gave you a null pointer to a short. That's not what you want since the first dereference of that beast will probably crash your code (or, worse, not crash your code but cause strange behaviour).
Secondly, you don't need to pass in the address of strings, they automatically decay to an address, so change:
getData (&number, &string);
echoPair (&number, &string);
to:
getData (&number, string);
echoPair (&number, string); // but see last point below.
And, last of all, you don't need to pass in the address just to print it, you can just pass in the value, hence:
echoPair (&number, &string);
becomes:
echoPair (number, string);
As a whole, I think what you want is:
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
void getData(short int *number, char *string) {
printf("\nPlease enter a number greater than zero: ");
scanf("%hd", number);
printf("Please enter a character string: ");
scanf("%s", string);
}
void echoPair(short int number, char *string) {
printf("Number: %hd Character(s): %s\n", number, string);
}
int main (void) {
short int number = 0;
char string[32] = {0};
printf("Blah blah ...");
getData(&number, string);
echoPair(number, string);
return(0);
}
As an aside, you don't ever want to see unbounded string scans like:
scanf ("%s", string);
in production-ready code. It's a buffer overflow vulnerability waiting to happen, since you don't control what the user will input. In your particular case, the user entering more than (about) 30 characters may cause all sorts of weird behaviour.
The scanf function is for scanning formatted text, and there's not many things more unformatted than user input :-)
If you want a robust user input function, see here.
You declare the local variable number as a pointer to short int. You then pass a pointer to it to getData and echoPair. So you're passing a pointer to a pointer, which is the wrong type. Probably you want to declare number as just a short int rather than a pointer.
#include <Windows.h>
void memfrob(void * s, size_t n)
{
char *p = (char *) s;
while (n-- > 0)
*p++ ^= 42;
}
int main()
{
memfrob("C:\\Program Files\\***\***\\***\***\\***", 30344);
}
There's my code. If you can't tell, I'm not sure what I'm doing. I've Googled for about an hour and I haven't seen an example of how to use memfrob(), which is probably why I'm so lost. I'm trying to pass it the name of the file and then the size of the file in bytes, but my program just crashes.
Alright, this is what I have right now:
#include <Windows.h>
#include <stdio.h>
int count = 0;
FILE* pFile = 0;
long Size = 0;
void *memfrob(void * s, size_t n)
{
char *p = (char *) s;
while (n-- > 0)
*p++ ^= 42;
return s;
}
int main()
{
fopen_s(&pFile, "C:\\Program Files\\CCP\\EVE\\lib\\corelib\\nasty.pyj", "r+");
fseek(pFile, 0, SEEK_END);
Size = ftell(pFile);
char *buffer = (char*)malloc(Size);
memset(buffer, 0, Size);
fread(buffer, Size, 1, pFile);
fclose(pFile);
memfrob(buffer, Size);
fopen_s(&pFile, "C:\\Program Files\\CCP\\EVE\\lib\\corelib\\nasty.pyj", "w+");
fwrite(buffer, Size, 1, pFile);
fclose(pFile);
}
In my debugger, it seems that fread is not writing anything to buffer, and my ending file is just 2A over and over, which is 00 xor'd with 42. So can I get another hint?
You need to pass memfrob a piece of memory containing the contents of the file, rather than the name of the file. It's crashing because you're passing in a buffer of read-only memory, and then trying to modify it.
Investigate the open and read I/O functions, or alternatively fopen and fread. Your mainline should look something like:
int main() {
// open file
// find size of file
// allocate buffer of that size
// read contents of file into the buffer
// close the file
// call memfrob on the buffer
// do what you want with the file
// free the buffer
}
Well, several things are wrong here.
The minor problem is that you're passing it the location of the file and not the file itself. Read up on how to do file I/O in C (this being a pretty good link).
The real problem is that you seem to think this is encryption. This doesn't really encrypt your file from anything but the most trivial security issues (such as someone randomly opening your file).