flat assembler
Message board for the users of flat assembler.

Index > Heap > polling deas, how to verify desktop screenshots

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
problem description:
somebody took screenshots of something important, be it news, conspiracy posts, craiglist posts, etc

how to let that screenshot jpg / png file (through our software / application / utility) become a evidence of itself?

what stuff we must add into that screenshot in order to prevent tampering, false screenshot and etc
Post 09 Jul 2016, 22:44
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
- this push me to ponder about how exactly to record event / transaction, a solid checksum, prevent re-animate of that event to re-create one flavored evidence

- let say i set up a online binary gamble site with following rules,

- a dice rolls, would give a number from 1 to 6,

- (low) 1,2 = if you bet low correctly, your bet 2x return (1 dollar gain another 1 dollar)

- (middle) 3,6 = i take 50% of your bet (1 dollar lose 0.50 cent, you get 0.50 back)

- (high) 4,5 = if you bet high correctly, your bet 2x return (1 dollar gain another 1 dollar)

- your concern would be, you bet low, i tweak the result to middle or high to make you loss

- or i total up bet money in low vs high, and i twist the result to my best position, so i always make money no matter what,

- so, what if i announced the dice result first and then only i let you bet?

- then this would be a very fair betting game for you

- let say before you bet, the result announced in md5, e4da3b7fbbce2345d7772b0674a318d5

- you google e4da3b7fbbce2345d7772b0674a318d5 and found out it is "5"

- but what if the result i announced is, "random stuff" + "random number" + "etc" + and last with dice number

- eg. 1f246d6e2294cfd707b85b9bb301578e

- my source md5 is, "World number one Serena Williams beat German fourth seed Angelique Kerber to win a seventh Wimbledon and 22nd Grand Slam title. The dice number is 1" without the 2 quotes

- so result shown first, then only everybody bet, if you google 1f246d6e2294cfd707b85b9bb301578e, you get nothing and this protect me from bankrupt

- so, after people bet their money, system shows source md5 and people can verify themselves, and host could proves their gambling system is fair

- i could embed date time into this random md5 input string too, eg.

"With such an array of big sporting events taking place this weekend, find out ways you can get involved by watching and having a go yourself. The datetime is 10 July 2016, 7:22 AM, the dice number is 6-3 equal 3."

which resulted c96e2a31fed98daf4a2bfa9904d3a2a9
Post 09 Jul 2016, 23:24
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
- the concern here is, how i prevent myself bankrupt if you keep on double your bet

- and your concern if i purposely roll 3 and 6 to eat your bet

- how we could come into a fair bet that determine by the act of dice?
Post 09 Jul 2016, 23:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
1) You can't verify anyone's screen shot. Ever.

2) If you don't trust online betting then don't use it. Ever.
Post 10 Jul 2016, 00:14
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
revolution wrote:
1) You can't verify anyone's screen shot. Ever.

2) If you don't trust online betting then don't use it. Ever.


1, i could only say, i don't think so, at least at this moment, there got to be a way,

2, i think it is about creating a better, fair and more transparent betting system that let the result be determined by the act of dice,
Post 10 Jul 2016, 08:48
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
sleepsleep wrote:

what stuff we must add into that screenshot in order to prevent tampering, false screenshot and etc


ever use PGP/GPG before?

probably using a screenshot app which will encrypt the screenshot automatically using the author's public key (and yours as well)?

but that means unless the file is decrypted, it cannot be verified publicly

hmmm Confused
Post 10 Jul 2016, 09:20
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
Verifying with MD5?! Depending on the application, it is useless because it is cracked and producing collisions are as fast as 1, 2, 3.
Post 11 Jul 2016, 04:00
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
hi TmX,

i was thinking like an application, if run, it would shows something on the desktop, a graphic or etc, so whenever the user print screen, that "extra string & numbers & " would get screenshot into it

so what capabilities would this application,

- user press screenshot, our application hook screenshot key at the background

- we calculate a whole printshot area checksum

- if user present salt value, we will use md5(salt value + date time info + screenshot area md5)

- since our md5 string will be on top of that screenshot, we copy out the previous pixels data and give it to user, (so only he could verify he is the owner of that particular screenshot)

- we then post the md5 to blockchain and charge 0.00000001 BTC example

- a new blockchain concept for such date/time verification purpose might be useful in future,


the issue we face,
user might tamper the data on screen before doing the screenshot, md5 of that screenshot correlate blockchain insert date/time, but the data on screenshot is tampered,

- solution is actually quite easy,

- for screenshot info verification, this user (or other users who want to verify that screenshot) needs to offer up eg, 0.00001 BTC or etc for 100 people, to post the exact info screenshot,

- most people love money, and they might just conspired with that tampered info and post tampered info screenshot too

- so we could present a voting idea here to solve this issue,

- eg, if you need 100 others to verify your screenshot info,
if 80% said info is correct, then 80% get money, 20% no money
and this percentage will be inserted into blockchain too later with reference to this screenshot md5


so we got a new idea here, info verification economy system,
user offer up bounty/money/tips, and others participate to verify the info and find additional information.
Post 11 Jul 2016, 04:50
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E
YONG
1. Each user is assigned an encrypted secret key, which is kept in the system and is unknown to the user.

2. A time stamp is always shown on the screen.

3. On the top and at the bottom of the screen, there are two thin colored bands.

4. The two bands are like photoTAN/CrontoSign, which are, in fact, concatenations of a series of small rectangular portions. The portions are generated by taking into account (at least) three inputs:
- the secret key,
- the time stamp, and
- the actual contents appearing within a thin vertical column of the screen.

5. To make the colored bands less distracting, we may use a gradient of color saturation instead of a spectrum of different colors.

6. We may use two different proprietary hash algorithms, one for the top portion and the other for the bottom one. Or we may use just one hash algorithm but split the result into two parts, one for the top and the other for the bottom.

7. Screen shots without the top and bottom bands or the time stamp are considered invalid.

8. Users trying to tamper with the contents of the screen shot would not be able to regenerate the top and bottom portions without knowing the secret key and the proprietary hash algorithm(s).


Refer to:

photoTAN / CrontoSign
https://en.wikipedia.org/wiki/Transaction_authentication_number#photoTAN_.2F_CrontoSign

Color Saturation
https://en.wikipedia.org/wiki/Colorfulness#Saturation

Wink


Description: Screen Shot Example
Filesize: 15.11 KB
Viewed: 6451 Time(s)

Idea.png


Post 11 Jul 2016, 06:28
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
YONG wrote:
1. Each user is assigned an encrypted secret key, which is kept in the system and is unknown to the user.
Oops, failed at the first step. The system is not secured against the user. Just ask anyone who tries to implement DRM.
Post 11 Jul 2016, 09:01
View user's profile Send private message Visit poster's website Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E
YONG
revolution wrote:
YONG wrote:
1. Each user is assigned an encrypted secret key, which is kept in the system and is unknown to the user.
Oops, failed at the first step. The system is not secured against the user. Just ask anyone who tries to implement DRM.
What's wrong with assigning each user with an encrypted secret key? Rolling Eyes

... I got it. There is something wrong with your location. HD 131399Ab, the exoplanet that you are currently on, has four times the mass of Jupiter, i.e., 1272 times the mass of Earth. Under the huge gravity like that, your brain must not be functioning correctly. Son/Daughter, please go home asap. Or you may suffer from asphyxia. Twisted Evil

Wink
Post 11 Jul 2016, 09:52
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
YONG wrote:
1. Each user is assigned an encrypted secret key, which is kept in the system and is unknown to the user.

i think it creates more job for us to implement,
- to store encrypted key, (there are policies out there to abide if what you store is encrypted key), more rules and regulations to follow, more complex

- unless the picture is hashed server side (requires upload now), otherwise, secret key will somehow needs to present on client side, and that mean it will no longer be secret (this add into bandwidth requirement and increase cost to deploy such service)

- why we need to keep the secret key secret?

back to why i posted this in the first place,

- user screenshot after he saw the following craiglist ads, eg, "Dallas Crisis Actors Needed Craiglist ads" save into his drive (maybe because he finds this ads suspicious or interesting)

- after a week or so, shit happened in Dallas, terrorists attack, or etc attack

- this guy remembered the screenshot, start posting on board and tell others, that attack most probably could be some kinda conspiracy to bring attention away from shillary email, fbi say no problem, clinton foundation and so on, a planned fake attack or etc

- he posted the craiglist ads link, but too bad, it is gone now, blocked as instructed by higher power or etc

- he posted screenshot, but people said he made up,

- the truth could be, he made up that screenshot too, we got no way to verify this,


my thoughts regarding above problem

- i think we are dumped with lots of information, so much that it becomes useless

- google rank their search result based on how relevant those are with your query string, not how much real or truth with what you query

- eg, AI trades nasdaq, dow jones based on official twitter account posts, once hackers hijack that twitter, you could imagine the havoc ensues in index

- those are information, but how true is that information is nobody know

- the next google would be information verify-er, confirmationer, (you read this in 2016, you would see this in 2021)

- users want information, and they prefer verified information, logical approach and management to information that available on everywhere

- everybody could produce trillion tons of information, screenshot, photos, etc, and everybody could produce information that they got no idea, when they are not expert or etc.

- what we could do is, present a way to at least verified the date/time and screenshot content hashed

- hashed stored in blockchain, no way to tamper the hash and inserted date/time, they are still issues in that technology, but so far, it doesn't allow you to modify yesterday transactions,

- as i said previously, users could tamper the html sources easily to invent new information, screenshot and post hash into blockchain,

- and to solve such issue, we need to pull everybody into this, tips them with money, bitcoin or etc, so information consumers could become information verifier, and through such process, we create new information economy and enrich everybody

- long term view, to create a more logical and sane online society,

- expert in particular field could verify something, but those non-expert could verify other things/information

- voting allow people to express their judgement through investigation, thats why the need for them to present their screenshot with exact info, or opposite info to confirm those lies,
Post 11 Jul 2016, 10:22
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
YONG wrote:
What's wrong with assigning each user with an encrypted secret key?
The problem is the word "secret". You can't keep secrets from the user. If the CPU can access the "secret', then so can the user. It is the classic DRM unsolvable problem.
Post 11 Jul 2016, 10:24
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
i need to tweak a bit previous idea,
i found something more simple,

- under previous idea, the burden to proof lies on the person who posted the screenshot, if he keeps mum, it means nobody can verify, since we need his salt value to verify,

- this issue could raise because another person might copy his screenshot hash and photoshop it into his screenshot, so we got 2 screenshot with same hash,

- through the hash from blockchain, we know the screenshot was taken in 1st July 2016, but which one?

- so i thought of something more simple,

- when i said hash, i mean hash of screenshot data, not file hash

- i will use YONG idea to add a 18 pixels top bar, with font size 14 px

- top bar info would be

| date taken : 01 July 2016 06:22:20 |
| previous hash from blockchain : 64ec70591e393276b5f75643496fcc97 |
| hash for screenshot region data : 12227ac1ea36d1ab2c0656099be9f8cb |
| final hash for this screenshot : 3c35bd7174879957bc5296d5181420a4 |

hash of this screenshot would be, md5 of previous hash from blockchain and hash for screenshot region data

submitted into blockchain would be 3c35bd7174879957bc5296d5181420a4 which will become previous hash from blockchain for next user screenshot

so, to verify date/time, others just need to query 3c35bd7174879957bc5296d5181420a4 from blockchain

to make sure the screenshot region data is expected, user just open the file with our application, which will deselect the top bar info region, and calculate md5 of it,

if region data not tampered, you got 12227ac1ea36d1ab2c0656099be9f8cb
Post 11 Jul 2016, 11:30
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
HaHaAnonymous wrote:
Verifying with MD5?! Depending on the application, it is useless because it is cracked and producing collisions are as fast as 1, 2, 3.


we could use SHA-3 then
Post 11 Jul 2016, 11:34
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E
YONG
sleepsleep wrote:
- unless the picture is hashed server side (requires upload now), otherwise, secret key will somehow needs to present on client side, and that mean it will no longer be secret (this add into bandwidth requirement and increase cost to deploy such service)
I always thought that we were talking about a web-based / client-server application. The user would have to log in to use the application. And of course, the encrypted secret key would have to be kept on the server side.

If you are talking about an application that runs entirely on a PC, revolution is correct in saying that we cannot keep any secrets from the user, because the user can always try "reverse engineering" and find out the inner workings of the application.

Wink
Post 11 Jul 2016, 12:03
View user's profile Send private message Visit poster's website Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E
YONG
"Orbiting HD 131399Ab" is better and safer. Enjoy your trip, revolution.

Wink
Post 11 Jul 2016, 12:07
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
I think verifying screenshots is not possible.

The user can modify the contents of the screen before capturing.
Post 11 Jul 2016, 13:48
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
YONG wrote:
I always thought that we were talking about a web-based / client-server application. The user would have to log in to use the application. And of course,


it is possible too to use such method,

- we code a server side web browser, so user browses inside, all ads remove, trans box

- when user press web web browser screenshot button, hash on browser content window obtained, browser will pass the same link to server, server will hash the same stuff, with exact viewing condition,

- is it possible to get same hash? idk, in case we got the exact same hash, we could say content is verified,

- exact hash obtained, hash pass to blockchain and we could say, content verified

- issue might be if viewed content requires authorization, would user pass their username, password to server in order to gain exact browser content, i would say 100% they don't want, don't trust,

- so it only works on public accessible content, afaics

- but still a nice concept if you ask me,
Post 11 Jul 2016, 16:53
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
HaHaAnonymous wrote:
I think verifying screenshots is not possible.

The user can modify the contents of the screen before capturing.


it should be possible if we could deploy information/content verifier economy system, as i mentioned above
Post 11 Jul 2016, 16:56
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.