First Question: Say I have a random Base64 encoded string. Is it possible to read each character on the string and convert each character to a frequency/sound and then same the string as a sound?
Second Question: Is it possible to do the opposite? How would I take a sound that was created above and convert back to a base64 string?
If someone clicked no the audio encrypted file it would just be noise.
Yes, it's possible and actually being used, for example here: http://arstechnica.com/tech-policy/2015/11/beware-of-ads-that-use-inaudible-sound-to-link-your-phone-tv-tablet-and-pc/
A Perl script for this is beyond a single answer, but there are many Sound-related modules on CPAN: http://search.cpan.org/search?query=sound&mode=all You'll probably need some time for research, but it should be more or less easy to build.
Related
I am trying to printing TID FROM ZPL COMMANDS
getting JJL179464
can anyone please tell me
what is this character
To partially answer your question:
Are you reading an ASCII encoded data? Because your result: "JJL179464" does not look like a valid RFID tag data, unless it is in ASCII. Data encoded in RFID tags are encoded in binary. Depending on reader settings, the data can be outputed in binary, hexadecimal or ASCII format. Judging by the first three symbols "JJL", your reader is set to output ASCII data, or there is an error in your code.
Try to answer us the following questions:
What are you trying to achieve?
Provide us your code. (whole, structured)
What device are you using to read the RFID tag?
Provide us the settings of your reading device. (unless they are a part of the code)
Do you know the data content of the RFID tag you are trying to read? That means, can you validate that the reading was successful?
Edit:
Thank you for your code:
^XA
^FN1^RFR,H,0,12,2^FS^FH_^HV1,256^FS
^XZ
It seems that there could be several issues in your code.
Firstly, your ^HV command is incomplete. It is missing 3 parameters. The first one (third parameter) sets the data prefix. Next one data termination. And the last one specifies when to return data. You should include all of them in the ^HV command.
There is already a good example how the ^HV command needs to be set:
^RFR,^FN1,^HV1 not sending output to computer
The second issue, at least I think that it is an issue but I don't have the means to verify it, is that you are using ^FH_ command. There are no hexadecimal values for encoding special characters in your code, so there is no point in using it. So I would try to omit it.
Also, I am not sure about the order of commands. The ^FN1 command should be after ^RFR and before ^FS commands.
Try this code:
^XA
^RFR,H,0,12,2^FN1^FS^HV1,256,HEADER,TERMINATION,L^FS
^XZ
That should give you output in format:
HEADERhexadecimaldataTERMINATION
It is a little bit hard to read, but if it will work, then you might proceed to format it nicely.
The words HEADER and TERMINATION serve as prefix and postfix of data from ^RFR command. So if this will work you can replace them with brackets or whatever suits your needs.
I am also concerned about 2 things:
The number of bytes to read - 12. Usually it is 8, but it varies depending on the type of RFID tag and the data format. I don't say that it is a mistake, just unsual to me.
The last parameter in ^HV1 command may be "F" instead of "L". The "F" is default value and it seems that in your case it was working with it. At least you got some output, so maybe it should be "F". But try it with "L" to get a response for each label. "F" means getting a response after the entire job is done.
I hope this will work. Currently we are in lockdown and I don't have the means to verify this on real devices. But theoreticaly it should help.
Please let me know the results.
For my project I'm experimenting with disguising the content of a file and thought a good way to do this would be to change the document signature (magic numbers). I think in order to do this I need to change the starting x bytes of the hex but am not sure if this is possible? I've tried looking at the file I want to change in various hex viewers such as autopsy but it strips back all the metadata and only shows the content of that file and the corresponding hex. My question is it possible to change the signature and if so what is the best way to go about it? Any program recommendations?
I'd like to create a bash script to encrypt my personal (text) files, and decrypt them when I need them.
The encryption method I want is, to convert all ASCII characters to hex, then add a value, and convert back to ASCII.
The value to add should be the hex value of a certain character in the file - based on it's position, so it would vary depending on what character happens to be there.
I know next to nothing about bash scripting and about Linux at all for that matter, can anyone please help me?
Unless you trying to learn the history of cryptography forget about this. Anyone with limited knowledge of cryptography will break your code in minutes. A determined hacker will break this in seconds (using frequency analysis of single letters, doublets and triplets).
For encryption (approach you described can hardly be called encryption. It is rather cipher), use stable, proven algorithms (AES, 3DES, TwoFish, Serpent) and tools, such as GPG, TrueCrypt.
In ruby how to check a string is an actural string or a blob data such as image, from the data type of view they are ruby string, but really their contents are very different since one is literal string, the other is blob data such as image.
Could anyone provide some clue for me? Thank you in advance.
Bytes are bytes. There is no way to declare that something isn't file data. It'd be fairly easy to construct a valid file in many formats consisting only of printable ASCII. Especially when dealing with Unicode, you're in very murky territory. If possible, I'd suggest modifying the method so that it takes two parameters... use one for passing text and the other for binary data.
One thing you might do is look at the length of the string. Most image formats are at least 500-600 bytes even for a tiny image, and while this is by no means an accurate test, if you get passed, say, a 20k string, it's probably an image. If it were text, it would be quite a bit (Like a quarter of a typical novel, or thereabouts)
Files like images or sound files have defined blocks that can be "sniffed". Wotsit.org has a lot of info about the key bytes and ways to determine what the files are. By looking at those byte offsets in your data you could figure it out.
Another way way is to use some "magic", which is code to sniff key-bytes or byte-types in a file to try to figure out what its type is. *nix systems have it built in via the file command. Do a man file or man magic for more info or check Wikipedia's article on Magic numbers in files.
Ruby Filemagic uses the same technique but is based on GNU's libmagic.
What would constitute a string? Are you expecting simple ASCII? UTF-8? Or text encoded some other way?
If you know you're going to get ASCII text or a blob then you can just spin through the first n bytes and see if anything has the eight bit set, that would tell you that you have binary. OTOH, not finding anything wouldn't guarantee that you had text.
If you're going to get UTF-8 Unicode then you'd do the same thing but look for invalid UTF-8 sequences. Of course, the same caveats apply.
You could scan the first n bytes for anything between 0x00 and 0x20. If you find any bytes that low then you probably have a binary blob of some sort. But maybe not.
As Tyler Eaves said: bytes are bytes. You're starting with a bunch of bytes and trying to find an interpretation of them that makes sense.
Your best bet is to make the caller supply the expected interpretation or take Greg's advice and use a magic number library.
Is there a good way to see what format an image is, without having to read the entire file into memory?
Obviously this would vary from format to format (I'm particularly interested in TIFF files) but what sort of procedure would be useful to determine what kind of image format a file is without having to read through the entire file?
BONUS: What if the image is a Base64-encoded string? Any reliable way to infer it before decoding it?
Most image file formats have unique bytes at the start. The unix file command looks at the start of the file to see what type of data it contains. See the Wikipedia article on Magic numbers in files and magicdb.org.
Sure there is. Like the others have mentioned, most images start with some sort of 'Magic', which will always translate to some sort of Base64 data. The following are a couple examples:
A Bitmap will start with Qk3
A Jpeg will start with /9j/
A GIF will start with R0l (That's a zero as the second char).
And so on. It's not hard to take the different image types and figure out what they encode to. Just be careful, as some have more than one piece of magic, so you need to account for them in your B64 'translation code'.
Either file on the *nix command-line or reading the initial bytes of the file. Most files come with a unique header in the first few bytes. For example, TIFF's header looks something like this: 0x00000000: 4949 2a00 0800 0000
For more information on the TIFF file format specifically if you'd like to know what those bytes stand for, go here.
TIFFs will begin with either II or MM (Intel byte ordering or Motorolla).
The TIFF 6 specification can be downloaded here and isn't too hard to follow