[brailleblaster] Re: More on Embosser Drivers
- From: "Sina Bahram" <sbahram@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Sun, 7 Nov 2010 13:34:01 -0500
It's also trivial to prevent this from occuring by simply optimizing and
obfiscating the code.
Take care,
Sina
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Sunday, November 07, 2010 10:46 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: More on Embosser Drivers
Hello,
I have done a quick look at this, it is very easy to get source code from the
class files. I just ran jad on a class file and its
certainly given me source code which resembles what I put in.
You can find jad at http://www.varaneckas.com/jad.
Michael Whapples
On 07/11/10 04:49, John J. Boyer wrote:
> I've actually used Linux software to decompile classes. The name of
> the software escapes me at the minute. One could go0 further and
> disassemble the byte code. I've tried that with some machine code. The
> reault was instructions with the opcodes and generated symbolic
> addresses, which of course didn't give much information about thge original
> source.
> Reconstructing the source would be a hand operation from then on.
> Also, if the code were optimized, as it usually is for libraries, that
> would make reconnstructing the source all the more difficult. I
> suspect the same is true for Java bytye code.
>
> You would have to be pretty determined to get any proprietary
> information out of a Java class.
>
> John
>
> On Sun, Nov 07, 2010 at 03:50:17AM +0000, Michael Whapples wrote:
>> Regarding how native libraries are included in jar files, I think the
>> approach both for SWT and JNA is that the library will be extracted
>> to a temporary directory where they are then accessed. I am not sure
>> whether they have cleanup code or just rely on the operating system
>> to clean out temporary directories, its probably the latter as it
>> means that there could be times when the library is already extracted
>> so saving start up time as it need not be extracted again. As an
>> additional note for how SWT and JNA work, they will actually look for
>> the library in a specific location before extracting the one in the
>> jar file, this is done so if the application is being run in a
>> restricted environment where files cannot be written to the file
>> system then the administrator (or whoever installs it) can put the library
>> in the required location.
>>
>> Now to the point on decompiling Java class files, I haven't tried it
>> but I am sure I have seen linux software for that purpose and I would
>> imagine some software could get back to java source code.
>>
>> Finally on the point of drivers, I just thought it would be worth
>> allowing driver jars to be added and detected automatically in case
>> there are embosser companies unwilling to let others distribute the files.
>>
>> Michael Whapples
>> On 07/11/10 03:00, John J. Boyer wrote:
>>> BrailleBlaster will probably include drivers for most common embossers.
>>> There will be a combo box for the user to select the one she wants.
>>> New drivers can be added as needed. This is the approach of screen
>>> readers for Braille displays. BrailleBlaster will not have drivers
>>> for displays because they are either driven by screen readers or part of
>>> notetakers.
>>> I like to translate files using liblouisutdml and then read them in
>>> a text editor with my Elba, which has wi-fi, so I get the advantages
>>> of the big machine along with portability.
>>>
>>> It is interesting that compiled C libraries can be included in jar
>>> files. How are these libraries called? I thought they had to be
>>> installed in a specific place. Perhaps it would be possible to
>>> include liblouis and liblouisutdml in a jar file along with the Java
>>> bindings. I am actually planning to have bindings only for
>>> liblouisutdml. It will have enough functionality that BrailleBlaster
>>> need never call liblouis directly.
>>>
>>> I've tried decompiling class files. All I got was the names of
>>> publicv methods and public variables. A more detailed examination of
>>> a class file would reveal the byte code, but this is probably no
>>> easier to understand than the instructions for a physical machine.
>>> So proprietary ingormation inside a class file would probably be quite
>>> secure.
>>>
>>> John
>>>
>>> On Sat, Nov 06, 2010 at 12:28:46PM -0700, Alex Jurgensen wrote:
>>>> Hi,
>>>>
>>>> Firstly, there is a plugin framework for Java. I'll look up the
>>>> name of it, but I am heading out the dorr right now, so that will
>>>> have to wait until I return.
>>>>
>>>> On the matter of standard API's for embossers, I use mine under the
>>>> Common Unix Prinint System, A.K.A.. CUPS. I believe that there will
>>>> be more drivers writen by ONCE for CUPS. I'll look up the link.
>>>>
>>>> Regards,
>>>> Alex,
>>>>
>>>>
>>>> On 2010-11-06, at 11:25 AM, Michael Whapples wrote:
>>>>
>>>>> Dealing with the idea of including C/C++ code in a jar file with
>>>>> java bindings, yes this can be done (examples both being SWT and
>>>>> JNA). Now to would this protect those who want to keep things
>>>>> secret? The jar file itself is simply an archive file and is
>>>>> easily extracted. Now if a user were to do this they would find
>>>>> some java class files (these would be the compiled class files not
>>>>> the source) and a DLL or other shared library file (like for any
>>>>> other compiled C/C++ library). So I believe the C/C++ part would
>>>>> be as protected as they may be now without any java bindings.
>>>>> While the C/C++ code may be as secure, a standard java class file
>>>>> I believe can be decompiled, but this probably wouldn't reveal
>>>>> anything top secret as it could simply use their published C/C++ API and
>>>>> so would be just a mapping between two knowns.
>>>>>
>>>>> One thing this does raise in my mind, if drivers are to be done as
>>>>> described by John, BrailleBlaster would need some way to
>>>>> dynamically detect drivers which are installed (may be some sort
>>>>> of plugin system where the user simply has to drop a jar file in a
>>>>> certain directory then next time they start BrailleBlaster that new
>>>>> embosser will be shown).
>>>>> There may be some frameworks already out there to support such a
>>>>> plugin system.
>>>>>
>>>>> Now I do have a slight question, may be the answer is obvious to
>>>>> those more involved in Braille production, why don't embossers use
>>>>> a standard API, may be even the printer API like the tiger printer does?
>>>>>
>>>>> Michael Whapples
>>>>> On 6 Nov 2010, at 11:26, John J. Boyer wrote:
>>>>>
>>>>>> I think the driver interface and the classes which implement it
>>>>>> should be in a package called org.brailleblaster.drivers The
>>>>>> interface would be called driver.java Each class implementing it
>>>>>> would be named for the embosser which it suppoorts, for example,
>>>>>> Tiger.java Indexd.java Everest.java
>>>>>>
>>>>>> As I mentioned previously, the drivers should be written in Java
>>>>>> or converted from other languages to avoid messing around with
>>>>>> bindings. A manufacturer might chose to protect propritary
>>>>>> information by supplying a driver compiled into a C or C++
>>>>>> library. In this case it woulod be desirable for the manufacturer
>>>>>> to also supply the Java bindings and to incorporate the JNI
>>>>>> portion of the bindings into the library containing the driver.
>>>>>>
>>>>>> Is it possible to put Java code containing proprietary
>>>>>> information into a jar file which can be used by the Java
>>>>>> compiler and the JRE but which the user cannot see inside? That
>>>>>> would make it much easier to get Java drivers from manufacurers.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> --
>>>>>> John J. Boyer; President, Chief Software Developer Abilitiessoft,
>>>>>> Inc.
>>>>>> http://www.abilitiessoft.com
>>>>>> Madison, Wisconsin USA
>>>>>> Developing software for people with disabilities
>>>>>>
>>>>>>
>>>> Alex Jurgensen,
>>>> VoiceOver Trainer,
>>>> ASquared21@xxxxxxxxxxxxxxxxx
>>>>
>>>> Visit us on the web at: www.vipbc.org
>>>>
>>
Other related posts:
