* * *

Recent Posts

Pages: [1] 2 3 ... 10
1
General / Re: An advice - um conselho
« Last post by hrayon on Today at 01:58:27 am »
Hello! Another information to put on the scale. Imagine not releasing the code, just the binary part. And someone breaks your protection. Will you release a fix on your software? Another question: Consider whether your code is stolen and sold under another name. How effective will the application and monitoring of the license be? Are you prepared to accept that theft can occur and that others can make money from your work without crediting you?


Olá! Uma outra informação para colocar na balança. Imagine que não libere o código, apenas a parte binária. E que alguém quebre a sua proteção. Você liberará uma correção no seu software? Outra questão: avalie a possibilidade do seu código ser roubado e vendido sob outro nome. O quão efetiva será a aplicação e monitoramento da licença? Está preparado para aceitar que o roubo pode ocorrer e que outros poderão fazer dinheiro com seu trabalho sem creditá-lo?
2
General / Re: Ubuntu Launcher not using OnShow
« Last post by soerensen3 on Today at 12:29:27 am »
Maybe you should create your form manually because otherwise it is really simple to show a hidden window from another application so it would also be very simple to bypass the password.
3
Networking and Web Programming / Re: indy IRC and Umlauts
« Last post by mica on Today at 12:12:39 am »
Thanks Remy Lebeau, i think this solved my issue

IdIRC1.IOHandler.DefStringEncoding:=IndyTextEncoding_UTF8;
IdIRC1.IOHandler.DefAnsiEncoding:=  IndyTextEncoding_UTF8;

in the connected Event
4
Beginners / Re: Find text
« Last post by justnewbie on April 20, 2018, 11:59:00 pm »
@howardpc: thank you, I will study it!
Meanwhile I could do my own solution by using StuffString http://lazarus-ccr.sourceforge.net/docs/rtl/strutils/stuffstring.html
5
General / Re: Ubuntu Launcher not using OnShow
« Last post by jamie on April 20, 2018, 11:52:41 pm »
what manner are you using for the Password frontend ?

 Not sure how this all plays out on non-windows targets but I think you can switch
the MAIN form in the Application to your Password form and hide the prior main form..

 Switch back when ok.
6
Android / Re: LAMW: Android 7.1.2
« Last post by c4p on April 20, 2018, 11:46:55 pm »
I think I have isolated the issue and should have picked up on it sooner tbh.
Not sure if you recall a while back I mentioned that I could not save to the TEnvDirectory dirInternalAppStorage using the jDownloadManager component but could to dirDownloads, dirNotifications etc., to cut a very long story short, I could save to Internal App Storage on 7.1.1 but not on 7.1.2 and can no longer save data directly to that location, but can save fine on 5.1, 4.4 etc. which sent me on a bit of a tangent.
The code below works perfect on 5.1.1, 4.4.2 but not on 7.1.2 (depreciated?) and have to assume it works on 7.1.1 but not tested this since:
Code: Pascal  [Select]
  1. jListView1.Items.SaveToFile(GetEnvironmentDirectoryPath(dirSdCard)+GetInternalAppStoragePath+'/test.txt');
I did fresh installs back to LAMW rev. 691, rev.700 and used the latest rev.701 (0.8 version) but was still the same.

So to summarise, it's not a new issue and is to do with saving to the InternalAppStorage on certain Android versions, one being 7.1.2.
7
General / An advice - um conselho
« Last post by ezlage on April 20, 2018, 10:19:12 pm »
Since 2010, when I signed up for this forum, I've been studying about and looking for a way to protect cryptographic keys inside executables or libraries. Along the way I learned that it is impossible to protect absolutely because keys are clean parameters for cryptographic functions and methods, so there will always be risks. From then on, my focus has become reducing the attack surface to a minimum, and I'm close to completing my task.

I created a component that I call AppShield. The functions of it add some things that the already known UniqueInstance, OnGuard, StrHolder and others do (not only them, not all of them). I preferred not to reuse the code of the referred ones to facilitate my understanding on the interaction of pieces of code and the operation as a single piece. I only extract the idea of ​​each one, since ideas are not subject to licensing or patents. However, most of my component is made up of functions and methods of encryption, compression, xor, key derivation, message authentication, hash/checksum, execution of protected SQL code (SQLite/SQLCipher pragmas key/rekey for example), prevention against SQL Injection, protection of strings and texts. The protections embrace the execution time, design time, distribution time and loading time.

Many here in the forum contributed to my work, I will thank them again later. I received very good suggestions, like using hardlocks/dongles. I implanted the suggestions that were possible for me, but hardlocks/dongles involve costs, so I could use this alternative only when my other projects, which demand this one, start to give me a financial return.

Although it has been eight years of my effort, I do not mind opening the code, but due to the impossibility of absolute protection, I fear that knowledge about the code will be a map to circumvent the mechanisms that would theoretically reduce the attack surface. So the big question is: release the code would increase or decrease the safety of my component?

Please convince me of something because I am very hesitant.


=== Now in Brazilian Portuguese ===

Desde 2010, quando me inscrevi neste fórum, venho estudando sobre e procurando por uma forma de proteger chaves criptográficas dentro de executáveis ou bibliotecas. No caminho aprendi que é impossível proteger absolutamente porque as chaves são parâmetros limpos para as funções e métodos de criptografia, então sempre haverá riscos. Daí em diante, meu foco se tornou reduzir a superfície de ataque ao mínimo, e estou próximo de concluir minha tarefa.

Criei um componente que denomino como AppShield. As funções dele agregam algumas coisas que os já conhecidos UniqueInstance, OnGuard, StrHolder e outros fazem (não apenas elas, nem todas elas). Preferi não reaproveitar o código dos referidos para facilitar o meu entendimento sobre a interação dos pedaçoes de código e o funcionamento como uma peça única. Extraí apenas a idéia de cada um, já que idéias não estão sujeitas a licenciamento ou patentes. Todavia, a maior parte do meu componente é composta por funções e métodos de criptografia, compressão, xor, derivação de chave, autenticação de mensagens, hash/checksum, execução de código SQL protegido (pragmas key/rekey do SQLite/SQLCipher por exemplo), prevenção contra SQL Injection, proteção de strings e textos. As proteções abragem o tempo de execução, tempo de design, tempo de distribuição e tempo de carregamento.

Muitos aqui do fórum contribuíram com o meu trabalho, eu irei adradecê-los novamente depois. Recebi sugestões muito boas, como utilizar hardlocks/dongles. Eu implantei as sugestões que eram possíveis pra mim, mas hardlocks/dongles envolvem custos, então eu poderia utilizar essa alternativa apenas quando meus outros projetos, quais demandam este, começarem a me dar retorno financeiro.

Embora tenham sido oito anos do meu esforço, não me importo em abrir o código, mas devido à impossibilidade de proteger de forma absoluta, temo que o conhecimento sobre o código venha a ser um mapa para contornar os mecanismos que teoricamente reduziriam a superficie de ataque. Então, a grande questão é: liberar o código fonte aumentaria ou diminuiria a segurança do meu componente?

Por favor, convençam-me de alguma coisa porque estou muito indeciso.
8
Beginners / Re: Compiler can't find TPU files
« Last post by CzarAlex on April 20, 2018, 10:11:33 pm »
Thaddy, were you trying to compile Example.pas? I loaded that up and received this error. Seems similar to my others.

EDIT: I set up some directory paths to and solved that error but new ones keep popping up. Ugh..
9
AFAIK Indy uses HTTP version 1.0 for posts.

By default, yes.  You can disable that behavior by enabling the hoKeepOrigProtocol flag in the TIdHTTP.HTTPOptions property, then Post() will respect whichever version you specify in the TIdHTTP.ProtocolVersion property.

Also, Indy handles empty response and turns it into:
Code: Pascal  [Select]
  1.           if Length(LLocalHTTP.Response.ResponseText) = 0 then begin
  2.             // Support for HTTP responses without status line and headers
  3.             LLocalHTTP.Response.ResponseText := 'HTTP/1.0 200 OK'; {do not localize}

That is to handle old HTTP 0.9 servers, which don't send status lines or headers in responses (they also don't technically support POST either, only GET).

The ResponseText should NEVER be empty when communicating with an HTTP 1.0+ server.

Simple severs might expect Content-Length header directly after Content-Type header.

No HTTP server should *require* that, as it is forbidden by the HTTP specification to *require* headers be in any particular order.

Code: Pascal  [Select]
  1.     client.AddHeader('Content-Length', IntToStr(length(sJSON)));

That will fail to work if the JSON contains any non-ASCII characters.  The 'Content-Length' is the number of *bytes* being sent, not the number of *characters*.  So, if the JSON is encoded as UTF-8 during transmission, the 'Content-Length' must be set to the number of UTF-8 bytes being sent.

Indy keeps the connection alive:
Quote
Connection: keep-alive

HTTP 1.1 defaults to keep-alive semantics, unless you specify otherwise.  TIdHTTP explicitly requests keep-alive semantics in HTTP 1.0 unless you specify otherwise (in the TIdHTTP.Request.Connection property).  Ultimately, it is the server that decides whether a keep-alive is actually used or not, and that is reflected in the server's response (in the TIdHTTP.Response.KeepAlive property).

Keep-alive or not has no effect whatsoever on how the server processes a POST request, though.  It only affects whether the socket connection is kept open or is closed after the response is sent.
10
Networking and Web Programming / Re: indy IRC and Umlauts
« Last post by Remy Lebeau on April 20, 2018, 09:26:12 pm »
If IdIRC1.Say(channel,message) contains an Umlaut (äöü) the message doesent
show in the Chat .

The IRC protocol does not provide any provisions for handling Unicode data.  Text is sent as arbitrary bytes, clients can use whatever charsets they want, and have to manually detect and decode whatever they receive.  It is not uncommon to see text transmitted in charsets like ISO-8859-1, KOI8-R, SHIFT-JIS, ISO-2022-JP, etc.  However, UTF-8 is very common nowadays.

TIdIRC does not have any direct support for handling text encodings, it relies on whatever the DefStringEncoding and AnsiEncoding properties of its IOHandler are set to, which are set to ASCII and OSDefault by default, respectively.  That is why you are losing non-ASCII characters, like Umlauts.

After connecting to the IRC server and before sending any IRC commands, such as in the OnConnected event, you can set the IOHandler's DefStringEncoding and DefAnsiEncoding properties to whatever you want, such as IndyTextEncoding_UTF8.
Pages: [1] 2 3 ... 10

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus