I have to read the eiss table in the elementary stream. How to read the elementary stream and get access to the data.Are there any API's available in DVB , javatv or ocap
Do you have a standard that defines the format of the data you are trying to read? Something like the ISO/IEC 13818-1 for the Transport Stream and Packetized Elementary Stream. If you do, you can find out exactly how to read the data and what it means. If that is not what you are asking, please be more specific on your question.
There are a couple open source projects related to DVB that I know of:
TSFileSource
MediaPortal
Also possibly of use, but I'm not sure how open the source is:
DVBCore
Note, I've never used any of these personally, so I'm not sure how useful they will be, especially at the elementary stream level. It could be starting point though.
You might also check Project-X.
Related
By using Wireshark, I want to read the conversation between my machine (using MetaTrader) and the Meta trader server. It's a TCP conversation but unfortunately I couldn't decode the binary parsed (I tried base64 decode and others things by playing with hex but nothing worked).
Any way/idea to decode this conversation ?
Big thanks in advance for your time/reply
Respectfully
It's almost certainly going to be impossible without going to extreme measures requiring deep knowledge. Unless the protocol was designed by a complete imbecile, the information will be encrypted so just trying to decode it by observation is extremely unlikely to have any hope of working at all.
i'm a novice and trying the security shepard project where you have to pass challenges. https://www.owasp.org/index.php/OWASP_Security_Shepherd
I did all of the challenges but one that i have a really a hard time with.
To complete this challenge you have to find the key to an encryption method.
They just give you an application that can decrypt encrypted text.
IAAAAEkQBhEVBwpDHAFJGhYHSBYEGgocAw== gives This crypto is not strong.
Unlike other challenges there is no information in the source code.
I don't understand how I'm supposed to proceed.
Thanks
Instead of trying to find the algo, just try to find the algos which are most unlikely to be possible. for a instant, this is not a classic mono-alphabetic or key-less transposition cipher. On the other hand compare input and output bit sizes. Narrow down your possibilities like that and it will helps you to decide which cryptanalysis method to be used.
This may be not the perfect approach, but sure it's a start.
I'm looking for an thorough explanation of how data is encoded into qr codes. The explanation should be specific enough that one could encode a qr code manually (as by drawing)
The complete specificion is available from ISO, as ISO/IEC 18004:2006. It is not free. You can find some partial information on the internet, but not enough to create an encoding process. If you really need the detail, buy the spec.
I can tell you that the process is far too complex to carry out by hand -- the Reed-Solomon error correction calculation alone would take days and you'd not get it right :)
zxing has a complete QR code encoder implementation which may show you enough of how the process is carried out for your purpose.
I want to write an application that removes data from a hard drive. Are there any standards that I need to adhere to which will ensure that my software removes at least the bare minimum, or should I just use off the shelf software? If so any advice?
I think any "standard" you may encounter won't be any less science fiction or science mysticism than anything you come up with yourself. Basically, as long as you physically overwrite the data (even just once), there's no commercial forensic service that - even in the face of any amount of money you throw at them - will claim to be able to recover your data.
(Any "overwrite 35 times with rotating bit patterns" advice may have been true for coarsely spaced magnetic tapes in the 1970s, but it is entirely irrelevant for contemporary hard disks).
The far more important problem you have to solve is how to overwrite data physically. This is essentially impossible through any sort of application or even OS programming, and you'll have to find a way to talk to the hardware properly and get a reliable confirmation that the location you intended to write to has indeed be written to, and that there aren't any relocations of the clusters in question to other parts of the disk that might leak the data.
So in essence this is a very low-level question that'll probably have you pouring over your hard disk manufacturer's manuals quite a bit if you want a genuine solution.
Please define "data removal". Is this scrubbing in order to make undeletions impossible; or simply deletion of data ?
It is common to write over a file several times with a random bitpattern, if one wants to make sure it cannot be recovered. Due to the analog nature of the magnetic bit patterns, it might be possible to recover overwritten data in some circumstances.
Under all circumstances a normal file system delete operation will be revertable in most cases. When you delete a file (using a normal file system delete operation), you remove the file allocation table entry, not the data.
There are standards... see http://en.wikipedia.org/wiki/Data_erasure
You don't give any details so it is hard to tell whether they apply to your situation... Deleting a file with OS built-in file deletion can be almost always reverted... OTOH formatting a drive (NOT quick format) is usually ok except when you deal with sensitive data (like data from clients, patients, finance etc. or some security relevant stuff) then the above mentioned standards which usually use differents amounts/rounds/patterns of overwriting the data so make it nearly impossible to revert the deletion... in really really sensitive cases you first use the best of these methods, then format the drive, then use that method again and then destroy the drive physically (which in fact means real destruction, not only removing the electronics or similar!).
The best way to avoid all this hassle is to plan for this kind of thing and to use strong proven full-disk-encryption (with a key NOT stored on the drive electronics or media!)... this way you can easily just format the drive (NOT quick) and then sell it for example... since any strong encryption will look like "random data" is (if implemented correctly) absolutely useless without the key(s).
I want to ask for a mature model to do this.
Suppose I want to deliver a program and a sensitive data file to user. The program is able to read any data stored in the data file, but user is not allowd to easly break the data file. The data file will be encrypted by standard algorithm such as AES. Now, the problem turns to how to manage the key. Putting the key in the program seems to be a bad idea, but what else I can do? Apparently I can't give the key to user directly.
There is no way to do this securely, ie. to really prevent the user from reading the data. As long as they have the data and they have the program that can read it a competent disassembler will be able to figure out how the program reads it and do the same thing. Or, even easier, they could let the program do it and then get the decrypted version out of its memory.
Having said that, if you just want to prevent the average user from doing it, hardcoding the key in your source code should be fine. :) Just be realistic about the level of protection this provides.
Does it have to be pure software? If not, you could look at a solution which does decryption and storage of the key on a hardware device, e.g. a USB dongle.
You can also potentially prevent the whole problem by having your software retireve the data from a web-service instead of a data file. In this case you can control access to the data much more tightly (i.e. who gets how much of what and when). This might or might not work for your application.
Otherwise as others pointed out, there is no known good pure software solution.
There is no 100% safe solution to this because at some point you have to have the key loaded into memory so that de/encryption can take place and a savvy-enough hacker will be able to capture it. The best you can do is to make it very difficult to capture and to mitigate exposure to data (by limiting access as much as possible) if the key is compromised.
As far as how to make it safer... you could have a combined key that is made up of something stored in the program and something derived from the user's passcode?
Is your perceived user determined? are they skilled enough to do reverse the application or the key? If the user is considered to just be a generic desktop user you probably could implement a partial key using some general encryption just to make the key non obvious, beyond that a determined individual will be able to reverse must simple means of encrypting keys and data.
A DVD John conundrum, eh? Why is having a key in the program bad? You could have a super-obscured function which computes it reliably once. Someone with disassembler and debugger can break your key given enough time, IMO.