Kindle input event device file names can CHANGE.

[ixtab]

Has this really happened, i.e. has that backdoor really been in the wild?

I read about it before, and some quick search came up with this. However I always thought that this was some proof-of-concept, not that it ever went into "production". Do you have some references for the US Army thing?

[geekmaster]

Originally Posted by ixtab

Has this really happened, i.e. has that backdoor really been in the wild?

I read about it before, and some quick search came up with this. However I always thought that this was some proof-of-concept, not that it ever went into "production". Do you have some references for the US Army thing?

All I can find now is a statement that the hacked version of the compiler was never publicly released. This is contrary to what I read before (somewhere on the internet). As we know, information on the internet tends to not be there when you need it, but lasts forever if it is personally embarrassing. What I previously read may have been exaggerated, especially the part about the military, and my memory is not as good as it was when I was younger. But it is still a good story, and there are newer better hacks these days, like the Stuxnet variants the bad guys are sending "back at us".

EDIT: According to this, it was the US Navy, and it was done with their knowledge as part of a research project: http://books.google.com/books?id=_-1jwRwNaEoC&pg=PA378

[geekmaster]

And more misleading info: http://all.net/books/iw/iwardoc.html

Here is an excerpt:

The Thompson `C' compiler designed for the NSA with an embedded login attack is a classic. This early Unix compiler was designed to allow Thompson to login to any Unix system, regardless of changes to the password file, by recognizing and placing a Trojan horse in the login program at compile-time. In addition, the C-compiler was set to propagate this bug in itself whenever it was compiled. Please note that virtually every existing C compiler was compiled either directly or indirectly by a Thompson C compiler, and that bug could be present in Unix systems currently being fielded.

[geekmaster]

Originally Posted by ixtab

Some of the event devices (unfortunately not all, and probably not those that you want ) also have symbolic names:

[root@kindle input]# ls -la
drwxr-xr-x    3 root     root           160 Mar 10 18:15 .
drwxr-xr-x   16 root     root          1120 Mar 11 15:15 ..
drwxr-xr-x    2 root     root           100 Mar 10 18:15 by-path
crw-r-----    1 root     root       13,  64 Mar 10 18:15 event0
crw-r-----    1 root     root       13,  65 Mar 10 18:15 event1
crw-r-----    1 root     root       13,  66 Mar 10 18:15 event2
crw-r-----    1 root     root       13,  67 Mar 10 18:15 event3
crw-r-----    1 root     root       13,  68 Mar 10 18:15 event4
[root@kindle input]# ls -la by-path/
drwxr-xr-x    2 root     root           100 Mar 10 18:15 .
drwxr-xr-x    3 root     root           160 Mar 10 18:15 ..
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-soc-audio.1-event -> ../event1
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-whitney-button-event -> ../event2
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-zforce.0-event -> ../event4

Still, that would mean only figuring out what the remaining two are, instead of guessing what all 5 are.

Except when I try to repeat your steps in diags mode, I cannot figure out how to do the second step:

[root@kindle input]# ls -la
drwxr-xr-x    2 root     root           160 Jan 12 19:02 .
drwxr-xr-x   13 root     root          1020 Jan 12 19:02 ..
crw-rw----    1 root     root       13,  64 Jan 12 19:02 event0
crw-rw----    1 root     root       13,  65 Jan 12 19:02 event1
crw-rw----    1 root     root       13,  66 Jan 12 19:02 event2
crw-rw----    1 root     root       13,  67 Jan 12 19:02 event3
crw-rw----    1 root     root       13,  68 Jan 12 19:02 event4
crw-rw----    1 root     root       13,  69 Jan 12 19:02 event5
[root@kindle input]#

And not only is the z-force touchscreen device using a different event# in diags, and the by-path folder is missing, but there is even an extra event# in diags!

[knc1]

Names of devices in the sub-tree of /dev may and often are, maintained by udev rules (/etc/udev/**).

Names of devices in the sub-tree of /sys are set in (are part of) the driver code.

So for a "fixed", "primary" information source, try using /sys/class/input/**

For example, "what is event0?"

cd /sys/class/input
cd event0
cd device
ls -l

The /sys sub-tree is a nest of symbolic links giving you many ways to reach the information desired.

One quick way, get the Major:Minor number of the devices, then use /sys/dev/{block,char} as appropriate to reach the information about it.

The since this tree is hard-coded in the driver, it will not change while the driver is loaded. It will (should) disappear if the driver is unloaded.

(something to keep in mind when unloading a g_* module and loading a different g_* module for the same device)

[geekmaster]

I am currently getting the path to the zforce events this way:

T=$(for i in /dev/input/event*;do evtest info $i|grep zforce>/dev/null&&echo $i&&break;done)


If I change it to use your suggestion, it makes the command line longer, but no longer requires calling the built-in evtest program:

T=$(for i in /sys/class/input/event*;do grep zforce $i/device/name>/dev/null&&echo $i&&break;done)

I then use it like this:

script -c "hexdump $T" /dev/null | while...

The script command forces unbuffered STDOUT so I can sense touches immediately instead of waiting for enough extra touch data to trigger a full buffer. It is annoying to need to press an onscreen keyboard button multiple times to get any action, then have those multiple touches come out in a batch.

The complication is things in a piped while loop run in a separate process, and when my "Exit" button is touched in the inner do loop, an "exit" or "return" command only acts like a break, exiting only to the done. Setting DONE=1 to break the while (while [[ $DONE -ne 1 ]]; do) still waits for more output from hexdump before checking the flag, and you need to touch the screen to create that output. So I ended up doing the "self-terminating script" thing, by parsing "ps a" and killing the first "hexdump $T" process. If you kill the "script -c" your terminal goes bonkers, but it dies cleanly by killing its child process.

My "solution" may be crude but it will work until I find something better.

In my previous incarnation of my "onscreen keyboard" program, I just grabbed 64 bytes of touch event data (minimum guaranteed size), but that was (infrequently) missing the Y coordinate if a "sync" packet got squeezed in there, resulting in a lost keypress.

Now I do all processing inside the inner subprocess loop, but I wanted to exit without needed two touches, and hence the "ps kill" hack.

Anyway, when people suggest that I try things that don't actually work in the environment I described (diags bootmode), it wastes my time after I try it and find out I just wasted my time, and I have very little of that to spare.

[knc1]

Originally Posted by geekmaster

Anyway, when people suggest that I try things that don't actually work in the environment I described (diags bootmode), it wastes my time after I try it and find out I just wasted my time, and I have very little of that to spare.

1) The topic was changing device names.
I only addressed the topic.

2) I never received the copy of your code, nor the link to where you have your work-in-progress posted in a public repository.
So how am I expected to fix your coding errors?

3) I do not set the priorities of how you schedule your own time.
You get to do that yourself, I refuse to be responsible for the result of your own choices.

4)

[geekmaster]

This thread was to provide others a warning that we cannot make assumptions about input device file names like past code did. I do not have code bugs that I want you to solve, nor do I want you to manage my time (just don't waste it with dead-end suggestions). This thread is about how diags uses different device names than main uses, and the paths you and ixtab suggest that I use do not even exist in diags. I spend a lot of time checking my facts before I post them, and you should too.

[knc1]

Originally Posted by geekmaster

I am currently getting the path to the zforce events this way:

T=$(for i in /dev/input/event*;do evtest info $i|grep zforce>/dev/null&&echo $i&&break;done)


If I change it to use your suggestion, it makes the command line longer, but no longer requires calling the built-in evtest program:

T=$(for i in /sys/class/input/event*;do grep zforce $i/device/name>/dev/null&&echo $i&&break;done)

I do not think that loop will do what you expect it to.
Reads like a discovery process to me.

Originally Posted by geekmaster

I then use it like this:

script -c "hexdump $T" /dev/null | while...

The script command forces unbuffered STDOUT so I can sense touches immediately instead of waiting for enough extra touch data to trigger a full buffer. It is annoying to need to press an onscreen keyboard button multiple times to get any action, then have those multiple touches come out in a batch.

The complication is things in a piped while loop run in a separate process, and when my "Exit" button is touched in the inner do loop, an "exit" or "return" command only acts like a break, exiting only to the done. Setting DONE=1 to break the while (while [[ $DONE -ne 1 ]]; do) still waits for more output from hexdump before checking the flag, and you need to touch the screen to create that output. So I ended up doing the "self-terminating script" thing, by parsing "ps a" and killing the first "hexdump $T" process. If you kill the "script -c" your terminal goes bonkers, but it dies cleanly by killing its child process.

Answer:
Do not use a "piped while loop".

Originally Posted by geekmaster

My "solution" may be crude but it will work until I find something better.

In my previous incarnation of my "onscreen keyboard" program, I just grabbed 64 bytes of touch event data (minimum guaranteed size), but that was (infrequently) missing the Y coordinate if a "sync" packet got squeezed in there, resulting in a lost keypress.

Now I do all processing inside the inner subprocess loop, but I wanted to exit without needed two touches, and hence the "ps kill" hack.

Yeah, what you describe is certainly a dirty way to solve the problem you have.
When you find yourself doing something like that, take a break and re-think your solution.

Originally Posted by geekmaster

Anyway, when people suggest that I try things that don't actually work in the environment I described (diags bootmode), it wastes my time after I try it and find out I just wasted my time, and I have very little of that to spare.

You must have seen the names you where interested in, otherwise why did you try to poll them in a script?

Originally Posted by knc1

1) The topic was changing device names.
I only addressed the topic.

2) I never received the copy of your code, nor the link to where you have your work-in-progress posted in a public repository.
So how am I expected to fix your coding errors?

3) I do not set the priorities of how you schedule your own time.
You get to do that yourself, I refuse to be responsible for the result of your own choices.

4)

Originally Posted by geekmaster

WTF? This thread was to provide others a warning that we cannot make assumptions about input device file names like past code did.

And the separately sub-titled, response was a confimation that names in the /dev sub-tree are dynamic and that the names in the /sys sub-tree are fixed.

Originally Posted by geekmaster

I do not have code bugs that I want you to solve, nor do I want you to manage my time (just don't waste it with dead-end suggestions). This thread is about how diags uses different device names than main uses, and the paths you and ixtab suggest that I use do not even exist in diags. I spend a lot of time checking my facts before I post them, and you should too. You need to chill, dude! Go read a book or something...

While I am off reading that book, I think you need to re-read what you posted, as noted above.

[geekmaster]

SUMMARY: Constructive criticism is welcome when it provides specific details, suggested improvements, references, links, or examples of tested working code or methods. Destructive criticism with no specific details and no suggested improvements is not helpful, and can discourage development in an unhealthy manner.

[hawhill]

Please consider that nothing in this thread was probably meant destructive. I clearly read everything that way. OTOH, don't expect everything to be constructive. You cannot really hold a discussion with the premise that everything has to be constructive (there are sometimes reasons to call certain ways wrong, which should be allowed to be discussed too). Discussion behaviour is quite different among people. Some people that you would call harsh or pressing might actually be just to shy or to polite (different cultures!) to say too much at first, but might offer valuable points if one just asks "well, why do you think that?" in return.

Geekmaster, you're also writing exceptionally long posts. While they do certainly hold their share of information, please consider that the length alone will increase the probability to get worn into side issues or to be misunderstood. Nothing wrong with the length, not at all, but be prepared to be misunderstood sometimes. We all should be.

I'm sorry I interrupted this thread with this metadiscussion, but I have a strong feeling that we have some terrible misunderstandings of each other's intents going on here. It would be sad to let that ruin fruitful conversation. I really like the "developer's corner" hangout, one reason for that being the vast heterogeny of people contributing here.

[geekmaster]

Originally Posted by hawhill

Please consider that nothing in this thread was probably meant destructive. I clearly read everything that way. OTOH, don't expect everything to be constructive. You cannot really hold a discussion with the premise that everything has to be constructive (there are sometimes reasons to call certain ways wrong, which should be allowed to be discussed too). Discussion behaviour is quite different among people. Some people that you would call harsh or pressing might actually be just to shy or to polite (different cultures!) to say too much at first, but might offer valuable points if one just asks "well, why do you think that?" in return.

Geekmaster, you're also writing exceptionally long posts. While they do certainly hold their share of information, please consider that the length alone will increase the probability to get worn into side issues or to be misunderstood. Nothing wrong with the length, not at all, but be prepared to be misunderstood sometimes. We all should be.

I'm sorry I interrupted this thread with this metadiscussion, but I have a strong feeling that we have some terrible misunderstandings of each other's intents going on here. It would be sad to let that ruin fruitful conversation. I really like the "developer's corner" hangout, one reason for that being the vast heterogeny of people contributing here.

Thanks for the suggestions.

Regarding "sometimes reasons to call certain ways wrong", I agree that it is fine to call a way "wrong" if a "right" way is recommended to replace it, or at least that is should be worded in a way to not cause anger. But just calling something "wrong" with no details about why you think it is wrong, and no suggestions about how to improve it (i.e. "aggressive listening") causes anger in many people (not just me): http://c2.com/cgi/wiki?AggressiveListening
Here is a quote from that URL: [What Aggressive Listeners don't seem to understand is that their "challenging questions" have underlying meanings of "you are lying to me" or "you are incompetent".]. Sadly, what irks me most is the icon knc1 used, now super-glued to his identity in my mind.

Regarding the "exceptionally long posts", there is a famous quote "if i had more time i would have written a shorter letter", frequently attributed to Cicero, Blaise Pascal, Mark Twain, and others. It takes me multiple revisions to condense my posts down to contain the same (or more) useful content in a smaller space. My source code does this too -- I often add features by removing limitations, with the side-effect of smaller code as it gets refactored through mutliple revisions. I find that the process of polishing a rough draft into a completed manuscript first makes it grow, then usually condenses the word content by a factor of 16, while retaining all of the important information content. I have studied the "Reader's Digest" rules for text condensation, and I try to apply them during the final stages, but that is not particularly useful for ephemoral (short-lived) content such these posts.