Aktualizováno 02.06.17 16:17:50
***********************
02.06.2017
V GRD v režimu ET a okamžitém ESC se zeptalo, zda uložit výsledek
do RDA. Odpověď ano vedla k uložení všech vět. Nyní vznikne prázdná
relace.
***********************
24.03.2017
JUMP a spol. zjistili, že od Win7 se po najetí na ikonu WR na liště
se zobrazí zmenšená stránka a buď za okamžik nebo okamžitě se
v obrázku objeví křížek. Tímto křížkem bylo možno běžící aplikaci
kdykoliv odstřelit. To jsem nyní zakázal. Vzhledem k tomu, že
někteří uživatelé JUMPu tuto možnost využívali, měli chlívek
v datech a zálohování (na první pohled nepochopitelně).

Tato možnost již byla v podstatě i v XP s tím, že křížek byl
v souladu s křížkem aplikace aktivní nebo zašeděn - chovalo se to tedy
z našeho pohledu slušně!
***********************
27.02.2017
Předchozí zprávu ing. Čampula neguje. Mezera a pomlčka mu prochází.
********************
Problémy s EET ve Vosa Znojmo pokračují tímto zjištěním ing. Tempíra:

včera mě řádně vyšplouchlo XML pro EET. Pokud je v řetězci id_pokl
mezera nebo pomlčka ( "-" ," "), vede to k nevalidnímu XML. Neměl někdo
stejný problém?

Zdroj http://www.etrzby.cz/assets/cs/prilohy/EET_popis_rozhrani_v3.1.1.pdf

Ve specifikaci je uvedeno:
3.3.3.8 Označení pokladního zařízení poplatníka (id_pokl)
Je atributem XML elementu <Data>. Je to identifikační kód pokladního
zařízení poplatníka, které zasílá datovou zprávu evidované tržby na
společné technické zařízení správce daně. Tento kód je tvořen na straně
poplatníka alfanumerickými znaky a vybranými speciálními znaky. Pro
konkrétního poplatníka musí být označení pokladního zařízení unikátní na
jedné provozovně v jednom okamžiku. Přesně to znamená, že musí být
unikátní čtveřice položek:
(dic_popl, id_provoz, id_pokl, dat_trzby).
Maska datového formátu:
[0- 9a- zA- Z\.,:;/#\-_ ]{1,20}$
kde poslední znak v hranaté závorce je mezera (znak " " s dekadickým
kódem 32 v ASCII znakové sadě) a znak "-" je pomlčka (znak s dekadickým
kódem 45 v ASCII znakové sadě).
Délka: 1 až 20 znaků.
Příklad:
5a/A-q/5:22d_2

*Jan Tempír-Kotrlý*

LEVEL FIRM v.o.s.
********************
19.02.2017
Vygeneruje se náhodné číslo < maximum dané v parametrech křivky a pak se
zřejmě hledá hodnota k náhodnému číslu tak, aby (x,y) leželo na křivce.
Tuto doměnku ještě musím ověřit. Pracuje se všude se 128 bitovými čísly.
********************
18.02.2017
SHA512 jede, ověření, že zaslaný bod serverem leží na ekliptické křivce
c23 a RSA podpis hash sha512 vybrané části odpovědi clienta a serveru sedí.
Nicméně stále není jasno k čemu to a jak dál.
********************
16.02.2017
V kauze https bohužel sha256 nestačí. Musím dát dohromady sha512.
********************
16.02.2017
Ing. Havel z Vosa Znojmo dává podle něj podstatné upozornění:

Pokud se odešle UCTENKA.XML ale nedojde k získání FIK (asi nejde
internet), vytiskne se účtenka s BKP a PKP.
Při následném odeslání, ale musí mít UCTENKA.XML stejné BKP i PKP.
Protože PKP se tvoří z řetězce, který obsahuje DAT_TRZBY, musí se použít
dříve naplněné datum a čas (Také PRVNI_ZASLANI by se mělo nastavit na
"false", ale to není asi podstatné.).
V TRZBA.CMD se ale DAT_TRZBY pokaždé naplňuje aktuálním datem, což tedy
není správné.

Takže datum tržby by mělo být pevné. Podotýkám ale, že úvod tržby je pouze
pro ladicí účely a co je v EETV.RDA to se v rutině UCTENKA odešle - na datum
tržby se tedy zde nesáhne.
********************
08.02.2017
Již delší dobu se snažím přijít na kloub komunikaci HTTPS. Je to poměrně
komplikovaná záležitost. Zatím jsem zvládl navázání spojení a vyslání
zprávy HelloClient a analyzovat došlou odpověď HelloServer a následující
certifikáty, kryptografickou volbu a volbu ekliptické křivky.

Pro zjednodušení se mně podařilo zredukovat nabídku HelloClient na jednu
kryptografickou metodu a jednu ekliptickou křivku, kterou testovací servry
akceptují.

V CURL toto představuje mnoho rozsáhlých struktur a zanoření volání jedné rutiny
z druhé rutiny do úrovně až 10. U mne zatím pár desítek řádků. Nicméně jak
komunikovat šifrovaně na základě těchto úvodních informací se musím ještě
naučit.
********************
03.02.2017
Pro začátečníky v EET přikládám postřehy ing. Čampuly:

- Musí se získat soubor certifikátu poplatníka (např.CZ00000019.p12)
k souborům FIX,INIEET,CUT.
- Musí se nastavit cesty v programu INIEET.CMD.
- Musí se nejprve spustit program FIX.CMD a pokaždé, když změním certifikát
poplatníka
- Musí být stažen a umístěn program CURL.EXE do 'EXE'
- Musí být režim _MODE2 (v programu TRZBA.CMD)
- Nemusí se instalovat certifikát poplatníka - stačí soubor P12
- Nemusí se instalovat kořenový certifikát CA.
********************
02.01.2017
V dok585.zip je i CHM příručka.
********************
19.12.2016
Na webu je první verze dokumentace k wr585 - zatím XHL. Je nutno si stáhnout
i wr585, aby se na tuto dokumenaci odkazovala nebo wr585.xhl přejmenovat
na wr584.xhl.

Pokud vám v dokumentaci něco chybí nebo je špatně. Ozvěte se co nejrychleji
s eventuálními připomínkami!
*******************
14.12.2016
Náhodná chyba 325 - nelze číst! díky zamčení nebo chybě disku doplněna
na základě experimentu Ekosoftu o "či sítě". Dá se nasimulovat při
smyče ctení informací ze serveru vytažením Ethernetového kabelu.

Antiviry by po 10 sekundách držení souboru nebo části souboru způsobily
chybu 419 nebo 420 nebo 421.
*******************
12.12.2016
Ing. Tempír - Level firm konstatuje, že nejnovější verze AVG označila
curl.exe za škodlivý EXE a vyřadila ho. Naše EET hlásilo, že asi
nejde internet. Tato hláška je generována za curl, pokud vůbec nevznikne
soubor ODP.XML.
*******************
Protože se mně na to jeden váš kolega vyptával, tak touto cestou vám
sděluji, že v certifikátu xxx.p12 je tzv. veřejný a soukromý klíč.
Soukromý klíč je chráněný heslem, veřejný ne a FIX.CMD ho umístí do
SOAP hlavičky.

DGST podepisuje soukromým klíčem 32 bajtový SHA256 hash. Interně se na začátek
přidá předpsaný počet přesně definovaných bajtů (prefix) tak, že řetězec
má 256 bajtů. Pak se toto 256 bajtové číslo umocní 10001 hexa a ořízne se
modulo n - 256 bajtovým číslem z certifikátu. Podpis je tedy jakési 256
bajtové číslo, které se v EET vždy převádí do BASE64. Obecně 3 8 bitové
bajty vstupu se převedou na 4 6 bitové bajty. 256/3*4=341 se doplní dvěma
rovnítky (256+2 je dělitelno 3!) na 343 znaků.

SHA1 hash má 20 bajtů - to je BKP, presněji SHA1 hash z binární podoby
PKP což je 256 bajtové číslo podpisu předepsaného textového řetězce z
údajů na účtence.

Pokud máme k dispozici veřejný klíč, můžeme vytvořit textový řetězec
z údajů na účtence, aplikovat na něj SHA256 a dostaneme 32 bajtové
binární číslo. Pak pomocí veřejného klíče uděláme decrypt podpisu
a pokud vše funguje, dostaneme řetězec 256 bajtů s tím, že posledních
32 bajtů se shoduje s SHA256 hash z textového řetězce. Z toho se
usuzuje, že účtenku zaslal majitel certifikátu. Toto dělá server
na FÚ.

Analogicky funkce VERIFY pracuje se SOAP hlavičkou. V ní je veřejný
klíč FÚ, podpis SOAP havičky dle soukromého klíče. Na upravený text
části odpovědi se aplikuje SHA256 a po decryptu podpisu se porovnává
s tímto 32 bytovým hash. Dále ještě na upravený text BODY se aplikuje
SHA256 a výsledk má být shodný s DigestValue v SOAP halvičce odpovědi.

Protože by obecně bylo obtížné utajit klíč k certifikátu pokud bychom
ho chtěli bez podpory operátora používat - PKP.PEM je obecně zašifrován
zadaným výstupním heslem, rozhodl jsem se problém řešit tak, že si
vytvořím v pkcs12_pem kromě PKP.PEM ještě binární soubor EETV.DAT,
ze kterého DGST získá soukromý klíč již bez znalosti výstupního hesla.
Klíč je tedy mnou zabezpečen a operátora netřeba opakovaně obtězovat
zadáním hesla ani se bát při jeho poznamenání jeho vyzrazení analýzou
chodu vašeho programu. V důsledku toho je heslo v DGST zbytečné a může být
zcela libovolné. Pokud by ale EETV.DAT v adresáři s PKP.PEM chyběl,
přejde se na PKP.PEM a v tomto okamžiku DGST potřebuje správné heslo!
*******************
03.12.2016
Protože na účtence má být bkp+fik nebo v případě neuspěšného spojení
pkp, doplnil jsem tyto údaje do struktury EETV.RDA i když si to asi
většina z vás již provedla.
*******************
Při hledání nějakého problému jsem zjistil, že TRZBA.CMD neuvolňuje
v mnoha případech paměť. To by se mohlo projevit po mnoha cyklech
vyčerpáním dostupné paměti. Toto jsem dnes napravil.
*******************
30.11.2016
Z důvodu utajení hesla k certifikátu doporučuji místo uložení
v inieet.cmd se na jeho hodnotu zeptat obsluhy. heslo_out nastavit
na cokoliv (třeba na heslo_in), protože má význam pouze pro tvorbu
pkp.pem, který nadále nepoužívám. V dgst pak heslo_out nemá opět
význam. Takže obecně hesla v inieet.cmd můžete nastavit nějak
pouze pro matení nepřítele.
********************
28.11.2016
Příkaz verify vychází pouze ze zaslané odpovědi a v tržba.cmd je vidět

.verify "odp.xml"
.;Došlo k chybě - odpověď bez SOAP hlavičky
.if($filerr<=1) .goto CHYBOVAODP;
.if($filerr==4)
.begin
e.chyba:="Neplatný podpis SOAP"; e.kodch=50+$filerr;
.end
.if($filerr==24)
.begin
e.chyba:="Neplatný digest BODY"; e.kodch=50+$filerr;
.end
.if($filerr>1)
.begin
e.chyba:="Odpověd je zkomolená"; e.kodch=50+$filerr;
.end
_write e,1
_close e
.goto ADR
;Verifikace vyšla
********************
Do trzba.cmd přidán příkaz .rmlib a podmíněný chod jedna posílka/dávka.
********************
25.11.2016
Na základě zkušenosti pan Šolce upozorňuji, že použití knihovny v trzba.cmd je nutno
dát někam na začátek vašeho programu nebo nezpomenout použít příkaz .rmlib!
*********************
19.11.2016
Pokud za současný tvar příkazu .direct_mail přidáte parametr "SSL", dojde
k vyslání pošty přes port=465 se SSL zabezpečením. Pokud přidáte "SSL",ddd
dojde k vyslání pošty přes port=ddd se SSL zabezpečením.

Rozšíření příkazu provedeno na základě výzkumu ing. Čampuly z Cornus
České Budějovice.
*********************
13.11.2016
Explicitně to není v dokumentaci uvedeno, ale přepokládá se, že v .direct_mail je
předmět a přní soubor obshaující text dopisu v KOI a interně se převádí do kódu
Windows. Přílohy zůstavají beze změny.
*********************
08.11.2016
Protože v EET vadily koncové mezery za texty, doplněno v EML při přepínači CA
odstranění koncových mezer za řetězci.
*********************
Podíval jsem se na ověření účtenky a je to paskvil. Jednak se požaduje datum a čas
tržby, ale v neznámém formátu - snad to co dělá eett(0)?, dále částku, kousek FIKU 16 znaků
kousek BKP 16 znaků. Přitom, jak jsem uvedl výše, by stačilo uvést DIČ a číslo účtenky
(posílá se na FS v rámci eet). Datum, čas, částka by na zákazníka vypadla z evidence
tržeb. PKP a BKP je naprosto zbytečné - stačí DigestValue SHA256 ze SOAP hlavičky. Navíc v PG
režimu jsem konstatoval, že na kontrolu PKP kašlou, stačí zadat nějakých 343 znaků a správně
z toho spočítat SHA1 hash = BKP a odměnou byl FIK.

Správně by podle veřejného klíče v účtence měli udělat decrypt PKP a dostat SHA256 hash
z PKP.txt a pak sami udělat SHA256 z PKP.txt a porovnat na shodu. To dělám v rámci
.verify na odpověď z FS. Tam je ale pouze DigestValue a podpis SOAP hlavičky zahrnující
i DigestValue. Kdyby to mělo být symetrické, pak by v odpovědi měli mít také PKP i BKP!

Takže si v podstatě "kálejí" do vlastního hnízda, protože i kontroloři budou musit takové
kvantum údajů vyplnit, aby zjistili, že podnikatel nepodvádí a účtenka je v evidenci.

Přitom jak jsem psal ze znalosti BKP nemůže FS jednoznačně identifikovat účtenku, vzhledem
k nenulové pravděpodobnosti, že dva různé PKP.TXT budou mít stejný hash. Pokud by FIK
byl jednoznačný a ne zřejmě náhodný kód, stačil by ten. 9 cifer je miliarda účtenek, 16
cifer - které je nutno zadat dá 10**16 účtenek, což by stačilo na staletí.

Stále mně z těchto úvah vyplývá, že DIČ/IČO + číslo účtenky (může obsahovat v úvodu
číslo pracoviště či pokladny) je neprůstřelné při ověření a nejjednoduší. Proč ale
dělat věci jednoduše, když to jde složitě, a tak "odborníci" na FS mají pocit, že za
ty milony dostali odpovídajícně náročný produkt.
*********************
05.11.2016
Dnes jsem četl, jak bude pro kupujícího obtížné dohledat z účtenky na portálu FS
zda tam je či není - je nutno zadat spoustu údajů. Přitom zobrazení PKP.TXT do
PKP.B64 není prosté, tj. nekonečně mnoho PKP.TXT má stejné PKP.B64. Totéž platí
o přiřazení PKP.BIN k BKP.BIN - výstup je kratší než vstup.

Prostý selský rozum dává přednost údaji DIČ+číslo účtenky. Po zadání kupujícím
těchto dvou údajů by na něj vyběhlo datum a částka (správná nebo jiná) nebo nic. Toť vše.
*********************
Protože je problematické jak uchovat v tajnosti heslo k certifikátu, provedl
jsem dnes změnu v tom smyslu, že doporučuji pro heslo_out použít heslo_in
- uživatel ho musí zadat v rámci FIX.cmd a nikam ho neukládat, protože
DGST ho nyní nepotřebuje (heslo_out je použito pouze k tvorbě PKP.PEM). Heslo v DGST
může být nyní zcela libovolné, protože se interně neuplatní.
*********************
Po konzultaci s fy JUMP byly ve fix.cmd upraveny kódy chyb z cc na dd a prodloužen
text chyby na 100 znaků. Dále do fix.cmd přidána reakce na chybu .pkcs12_pem a
v trzba.cmd na chybu v DGST. V obou případech by mohla nastat v případě poškození
pkp.pem nebo zadáním neplatného hesla.
*********************
02.11.2016
Do trzba.cmd přidáno overeni=true a do inieet odkaz na produkční prostředí.
Ostré certifikáty to nyní akceptuje.
*********************
01.11.2016
Dnes po 14. hodině se zřejmě rozjel web pro EET

https://prod.eet.cz:443/eet/services/EETServiceSOAP/v3

a bere to vygenerované individuální certifikáty.
*********************
Do DGST přidány chyby:

424 zkomolený pkp.pem
425 asi nesprávné heslo
*********************
31.10.2016
Opravena indikace letní/zimní čas. Nový Fix.cmd a Trzba.cmd obsluhující chybu i varování,
nefunkční internet a nový tvar chybové odpovědi. Rovněž využita nová funkce verify,
zkontrolující platnost podpisu SOAP hlavičky a digest BODY,
*********************
30.10.2016
S pravděpodobností 4 promile funkce .bintohex dala špatný výsledek. To se projevilo
na neplatném BKP kódu.
*********************
28.10.206
Do pkcs12_pem přidáno standardní volání chyby

422 nesprávný KS certifikátu
423 neznámá struktura certifikátu
*********************
19.10.2016
Byl upraven příkaz .pkcs12_pem, aby akceptoval nový tvar vzorových certifikátů.

Byla provedena úprava záhlaví struktur XMLRDA pro zajištění kompatibility 32 a 64
bitových Windows. POZOR!! na 32 bitech není zpětná kompatibilita!
*********************
Umím zajistit kompatibilitu XMLRDA, ale jen za cenu ztráty zpětné kompatibility k již
vytvořeným XMLRDA v 32 bitové verzi. Bude to činit nějaké zásadní obtíže?
*********************
11.10.2016
Upraven fix.cmd, aby bežel i v 64 bitové verzi. Bohužel je momentálně XMLRDA v 32 a 64
bitove verzi nekompatibilní, což jsem do dnešního dne netušil.
*******************
07.10.2016
Protože se množí případy, kdy ve Windows je vypnuta tvorba jmen 8.3, dal jsem na zkoušku
do wr585 detekci tohoto stavu a automaticky zapínám .enable long_name2.

Přirozeně v takovém systému selže .next jm,<soubor>, protože dlouhá jména zmrší fixní
řádek a po .enable long_name2 se vrací pouze jméno. Tedy tak jako tak program by nejel
správně.

Test na existenci/neexistenci 8.3 můžete nyní provést:

.onerr #; .getkey hodn,"HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/FileSystem=NtfsDisable8dot3NameCreation"
.if(error) "Neexistuje"; .else "Existuje"
;1 neni 0 je 8.3 'hodn'
*******************
26.09.2016
Zprovozněny čárové kódy v pdf souborech generovaných TBN.
*******************
21.09.2016
Ing. Polida má potvrzenou odpověď na dotaz, kdy je možno začít používat individuální
certifikáty. Je to až od 1.11.2016! Do té doby jsou tedy nefunkční.
*******************
21.09.2016
Příklad řešení v eet.zip je rozšířen o inieet.cmd s cestami na různé složky
dat a exe. Doplněna též indikace místa spuštění FIX nebo TRZBA, takže INIEET
a CUT se správně spustí, pokud jsou všechny CMD v jednom adresáři.

Zjistil jsem po letech, že $logdev a $loguic jsou lokální proměnné, takže jsem
je zglobalizoval. Doufám, že jsem tím někomu něco nesestřelil.
*******************
20.09.2016
V eet.zip nyní trzba.cmd rozšířená o kontrolu hlavičky SOAP a DIGEST Body. Nutno
poslední stav wr585 a přibyla knihovna cut.cmd.
*******************
10.09.2016
Do příkazu .wait byla přidána událost "kd" = keydown. Nastane při stisku znakové
klávesy.

Takže např. pro .put $key,"a" nenastane, po stisku klávesy "a" nastane. Lze tedy
rozlišit psaní na klávesnici od zaslání znaků např. ze scaneru snímající EAN kódy.
*******************
09.09.2016
Nevím přesně čím je to způsobeno, ale WR584 je překvapivě o 25 kB větší než
WR585 obsahující navíc práci s certifikáty a SHA1 a SHA256 hash.
*******************
02.09.2016
Žádná záhada se nekonala. Pokud měl podpis určitý konec, interně WR předpokládalo,
že je zašifrovaný a odšifrovalo ho na pozadí. Takže vstup do .crypt_hash byl pak
nesmyslný. Protože to předcházelo i volání API Microsoft, dopadlo to stejně špatně.
*******************
02.09.2016
EET se nám začíná zamotávat. Jednak komunikace s centrem je zcela na kočku a
za druhé, SHA1 Microsoft a moje SHA1 dává pro malý počet případů jiný výsledek
než openssl (playground bere openssl) a za třetí openssl i já pro DGST pro
malý počet případů, kdy podpis vyjde s úvodními nulami, je pak výsledek pro
base64 340 a ne 344 znaků, což playground nebere. To jsem u sebe napravil,
že vedoucí nuly v podpisu ponechávám. Zbývá tedy upravit moje SHA1 tak, aby
se shodovalo s openssl.
*******************
23.08.2016
Vedlejším efektem příkazu .pkcs12 je soubor platnost.txt vytvořen v adresáři
kam směřujete soubor.pem. V něm jsou data začátku a konce platnosti ve tvaru:

rrmmddhhmmss

*******************
23.08.2016
Ve wr585+eet se projevila chyba nedodtatečné velikosti deklarace, takže dgst
padalo. V trzba.cmd zůstal hash podle openssl a do curl přidán timeout 10 s.
*******************
16.08.2016
Na webu je www.redap.cz/eet.zip se zapracovanými novými příkazy ve wr585,
takže se EET objede bez openssl.exe.
*******************
12.08.2006
Nový příkaz je:

.dgst "<certifikát.pem>","<heslo>","<soubor k podpisu>",Sprom

v Sprom je podpis hash vstupu dle SHA256 ve tvaru Base64 bez CRLF.
*******************
12.08.2016
Tak to vypadá, že jsem ve WR585 schopen podepisovat, takže openssl již netřeba.
WR585 nakynul o 20 kB, tedy celkem o 35 kB.
*******************
28.07.2016
Tak se podařilo zmermomocnit tvorbu PEM souboru, i když to mělo zůstat tajemstvím
autorů openssl. Nicméně to stálo týden různých pokusů a hledání, než jsem
oklikou dospěl k způsobu zašifrování soukromého klíče v PEM souboru. Máme tedy
nový příkaz:

.pkcs12_pem "c:\wr585\eet\01000003.p12","eet","eett","c:\wr585\eet\pkb.pem"

tedy certifikát, původní heslo, nové heslo a jméno PEM souboru.

Podle předpokladu se WR nafoukl pouze o 15 kB, původní pkcs12 bez šifrování! měl
1.5 MB.

Před časem jsem naprogramoval SHA1. V poslední fázi jsem si řekl, že raději použiji
SHA1 ve Windows API. Nic zlého netuše, jsem pak pustil nový příkaz a WR se zakousl.
Po delší době mně došlo, že SHA1 z API je nesmírně pomalé a tak několik cyklů
po 2048 opakování trvalo cca 30 s, zatímco moje SHA1 to zvládne téměř okamžitě.
*******************
16.07.2016
Soukromý klíč odšifrován. Nevím k čemu mně to bude, nicméně je to šílenost.
Na základě hesla EET je vygenerován 20 znakový hash a pak ještě jeden 24 znakový.
Poslední 4 znaky se generují přes aritmetiku velkých čísel. 24 znakový klíč se
rozdělí na 3x8 znaků a každá osmice generuje nějak 64 32 bitových numer. Pak se
nějak přes stovky posunů a permutací ještě za pomoci 20 znakového klíče a tabulky se
stovkami hodnot rozšifruje zašifrovaná sekce soukromého klíče. Je to jakási
šifra 3DES. Nejhorší na tom je, že to zřejmě funguje tam i zpátky!
*******************
12.07.2016
Naučil jsem se odšifrovat PKCS7 formát v PKCS12 struktuře. Přirozeně pro jednu
konkrétní šifru RC2-40 bitů. Nyní mne čeká ještě se naučit rozšifrovat soukromý
klíč v PKCS12 struktuře.
*******************
08.07.2016
První krok se podařil. Dosáhl jsem rozdělení DER struktury, vydělení šifrované
části a 8 bajtového a 20 bajtového hash a pak série Sha1 aplikací na různé
struktury až z toho vypadne shoda s těmi 20 byty uloženými v *.p12 struktuře.

Přirozeně je to boj, protože drobné nepochopení nebo drobná chyba vede
k hash se zcela jiným obsahem bez možnosti zjistit přímo příčinu neshody.
Zatím WR nakynul o cca 1 kB.

Nyní další úkol je odšifrovat zašifrovanou část.
*******************
06.07.2016
Nedalo mně to a zabývám se luštěním formátu PKCS12. Využívám k tomu PKCS12.exe
sestavené jako podmnožinu OPENSSL o velikosti cca 1.5 MB. Vše autoři pojímají
nesmírně obecně, rozehrávají do krajnosti možnosti C++. Studium je tudíž velmi
obtížné a zdlouhavé. Udělal jsem první dílčí krok, kdy jsem vlastní silou
vygeneroval jakýsi MAC klíč pro ověření neporušenosti certifikátu.

Rutina pro rozkódování DER struktury má momentálně 24 řádků a využití jedné
části struktury a generace MAC klíče má 25 řádků. Jdu tedy bez nějakých oklik
přímo na věc, užívám pár hotových věcí ve WR a šetřím tak stovky řádků původního
kódu. Místo zanoření rutin cca do 10. úrovně mám pouze jedinou rutinu.

Šifrování PKCS12 není nikde publikováno (alespoň jsem nic nenašel) a jedná se
o dílo "šíleného programátora", který se snaží použít takové množství kroků, aby to
nebylo vysledovatelné. Např. závěr generace MAC klíče spočívá v postupném
2047x zopakované aplikaci SHA1 na předchozí hash SHA1. Přitom v případě
zjištění nutnosti provedení takového cyklu je lhostejné zda je do řetězce
postupných kroků vložen nebo ne. Napsat 2047x provedení SHA1 hash "na sebe sama"
zvládne napsat pak každý blbec:

for(i=0; i<2047; i++) Sha1(hsh,hsh,20);

Netuším, zda to psychicky vydržím, ale předpokládám, že při dosažení cíle, tj.
vygenerování PEM struktury z PKCS12 formátu nakyne WR řádově o desíky kB. Nebudu
přirozeně umět tolik věcí jako PKCS12.EXE, ale pro účely EET nic dalšího
nepotřebujeme.

pkcs12 -passin pass:eet -passout pass:eett -in 01000003.p12 -out pkp.pem

Přesně tohle a nic jiného bych byl rád, aby WR zvládl.
*******************
02.07.2016
?? Má cenu ještě pracovat na EET. Momentálně jsme schopni za využití openssl a
curl vytvořit elektronickou účtenku se dvěma digest a dvěma podpisy podle dodaného
certifikátu, přijmout a vyhodnotit odpověď.

Pomýšlel jsem na likvidaci openssl a přesunutí funkce podpisu do WR. To odhaduji
minimálně na dva měsíce pilné práce. Zatím jsem zkoušel upravit základ aritmetiky
velkých čísel, což se dařilo s redukcí rutin minimálně na 30% původního rozsahu.
Střeva openssl nejsou psána s nějakou velkou programátorskou erudicí. Ve mně
i v 70 letech dřímou základy, kdy se člověk především musil vejít z dnešního
pohledu do operační pidipaměti. Zdroje openssl mají 24 MB (WR 5.5 MB) a vlastní
EXE je o 30% menší než WR po 35 letech úprav.

Zkušenost se zipováním byla, že jsem potřebné zdroje zredukoval na 10% původní
délky. (Hlavní část redukce spočívala v likvidaci zbytečných rutin v kódu.)
*******************
30.06.2016
Uchodil jsem v ATP dosazovací příkazy, které dosud nefungovaly:

s:=o.Envelope\Body\Id
;'s'
n=o.Envelope\Header\Security\Signature\SignedInfo\Reference\DigestValue
;'n'

tj. převzetí hodnot z otevřené XMLRDA - zde "o".
*******************
28.06.2016
Pro funkčnost EET tržeb je třeba CURL 32 bitů - najdete na

http://winampplugins.co.uk/curl/

Pozor! certifikát v download je nutný!
*******************
26.06.2016
Dnes po 13. hodinové šichtě se konečně podařilo vyrobit a poslat účtenku a dostat příznivou
odpověď. Postupně padly tajemné hodnoty bkp, pkp, DigestValue a SignatureValue. Musil jsem
přečíst a pochopit taje Exkluzivní kanonizace a Podepisování. Nicméně zatím za podpory

openssl.exe - podepisování
curl.exe - posílání

Největší dík v tmto martiriu ale patří aparátu ATP!
*******************
25.06.2016
Pokud uvažujete o nutnosti aplikovat EET ve vašem software, pak si stáhněte

http://osdn.jp/projects/sfnet_gnuwin32/downloads/openssl/0.9.8h-1/openssl-0.9.8h-1-bin.zip/

*******************
24.06.2016
Zatím se dost peru s tvorbou soap obálky EET. Zatímco podpis a digest podpisu přímo
v tržbě závisel jen na získání vhodné openssl.exe, digest v soap obálce je tvořen
až po exkluzivní kanonizaci XML. Přečetl jsem řadu pojednání a dnes se mně se štěstím
podařilo XML správně zkanonizovat a digest konečně vyšel. Musíte si uvědomit, že
digest SHA256 je 32 bajtové číslo, které se při odchylce v jednom znaku vzoru, liší
úplně na všech pozicích!

Na základě tohoto výsledku jsem se musil ještě porýpat v %EML a přidat mezi jiným
přepínač CA - kanonizovat. Ovšem exkluzivní kanonizaci lze provést až v ATP.

Teď mně zbývá se poprat s podpisem digestu, což je opět velká věda, protože digest se musí
obalit různou vatou a pak podepsat. Platí totéž co u digestu - odchylka v jednom znaku
se rovná odlišností tentokrát na 256 bajtech výsledku.
*******************
V www.redap.cz/EET.ZIP je RSD odpovidající popsané struktuře.
*******************
09.06.2016
Do WR585 po .test $net doplněna tvorba proměné $uuid obsahující UUID ve smyslu požadavkům
EET. Cifra M je vždy 4 - náhodné číslo.
*******************
03.06.2016
Trochu se rýpu v kryptografii a prohlížím rutiny z různých zdrojů. RSA šira
je dost náročná. Jde o to, umocnit hash SHA256 (64 hexa cifer) na 65537 a mocninu
oříznout modulo číslem s 256 ciframi. Jsou na to kilometry kódu i s využitím různých
poznatků od různých chytrých pánů včetně pana Fermanta a Eulera - publikoval v roce
1764!!!
*******************
02.06.2016
Nešlo v ARI editovat textovou položku, pokud byla hodnotou uzlu - odporuje
standardnímu hieararchickému modelu. V EET je to pkp a bkp.
*******************
25.05.2016
Příkaz .crypt_hash je obohacen o SHA256 hashing - výsledek 32 bajtů.

.bopenw text.txt
.bwrite 0,"abc"
.close
.crypt_hash "text.txt","SHA256","sha256.hsh"
.bintohex "sha256.hsh","sha256.hex"
type sha256.hex
*******************
21.05.2016
Zavedena funkce EETT(0) - numerický parametr nemá zatím význam produkující
řetězec dle požadavku na určení času v EET

2016-05-21T07:12:50+01:00

dle okamžitého času PC. Timezone je uvažována.
*******************
18.05.2016
Jako přípravu na podporu EET jsem doplnil příkazy:

.bintohex "<binární soubor>","<hexa soubor>"

a

.hextobin "<hexa soubor>","<binární soubor>"

a položka <bkp> dle příkladu na webu se vytvoří v souboru p1.hex:

.open pkp.txt
.enable data
Ca8sTbURReQjjgcy/znXBKjPOnZof3AxWK5WySpyMrUXF0o7cz1BP6adQzktODKh2d8s
oAhn1R/S07lVDTa/6r9xTuI3NBH/+7YfYz/t92eb5Y6aNvLm6tXfOdE3C94EQmT0SEEz
9rInGXXP1whIKYX7K0HgVrxjdxCFkZF8Lt12XbahhAzJ47LcPxuBZZp6U6wJ2sWI5os3
KY9u/ZChzAUaCec7H56QwkMnu3U3Ftwi/YrxSzQZTmPTpFYKXnYanrFaLDJm+1/yg+VQ
ntoByBM+HeDXigBK+SHaxx+Nd0sSmm1Im4v685BRVdUId+4CobcnSQ3CBsjAhqmIrtWT
GQ==
.close
.crypt_decode "pkp.txt","pkp.bin"
.crypt_hash "pkp.bin","SHA1","p1.hsh"
.bintohex "p1.hsh","bkp.hex"
type bkp.hex

Z tohoto pohledu se mně nezdá pravděpodobné, že by současné autonomní
pokladny, instalované v obchodech, zvládly EET, jak tvrdí pan ministr Babiš.
******************
12.05.2016
Často je třeba vícenásobnou substituci rozložit do více příkazů, neboť najednou to
neprojde. Proto jsem učinil pokus zlegalizovat do sebe zanořenou substituci:

s1:="adr"
x2:="1"
n=2
's'x'n''':="Nazdar"
;'adr'

Vyhodnocení probíhá 's' - zjistí, že tomu nerozumí, pokračuje dál a zjistí, že
'x' nerozumí. Pokračuje dál a zjistí, že 'n' je 2. Vznikne tedy

's'x2''

vrátí se tedy na pozici předchozího apostrofu a konstatuje, že 'x2' je 1
Vznikne tedy:

's1'

Vrátí se tedy opět na pozici předchozího apostrofu a zjisí, že 's1' je "adr"
a příkaz se provede.
******************
19.04.2016
Zdá se, že alespoň v prvním přiblížení jede

grdwin(+0,0,0,32,100,<13713>,<11713>,"Prohlížení RDA")
grd uziv
******************
15.04.2016
Dokončuji příkaz grdwin - analogie s ediwin.
******************
09.04.2016
Odstraněna celá řada problémů "od jakživa" ve wr584.

V ediwin odstraněn problém při Alt F - menu se vykreslilo do základního okna.

V parametrech ediwin za úvodní závorku je možno dát rámečkový znak (jednoduchý
i dvojitý jsou ve své funkci totožné) pro umístění okna na obrazovce.

ediwin(+0,0,0,5,20,<13733>,<11709>,"Editace")

Okno bude vycentrováno na obrazovce.
******************
01.04.2016
Jednak ediwin+EDI/PRO se chová nyní jako celek, tj. po ukončení EDI/PRO se zlikviduje
automaticky i win okno a jednak jsem odstranil několik problémů, které se při testování
vyskytly i s ohledem na Win7 a výše. (Moje nejmilejší je stále Win XP.)
******************
29.03.2016
Po značném úsilí se zadařilo zobecnit okno .ediwin tak, že okno EDI/PRO má nápovědný
řádek na kalkulačku a je v režimu "normal" podle zadané velikosti okna. Pak
reaguje na maximalizaci a obnovení rozměrů a též na roztahování okna pomocí
tažením za strany okna myší. Po změně rozměrů se EDI/PRO přepočítá a zaplní zcela
nové okno. Funguje zobrazování části posledního řádku a posledního neúplného
sloupce.
******************
03.03.2016
Ve VST existuje léta dobře utajený přepínač bp:fnt1:fnt2. První font se ve VST
aplikuje na texty i před položkami a druhý na vlastní položky. Upozornil mně na to
ing. Novák. Přiznám se, že jsem o této úpravě již neměl ani tušení.
******************
02.03.2016
Protože se obtížně navrhuje winwin okno pro editor, přidal jsem příkaz

ediwin(0,Rd,Sl,Prd,Psl,bar,barr,"<Nadpis okna">)

kde souřadnice jsou řádkové a ne pixlové. Takže například:

ediwin(0,1,1,5,20,<13733>,<11709>,"Editace")
edi p.cmd
.remwin()
.ask u Povedlo se?

Přirozeně ediwin je určen (a možná předvším) pro PRO.
******************
29.02.2016
Zatím nemám žádný vážnější námět vývoje do WR585. Přemýšlím o realizaci víceřádkového
menu, tj. jedna věta na více řádcích. Zatím je delší řádek realizován přes bublinku
generovanou textem za vlnovkou. Užilo by se to?
******************
23.02.2016
Problém s odkazy v 64 bitovém WR pro správu emulace původní EMS paměti v DOSu vedly
k přechodu od homogenního pole ke dvěma strukturám, což je přirozeně drastický zásah
do kódu. Nicméně se jedná o preventivní opatření, protože se dosud žádný problém
s využitím paměti neobjevil.
******************
13.02.2016
Mírně upavena instrukce CSV. Jednak při přepínači RE a AI:0 se správně první řádek
vzal jako hlavička, ale zároveň se načetl jako první řádek do RDA. Dále z důvodu úspory
místa byl pro sloupec s texty nepřesahující 255 znaků použit typ RV, což někdy škodí.
Proto při použití přepínače RE:2 se vždy použije RE a RV tedy v definici zmizí.
******************
10.02.2016
Vzhledem k tomu, ze umíme interně dekompresi, zkusil jsem rýpnout do souborů XLSX.
Vyrobil jsem instrukci XLS a naučil ji zjistit seznam prázdných listů a vyplněných
listů v tomto souboru. Syntaxe

%xls
sh.
<soubor>.xlsx
%
;Prázdné listy: '$list0'
;Vyplněné listy: '$list1'

Protože podobného výsledku se dá dosáhnout i přes ODBC, nevím, zda by pokračování
ve vytěžování XLSX mělo nějaký smysl.
******************
03.02.2016
Na webu je a bude wr585d.zip s wr585.exe - časově omezené demo do 30.06.2016.
******************
02.02.2016
Zkusmo jsem porušil zásadu programově nesahat na myšovou šipku v případě menu, kdy
pravítko sleduje myšovou šipku. Použijeme-li ale kolečko myši nebo šipky na klávesnici,
pak se pravítko posouvá a šipka stojí. Při nepatrném pohybu myší, se pak pravítko z právě
vybraného řádku vrátilo pod kurzor myši.

Zkusil jsem v připadě, že myšová šipka je uvnitř okna menu zajistit i naopak, že šipka
myši sleduje automaticky pravítko. Navíc jsem přidal, že stisknutím kolečka myši dojde
k výběru řádku.
******************
17.01.2016
Na PC s více jak 4 GB operační paměti 64 bitový WR nemusel pracovat správně. Na několika
místech se totiž pracuje s ukazateli na 4 bajty (do 4 GB) místo s 8 bajty, jak je to
kompilátorem zajištěno při překladu do 64 bitové verze. To jsem snad všude napravil.
******************
13.01.2016
Ve zdrojích WR odstraněno cca 1000 varování - letitý a odkládaný problém.