View Full Version : Exchanging data between plugins
17th July 2005, 19:25
I want to create plugin, which will be able to decode encrypted music files(Mp3,Ogg...etc.) in realtime. Those files will be encrypted using XOR algorythm and will have an extension SAC. I am a newbie in winamp development and the thing is, I don't know which type of plugin should it be...
Should it be an input plugin or general purpose plugin??
I want it to work like this:
I will add to the playlist a *.sac file (Safe Audio Codec - my own name for this kind of files:) ). The plugin should recognize what type of music format it is (an mp3 or ogg or...etc.) using a first bit of my *.sac file. After recognision it will start the realtime decoding process sending decoded data to build-in input plugin (eg. to in_vorbis.dll), to retrieve info from tags and to enable winamp to play the encrypted file. So the winamp will be able to play the audio stream decoded from *.sac file, which is a simple music file but encrypted with XOR.
As I said: The thing is, I don't now what sort of plugin should it be. The winamp should recognize the *.sac file, so it probably should be done by an input plugin, but on the other side it should send data to other input plugins(responsible for decoding audio stream in specified audio formats) in realtime. The question is - Will it be possible to do using input plugin only??
And the second thing is - Is it possible to send data from one input plugin to another input plugin?? And if it is, can someone tell me, where can I find info for doing it...?
1st August 2005, 22:18
Ok, I have found solution for my problem mentioned above, but now I came to another problem. Can anybody tell me, if there is possibility to write to memory page which is marked as READ_ONLY?? Is there any WINAPI function which does this?? I tried with WriteProcessMemory, but it fails to write READ_ONLY memory pages. In Jefrey Richter's "Programming aplications for Microsoft Windows" book is said, that WriteProcessMemory function shall write with no problem to READ_ONLY memory pages, but it doesn't!!! Can somebody help me? Please...
1st August 2005, 22:36
I have to say im kinda confused as to what protection your file format is giving your files. a simple XOR isnt much in the way of protection, and, like any encoding system, you have to give away the decoding method to allow playback (hello drm).
I'm not much of a windows coder, so you'll have to just make do until someone else comes along, but, you could just write an input plugin that fakes the winamp plugin api and load other input plugins as required, basically proxying those functions to the real winamp. I dont believe you will have any memory issues that way.
2nd August 2005, 09:02
Thanks CraigF for info.:) Fortunately I have sold my problem yesterday using VirtualProtect function. I needed this to superseed an original WINAPI ReadFile function with my own function, which automaticaly decrypt encrypted data from disk. Everything works fine when reading file tag, but when playing I receive AccesViolation(this is very strange - can someone tell me the difference in reading file from disk when playing and reading a tag?).
And one word for the XOR algorythm - if key file is as big as file being encrypted, there is no way to decrypt such file without having a key file - this algorythm is immune to speed of processor;) And thanks to that - this is the best way to encrypt files, because nobody without key file will be able to decrypt protected files in that way;)
4th August 2005, 09:41
Hello! I will no longer need info - I managed to create what I wanted:D Now I can safely listen to my music knowing, that nobody else will be able to listen to my music and nobody will be able to prove, that I listen to stolen music:D Unless someone finds my Key file;) Thanks to CraigF and others, who read my post and wanted to help me;)
Best regards to all Developers!!!:)
4th August 2005, 14:56
VirtualProtect can be used to change the Read/Write/Execute settings on pages in memory. See:
XOR is not a good encryption method. Obviously with a long enough key length, ANYTHING is a good encryption method. But with short key length (<512 bytes), and a few files to test with and the key could be cracked. MP3's and other file types have "known" data at certain locations (and usually on intervals) which means that the key bytes that line up with those locations can be cracked trivially. Given enough files, eventually all byte locations will line up. An encryption method that deals with more than one byte at once won't have this problem =)
But really the whole thing could be cracked in one quick step if you had both the source (un-"encrypted") and the destination ("encrypted") file.
In order to use the other input plugins, you'd have to have a physical file somewhere for the input plugin to read. Possibly a memory-mapped file.
Some plugins export functions to do decoding on passed bytes (rather than files) but it is not guaranteed to be present on every plugin (not even all the Nullsoft-written ones).
4th August 2005, 15:12
not including the issue that you have the key in the same location as the encrypted content.
7th August 2005, 14:36
I used API hijacking things to overload ReadFile function and now it works perfectly with every input plugin;) I just exchange the original function address in IMPORT ADDRESS TABLE of the plugin with my own ReadFile function from my GEN plugin;) So transferring data between plugins is now useless.
Thanks Benski for info, you are right, but my key is 200MB long and I have it on a CD which is always in my pocket;) Don't you think, that so big key file will be enough to make decryption of encrypted files impossible? And firstly, if someone wants to decrypt a known part of files would have to know the encryption algorythm. And to be honest, every my file is encrypted using different part of my key file, so every file is encrypted like using different key(it stores a starting possition of key file within encrypted file). Don't you all guys think that this will be impossible to decrypt??
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.