ಎಲ್ಲರಿಗೂ ನಮಸ್ಕಾರ.
ನಾವು, ವಿಕ್ಟರ್ ಆಂಟಿಪೋವ್ ಮತ್ತು ಇಲ್ಯಾ ಅಲೆಶಿನ್, ಇಂದು ಪೈಥಾನ್ PyUSB ಮೂಲಕ USB ಸಾಧನಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ನಮ್ಮ ಅನುಭವದ ಬಗ್ಗೆ ಮತ್ತು ರಿವರ್ಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಮಾತನಾಡುತ್ತೇವೆ.
ಪೂರ್ವೇತಿಹಾಸದ
2019 ರಲ್ಲಿ, ರಷ್ಯಾದ ಒಕ್ಕೂಟದ ಸರ್ಕಾರದ ತೀರ್ಪು ಸಂಖ್ಯೆ 224 “ತಂಬಾಕು ಉತ್ಪನ್ನಗಳನ್ನು ಗುರುತಿಸುವ ವಿಧಾನಗಳೊಂದಿಗೆ ಲೇಬಲ್ ಮಾಡುವ ನಿಯಮಗಳ ಅನುಮೋದನೆ ಮತ್ತು ಗುರುತಿನ ವಿಧಾನಗಳೊಂದಿಗೆ ಕಡ್ಡಾಯವಾಗಿ ಲೇಬಲಿಂಗ್ಗೆ ಒಳಪಟ್ಟಿರುವ ಸರಕುಗಳ ಪ್ರಸರಣವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ರಾಜ್ಯ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಯ ಅನುಷ್ಠಾನದ ವೈಶಿಷ್ಟ್ಯಗಳು ತಂಬಾಕು ಉತ್ಪನ್ನಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ” ಜಾರಿಗೆ ಬಂದಿತು.
ಜುಲೈ 1, 2019 ರಿಂದ ತಯಾರಕರು ತಂಬಾಕಿನ ಪ್ರತಿ ಪ್ಯಾಕ್ ಅನ್ನು ಲೇಬಲ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ ಎಂದು ಡಾಕ್ಯುಮೆಂಟ್ ವಿವರಿಸುತ್ತದೆ. ಮತ್ತು ನೇರ ವಿತರಕರು ಈ ಉತ್ಪನ್ನಗಳನ್ನು ಸಾರ್ವತ್ರಿಕ ವರ್ಗಾವಣೆ ಡಾಕ್ಯುಮೆಂಟ್ (ಯುಡಿಡಿ) ಕಾರ್ಯಗತಗೊಳಿಸುವುದರೊಂದಿಗೆ ಸ್ವೀಕರಿಸಬೇಕು. ಅಂಗಡಿಗಳು, ಪ್ರತಿಯಾಗಿ, ನಗದು ರಿಜಿಸ್ಟರ್ ಮೂಲಕ ಲೇಬಲ್ ಮಾಡಿದ ಉತ್ಪನ್ನಗಳ ಮಾರಾಟವನ್ನು ನೋಂದಾಯಿಸಿಕೊಳ್ಳಬೇಕು.
ಅಲ್ಲದೆ, ಜುಲೈ 1, 2020 ರಿಂದ, ಲೇಬಲ್ ಮಾಡದ ತಂಬಾಕು ಉತ್ಪನ್ನಗಳ ಪ್ರಸರಣವನ್ನು ನಿಷೇಧಿಸಲಾಗಿದೆ. ಇದರರ್ಥ ಎಲ್ಲಾ ಸಿಗರೇಟ್ ಪ್ಯಾಕ್ಗಳನ್ನು ವಿಶೇಷ ಡೇಟಾಮ್ಯಾಟ್ರಿಕ್ಸ್ ಬಾರ್ಕೋಡ್ನೊಂದಿಗೆ ಗುರುತಿಸಬೇಕು. ಇದಲ್ಲದೆ - ಒಂದು ಪ್ರಮುಖ ಅಂಶ - ಡಾಟಾಮ್ಯಾಟ್ರಿಕ್ಸ್ ಸಾಮಾನ್ಯವಲ್ಲ, ಆದರೆ ವಿಲೋಮವಾಗುವುದಿಲ್ಲ. ಅಂದರೆ, ಬಿಳಿಯ ಮೇಲೆ ಕಪ್ಪು ಕೋಡ್ ಅಲ್ಲ, ಆದರೆ ಪ್ರತಿಯಾಗಿ.
ನಾವು ನಮ್ಮ ಸ್ಕ್ಯಾನರ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳನ್ನು ರಿಫ್ಲಾಶ್ ಮಾಡಬೇಕಾಗಿದೆ/ಮರುತರಬೇತಿಗೊಳಿಸಬೇಕಾಗಿದೆ, ಇಲ್ಲದಿದ್ದರೆ ಅವರು ಈ ಬಾರ್ಕೋಡ್ನೊಂದಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಘಟನೆಗಳ ಈ ತಿರುವು ನಮಗೆ ತೀವ್ರ ತಲೆನೋವು ಖಾತರಿಪಡಿಸಿದೆ, ಏಕೆಂದರೆ ನಮ್ಮ ಕಂಪನಿಯು ವಿಶಾಲವಾದ ಭೂಪ್ರದೇಶದಲ್ಲಿ ಹರಡಿರುವ ಬಹಳಷ್ಟು ಮಳಿಗೆಗಳನ್ನು ಹೊಂದಿದೆ. ಹಲವಾರು ಹತ್ತು ಸಾವಿರ ನಗದು ರೆಜಿಸ್ಟರ್ಗಳು - ಮತ್ತು ಬಹಳ ಕಡಿಮೆ ಸಮಯ.
ಏನು ಮಾಡಬೇಕಿತ್ತು? ಎರಡು ಆಯ್ಕೆಗಳಿವೆ. ಮೊದಲನೆಯದು: ಆನ್-ಸೈಟ್ ಎಂಜಿನಿಯರ್ಗಳು ಸ್ಕ್ಯಾನರ್ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ರಿಫ್ಲಾಶ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಹೊಂದಿಸುತ್ತಾರೆ. ಎರಡನೆಯದು: ನಾವು ರಿಮೋಟ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಮೇಲಾಗಿ, ಒಂದೇ ಪುನರಾವರ್ತನೆಯಲ್ಲಿ ಅನೇಕ ಸ್ಕ್ಯಾನರ್ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಕವರ್ ಮಾಡುತ್ತೇವೆ.
ಮೊದಲ ಆಯ್ಕೆ, ನಿಸ್ಸಂಶಯವಾಗಿ, ನಮಗೆ ಸೂಕ್ತವಲ್ಲ: ಭೇಟಿ ನೀಡುವ ಎಂಜಿನಿಯರ್ಗಳಿಗೆ ನಾವು ಹಣವನ್ನು ಖರ್ಚು ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಮತ್ತು ಸಂಘಟಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಆದರೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಜನರು ಕೆಲಸ ಮಾಡುತ್ತಾರೆ, ಅಂದರೆ, ನಾವು ಸಾಕಷ್ಟು ದೋಷಗಳನ್ನು ಸಂಭಾವ್ಯವಾಗಿ ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ, ಗಡುವನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ.
ಎರಡನೆಯ ಆಯ್ಕೆಯು ಎಲ್ಲರಿಗೂ ಒಳ್ಳೆಯದು, ಒಂದು ವಿಷಯಕ್ಕಾಗಿ ಅಲ್ಲ. ಕೆಲವು ಮಾರಾಟಗಾರರು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ರಿಮೋಟ್ ಮಿನುಗುವ ಸಾಧನಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಮತ್ತು ಗಡುವು ಮುಗಿದ ಕಾರಣ, ನಾನು ನನ್ನ ಸ್ವಂತ ತಲೆಯಿಂದ ಯೋಚಿಸಬೇಕಾಗಿತ್ತು.
ಮುಂದೆ, ಡೆಬಿಯನ್ 9.x ಓಎಸ್ಗಾಗಿ ಹ್ಯಾಂಡ್-ಹೆಲ್ಡ್ ಸ್ಕ್ಯಾನರ್ಗಳಿಗಾಗಿ ನಾವು ಪರಿಕರಗಳನ್ನು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಎಂದು ನಾವು ನಿಮಗೆ ಹೇಳುತ್ತೇವೆ (ನಮ್ಮ ಎಲ್ಲಾ ನಗದು ರೆಜಿಸ್ಟರ್ಗಳು ಡೆಬಿಯನ್ನಲ್ಲಿವೆ).
ಒಗಟನ್ನು ಪರಿಹರಿಸಿ: ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಹೇಗೆ ಫ್ಲಾಶ್ ಮಾಡುವುದು
ವಿಕ್ಟರ್ ಆಂಟಿಪೋವ್ ವರದಿ ಮಾಡಿದ್ದಾರೆ.
ಮಾರಾಟಗಾರರಿಂದ ಒದಗಿಸಲಾದ ಅಧಿಕೃತ ಉಪಯುಕ್ತತೆಯು ವಿಂಡೋಸ್ ಅಡಿಯಲ್ಲಿ ಮತ್ತು IE ಯೊಂದಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಉಪಯುಕ್ತತೆಯು ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಫ್ಲ್ಯಾಷ್ ಮಾಡಬಹುದು ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.
ನಮ್ಮ ಗುರಿ ವ್ಯವಸ್ಥೆಯು ಡೆಬಿಯನ್ ಆಗಿರುವುದರಿಂದ, ನಾವು ಡೆಬಿಯನ್ನಲ್ಲಿ ಯುಎಸ್ಬಿ-ರೀಡೈರೆಕ್ಟರ್ ಸರ್ವರ್ ಮತ್ತು ವಿಂಡೋಸ್ನಲ್ಲಿ ಯುಎಸ್ಬಿ-ರೀಡೈರೆಕ್ಟರ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ. ಯುಎಸ್ಬಿ-ರೀಡೈರೆಕ್ಟರ್ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ಲಿನಕ್ಸ್ ಯಂತ್ರದಿಂದ ವಿಂಡೋಸ್ ಯಂತ್ರಕ್ಕೆ ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ್ದೇವೆ.
ವಿಂಡೋಸ್ ಮಾರಾಟಗಾರರಿಂದ ಉಪಯುಕ್ತತೆಯು ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ನೋಡಿದೆ ಮತ್ತು ಅದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಫ್ಲ್ಯಾಷ್ ಮಾಡಿದೆ. ಹೀಗಾಗಿ, ನಾವು ಮೊದಲ ತೀರ್ಮಾನವನ್ನು ಮಾಡಿದ್ದೇವೆ: ಯಾವುದೂ OS ಅನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ, ಇದು ಮಿನುಗುವ ಪ್ರೋಟೋಕಾಲ್ನ ವಿಷಯವಾಗಿದೆ.
ಸರಿ. ನಾವು ವಿಂಡೋಸ್ ಗಣಕದಲ್ಲಿ ಮಿನುಗುವಿಕೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಲಿನಕ್ಸ್ ಯಂತ್ರದಲ್ಲಿ ಡಂಪ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ.
ನಾವು ಡಂಪ್ ಅನ್ನು ವೈರ್ಶಾರ್ಕ್ನಲ್ಲಿ ತುಂಬಿದ್ದೇವೆ ಮತ್ತು... ದುಃಖವಾಯಿತು (ನಾನು ಡಂಪ್ನ ಕೆಲವು ವಿವರಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತೇನೆ, ಅವುಗಳು ಯಾವುದೇ ಆಸಕ್ತಿಯನ್ನು ಹೊಂದಿಲ್ಲ).
ಡಂಪ್ ನಮಗೆ ಏನು ತೋರಿಸಿದೆ:
ವಿಳಾಸಗಳು 0000-0030, ವೈರ್ಶಾರ್ಕ್ ಮೂಲಕ ನಿರ್ಣಯಿಸುವುದು, USB ಸೇವಾ ಮಾಹಿತಿಯಾಗಿದೆ.
ನಾವು 0040-0070 ಭಾಗದಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ.
MOCFT ಅಕ್ಷರಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಒಂದು ಪ್ರಸರಣ ಫ್ರೇಮ್ನಿಂದ ಏನೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಈ ಅಕ್ಷರಗಳು ಫರ್ಮ್ವೇರ್ ಫೈಲ್ನಿಂದ ಅಕ್ಷರಗಳಾಗಿ ಹೊರಹೊಮ್ಮಿದವು, ಹಾಗೆಯೇ ಫ್ರೇಮ್ನ ಅಂತ್ಯದವರೆಗೆ ಉಳಿದ ಅಕ್ಷರಗಳು (ಫರ್ಮ್ವೇರ್ ಫೈಲ್ ಅನ್ನು ಹೈಲೈಟ್ ಮಾಡಲಾಗಿದೆ):
fd 3e 02 01 fe ಚಿಹ್ನೆಗಳ ಅರ್ಥವೇನೆಂದರೆ, ವೈಯಕ್ತಿಕವಾಗಿ, ಇಲ್ಯಾ ಅವರಂತೆ ನನಗೆ ತಿಳಿದಿರಲಿಲ್ಲ.
ನಾನು ಈ ಕೆಳಗಿನ ಫ್ರೇಮ್ ಅನ್ನು ನೋಡಿದೆ (ಸೇವಾ ಮಾಹಿತಿಯನ್ನು ಇಲ್ಲಿ ತೆಗೆದುಹಾಕಲಾಗಿದೆ, ಫರ್ಮ್ವೇರ್ ಫೈಲ್ ಅನ್ನು ಹೈಲೈಟ್ ಮಾಡಲಾಗಿದೆ):
ಏನು ಸ್ಪಷ್ಟವಾಯಿತು? ಮೊದಲ ಎರಡು ಬೈಟ್ಗಳು ಕೆಲವು ರೀತಿಯ ಸ್ಥಿರವಾಗಿರುತ್ತವೆ. ಎಲ್ಲಾ ನಂತರದ ಬ್ಲಾಕ್ಗಳು ಇದನ್ನು ದೃಢಪಡಿಸಿದವು, ಆದರೆ ಪ್ರಸರಣ ಬ್ಲಾಕ್ನ ಅಂತ್ಯದ ಮೊದಲು:
ಈ ಫ್ರೇಮ್ ಕೂಡ ಮೂರ್ಖತನವನ್ನುಂಟುಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಸ್ಥಿರವು ಬದಲಾಗಿದೆ (ಹೈಲೈಟ್ ಮಾಡಲಾಗಿದೆ) ಮತ್ತು ವಿಚಿತ್ರವಾಗಿ ಸಾಕಷ್ಟು, ಫೈಲ್ನ ಭಾಗವಿತ್ತು. ಫೈಲ್ನ ವರ್ಗಾವಣೆಗೊಂಡ ಬೈಟ್ಗಳ ಗಾತ್ರವು 1024 ಬೈಟ್ಗಳನ್ನು ವರ್ಗಾಯಿಸಲಾಗಿದೆ ಎಂದು ತೋರಿಸಿದೆ. ಉಳಿದ ಬೈಟ್ಗಳ ಅರ್ಥವೇನೆಂದು ನನಗೆ ಮತ್ತೆ ತಿಳಿದಿರಲಿಲ್ಲ.
ಮೊದಲನೆಯದಾಗಿ, ಹಳೆಯ BBS ಅಡ್ಡಹೆಸರು, ನಾನು ಪ್ರಮಾಣಿತ ಪ್ರಸರಣ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇನೆ. ಯಾವುದೇ ಪ್ರೋಟೋಕಾಲ್ 1024 ಬೈಟ್ಗಳನ್ನು ರವಾನಿಸಿಲ್ಲ. ನಾನು ಹಾರ್ಡ್ವೇರ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ ಮತ್ತು 1K Xmodem ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನೋಡಿದೆ. ಇದು 1024 ಅನ್ನು ರವಾನಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು, ಆದರೆ ಒಂದು ಎಚ್ಚರಿಕೆಯೊಂದಿಗೆ: ಮೊದಲಿಗೆ ಕೇವಲ 128, ಮತ್ತು ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲದಿದ್ದರೆ ಮಾತ್ರ, ಪ್ರೋಟೋಕಾಲ್ ರವಾನೆಯಾಗುವ ಬೈಟ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿತು. ನಾನು ತಕ್ಷಣವೇ 1024 ಬೈಟ್ಗಳ ವರ್ಗಾವಣೆಯನ್ನು ಹೊಂದಿದ್ದೇನೆ. ನಾನು ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಎಕ್ಸ್-ಮೋಡೆಮ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ನಿರ್ಧರಿಸಿದೆ.
ಮೋಡೆಮ್ನ ಎರಡು ಮಾರ್ಪಾಡುಗಳಿದ್ದವು.
ಮೊದಲಿಗೆ, CRC8 ಬೆಂಬಲದೊಂದಿಗೆ XMODEM ಪ್ಯಾಕೇಜ್ ಫಾರ್ಮ್ಯಾಟ್ (ಮೂಲ XMODEM):
ಎರಡನೆಯದಾಗಿ, CRC16 ಬೆಂಬಲದೊಂದಿಗೆ XMODEM ಪ್ಯಾಕೆಟ್ ಸ್ವರೂಪ (XmodemCRC):
SOH, ಪ್ಯಾಕೇಜ್ ಸಂಖ್ಯೆ ಮತ್ತು CRC ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಉದ್ದವನ್ನು ಹೊರತುಪಡಿಸಿ ಇದು ಹೋಲುತ್ತದೆ.
ನಾನು ಎರಡನೇ ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಬ್ಲಾಕ್ನ ಪ್ರಾರಂಭವನ್ನು ನೋಡಿದೆ (ಮತ್ತು ಮತ್ತೆ ಫರ್ಮ್ವೇರ್ ಫೈಲ್ ಅನ್ನು ನೋಡಿದೆ, ಆದರೆ ಈಗಾಗಲೇ 1024 ಬೈಟ್ಗಳಿಂದ ಇಂಡೆಂಟ್ ಮಾಡಲಾಗಿದೆ):
ನಾನು ಪರಿಚಿತ ಹೆಡರ್ fd 3e 02 ಅನ್ನು ನೋಡಿದೆ, ಆದರೆ ಮುಂದಿನ ಎರಡು ಬೈಟ್ಗಳು ಈಗಾಗಲೇ ಬದಲಾಗಿದೆ: ಅದು 01 fe ಆಗಿತ್ತು ಮತ್ತು 02 fd ಆಯಿತು. ನಂತರ ಎರಡನೇ ಬ್ಲಾಕ್ ಅನ್ನು ಈಗ 02 ಎಂದು ನಾನು ಗಮನಿಸಿದೆ ಮತ್ತು ಹೀಗೆ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ: ನನ್ನ ಮುಂದೆ ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಬ್ಲಾಕ್ನ ಸಂಖ್ಯೆ ಇತ್ತು. ಮೊದಲ 1024 ಗೇರ್ 01, ಎರಡನೆಯದು 02, ಮೂರನೆಯದು 03 ಮತ್ತು ಹೀಗೆ (ಆದರೆ ಹೆಕ್ಸ್ನಲ್ಲಿ, ಸಹಜವಾಗಿ). ಆದರೆ fe ನಿಂದ fd ಗೆ ಬದಲಾವಣೆಯ ಅರ್ಥವೇನು? ಕಣ್ಣುಗಳು 1 ರಿಂದ ಕಡಿಮೆಯಾಗುವುದನ್ನು ಕಂಡವು, ಪ್ರೋಗ್ರಾಮರ್ಗಳು 0 ರಿಂದ ಎಣಿಕೆ ಮಾಡುತ್ತಾರೆ, 1 ಅಲ್ಲ ಎಂದು ಮೆದುಳು ನೆನಪಿಸಿತು. ಆದರೆ ಮೊದಲ ಬ್ಲಾಕ್ ಏಕೆ 1 ಆಗಿದೆ, ಮತ್ತು 0 ಅಲ್ಲ? ಈ ಪ್ರಶ್ನೆಗೆ ನಾನು ಇನ್ನೂ ಉತ್ತರವನ್ನು ಕಂಡುಕೊಂಡಿಲ್ಲ. ಆದರೆ ಎರಡನೇ ಬ್ಲಾಕ್ ಅನ್ನು ಹೇಗೆ ಎಣಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಎರಡನೇ ಬ್ಲಾಕ್ FF ಗಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ - (ಮೈನಸ್) ಮೊದಲ ಬ್ಲಾಕ್ನ ಸಂಖ್ಯೆ. ಹೀಗಾಗಿ, ಎರಡನೇ ಬ್ಲಾಕ್ ಅನ್ನು = 02 (FF-02) = 02 FD ಎಂದು ಗೊತ್ತುಪಡಿಸಲಾಗಿದೆ. ಡಂಪ್ನ ನಂತರದ ಓದುವಿಕೆ ನನ್ನ ಊಹೆಯನ್ನು ದೃಢಪಡಿಸಿತು.
ನಂತರ ಪ್ರಸರಣದ ಕೆಳಗಿನ ಚಿತ್ರವು ಹೊರಹೊಮ್ಮಲು ಪ್ರಾರಂಭಿಸಿತು:
ಪ್ರಸರಣದ ಪ್ರಾರಂಭ
fd 3e 02 - ಪ್ರಾರಂಭ
01 FE - ಪ್ರಸರಣ ಕೌಂಟರ್
ವರ್ಗಾವಣೆ (34 ಬ್ಲಾಕ್ಗಳು, 1024 ಬೈಟ್ಗಳನ್ನು ವರ್ಗಾಯಿಸಲಾಗಿದೆ)
fd 3e 1024 ಬೈಟ್ಗಳ ಡೇಟಾ (30 ಬೈಟ್ ಬ್ಲಾಕ್ಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ).
ಪ್ರಸರಣದ ಅಂತ್ಯ
fd 25
ಉಳಿದಿರುವ ಡೇಟಾವನ್ನು 1024 ಬೈಟ್ಗಳಿಗೆ ಜೋಡಿಸಬೇಕು.
ಬ್ಲಾಕ್ ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಎಂಡ್ ಫ್ರೇಮ್ ಹೇಗೆ ಕಾಣುತ್ತದೆ:
fd 25 - ಬ್ಲಾಕ್ ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸಲು ಸಂಕೇತ. ಮುಂದಿನ 2f 52 - ಗಾತ್ರದಲ್ಲಿ 1024 ಬೈಟ್ಗಳವರೆಗಿನ ಫೈಲ್ನ ಉಳಿದ ಭಾಗ. 2f 52, ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ನಿರ್ಣಯಿಸುವುದು, 16-ಬಿಟ್ CRC ಚೆಕ್ಸಮ್ ಆಗಿದೆ.
ಹಳೆಯ ಸಮಯದ ಸಲುವಾಗಿ, ನಾನು ಫೈಲ್ನಿಂದ 1024 ಬೈಟ್ಗಳನ್ನು ಎಳೆದ ಮತ್ತು 16-ಬಿಟ್ CRC ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು C ನಲ್ಲಿ ಮಾಡಿದ್ದೇನೆ. ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಇದು 16-ಬಿಟ್ CRC ಅಲ್ಲ ಎಂದು ತೋರಿಸಿದೆ. ಮತ್ತೆ ಮೂರ್ಖತನ - ಸುಮಾರು ಮೂರು ದಿನಗಳವರೆಗೆ. ಈ ಸಮಯದಲ್ಲಿ ನಾನು ಚೆಕ್ಸಮ್ ಅಲ್ಲದಿದ್ದರೆ ಅದು ಏನಾಗಬಹುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೆ. ಇಂಗ್ಲಿಷ್ ಭಾಷೆಯ ಸೈಟ್ಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡುವಾಗ, X-ಮೋಡೆಮ್ ತನ್ನದೇ ಆದ ಚೆಕ್ಸಮ್ ಲೆಕ್ಕಾಚಾರವನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ನಾನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ - CRC-CCITT (XModem). ಈ ಲೆಕ್ಕಾಚಾರದ ಯಾವುದೇ ಸಿ ಅನುಷ್ಠಾನಗಳು ನನಗೆ ಕಂಡುಬಂದಿಲ್ಲ, ಆದರೆ ಈ ಚೆಕ್ಸಮ್ ಅನ್ನು ಆನ್ಲೈನ್ನಲ್ಲಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಸೈಟ್ ಅನ್ನು ನಾನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ. ನನ್ನ ಫೈಲ್ನ 1024 ಬೈಟ್ಗಳನ್ನು ವೆಬ್ ಪುಟಕ್ಕೆ ವರ್ಗಾಯಿಸಿದ ನಂತರ, ಸೈಟ್ ನನಗೆ ಚೆಕ್ಸಮ್ ಅನ್ನು ತೋರಿಸಿದೆ ಅದು ಫೈಲ್ನಿಂದ ಚೆಕ್ಸಮ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.
ಹುರ್ರೇ! ಕೊನೆಯ ಒಗಟನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ, ಈಗ ನಾನು ನನ್ನ ಸ್ವಂತ ಫರ್ಮ್ವೇರ್ ಮಾಡಬೇಕಾಗಿದೆ. ಮುಂದೆ, ನಾನು ನನ್ನ ಜ್ಞಾನವನ್ನು (ಮತ್ತು ಅದು ನನ್ನ ತಲೆಯಲ್ಲಿ ಮಾತ್ರ ಉಳಿದಿದೆ) ಶಕ್ತಿಶಾಲಿ ಟೂಲ್ಕಿಟ್ ಪೈಥಾನ್ನೊಂದಿಗೆ ಪರಿಚಿತವಾಗಿರುವ ಇಲ್ಯಾಗೆ ರವಾನಿಸಿದೆ.
ಪ್ರೋಗ್ರಾಂ ರಚಿಸಲಾಗುತ್ತಿದೆ
ಇಲ್ಯಾ ಅಲೆಶಿನ್ ವರದಿ ಮಾಡಿದ್ದಾರೆ.
ಸೂಕ್ತವಾದ ಸೂಚನೆಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ನಾನು ತುಂಬಾ "ಸಂತೋಷದಿಂದ" ಇದ್ದೆ.
ಎಲ್ಲಿಂದ ಆರಂಭಿಸಬೇಕು? ಅದು ಸರಿ, ಮೊದಲಿನಿಂದಲೂ. USB ಪೋರ್ಟ್ನಿಂದ ಡಂಪ್ ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ.
USB-pcap ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ
ಸಾಧನವು ಸಂಪರ್ಕಗೊಂಡಿರುವ ಪೋರ್ಟ್ ಮತ್ತು ನಾವು ಡಂಪ್ ಅನ್ನು ಉಳಿಸುವ ಫೈಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.
ವಿಂಡೋಸ್ಗಾಗಿ ಸ್ಥಳೀಯ EZConfigScanning ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ ಯಂತ್ರಕ್ಕೆ ನಾವು ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತೇವೆ.
ಅದರಲ್ಲಿ ನಾವು ಸಾಧನಕ್ಕೆ ಆಜ್ಞೆಗಳನ್ನು ಕಳುಹಿಸುವ ಐಟಂ ಅನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ. ಆದರೆ ತಂಡಗಳ ಬಗ್ಗೆ ಏನು? ನಾನು ಅವುಗಳನ್ನು ಎಲ್ಲಿ ಪಡೆಯಬಹುದು?
ಪ್ರೋಗ್ರಾಂ ಪ್ರಾರಂಭವಾದಾಗ, ಉಪಕರಣಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪೋಲ್ ಮಾಡಲಾಗುತ್ತದೆ (ನಾವು ಇದನ್ನು ಸ್ವಲ್ಪ ನಂತರ ನೋಡುತ್ತೇವೆ). ಮತ್ತು ಅಧಿಕೃತ ಸಲಕರಣೆ ದಾಖಲೆಗಳಿಂದ ತರಬೇತಿ ಬಾರ್ಕೋಡ್ಗಳು ಇದ್ದವು. ಡೀಫಾಲ್ಟ್. ಇದು ನಮ್ಮ ತಂಡ.
ಅಗತ್ಯ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ. ವೈರ್ಶಾರ್ಕ್ ಮೂಲಕ dump.pcap ತೆರೆಯಿರಿ.
EZConfigScanning ಪ್ರಾರಂಭಿಸುವಾಗ ನಿರ್ಬಂಧಿಸಿ. ನೀವು ಗಮನ ಕೊಡಬೇಕಾದ ಸ್ಥಳಗಳನ್ನು ಕೆಂಪು ಬಣ್ಣದಲ್ಲಿ ಗುರುತಿಸಲಾಗಿದೆ.
ಮೊಟ್ಟಮೊದಲ ಬಾರಿಗೆ ಇದನ್ನೆಲ್ಲ ನೋಡಿ ಮನಸೋತಿದ್ದೆ. ಮುಂದೆ ಎಲ್ಲಿ ಅಗೆಯಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.
ಸ್ವಲ್ಪ ಬುದ್ದಿಮತ್ತೆ ಮತ್ತು-ಮತ್ತು-ಮತ್ತು... ಆಹಾ! ಡಂಪ್ನಲ್ಲಿ ಔಟ್ - ಆಗಿದೆ inಮತ್ತು in ಇದು ಔಟ್.
ನಾನು URB_INTERRUPT ಎಂದರೇನು ಎಂದು ಗೂಗಲ್ ಮಾಡಿದೆ. ಇದು ಡೇಟಾ ವರ್ಗಾವಣೆ ವಿಧಾನ ಎಂದು ನಾನು ಕಂಡುಕೊಂಡೆ. ಮತ್ತು ಅಂತಹ 4 ವಿಧಾನಗಳಿವೆ: ನಿಯಂತ್ರಣ, ಅಡಚಣೆ, ಐಸೊಕ್ರೊನಸ್, ಬೃಹತ್. ನೀವು ಅವರ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಬಹುದು.
ಮತ್ತು ಯುಎಸ್ಬಿ ಸಾಧನ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿರುವ ಎಂಡ್ಪಾಯಿಂಟ್ ವಿಳಾಸಗಳನ್ನು "lsusb -v" ಆಜ್ಞೆಯ ಮೂಲಕ ಅಥವಾ pyusb ಬಳಸಿ ಪಡೆಯಬಹುದು.
ಈಗ ನಾವು ಈ VID ಯೊಂದಿಗೆ ಎಲ್ಲಾ ಸಾಧನಗಳನ್ನು ಹುಡುಕಬೇಕಾಗಿದೆ. ನೀವು ನಿರ್ದಿಷ್ಟವಾಗಿ VID:PID ಮೂಲಕ ಹುಡುಕಬಹುದು.
ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಆದ್ದರಿಂದ, ನಾವು ಅಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ: P_INFO ಆಜ್ಞೆಗಳು. ಅಥವಾ DEFALT, ಕಮಾಂಡ್ಗಳನ್ನು ಎಲ್ಲಿ ಬರೆಯಬೇಕು ಎಂಡ್ಪಾಯಿಂಟ್=03 ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಎಂಡ್ಪಾಯಿಂಟ್=86 ಅನ್ನು ಎಲ್ಲಿ ಪಡೆಯಬೇಕು ಎಂದು ವಿಳಾಸಗಳು. ಆಜ್ಞೆಗಳನ್ನು ಹೆಕ್ಸ್ಗೆ ಪರಿವರ್ತಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ.
ನಾವು ಈಗಾಗಲೇ ಸಾಧನವನ್ನು ಕಂಡುಕೊಂಡಿರುವುದರಿಂದ, ಅದನ್ನು ಕರ್ನಲ್ನಿಂದ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸೋಣ...
ಮತ್ತು 0x03 ವಿಳಾಸದೊಂದಿಗೆ ಅಂತ್ಯಬಿಂದುವಿಗೆ ಬರೆಯಿರಿ,
... ತದನಂತರ ವಿಳಾಸ 0x86 ನೊಂದಿಗೆ ಅಂತ್ಯಬಿಂದುವಿನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಓದಿ.
ರಚನಾತ್ಮಕ ಉತ್ತರ:
P_INFOfmt: 1
mode: app
app-present: 1
boot-present: 1
hw-sn: 18072B44CA
hw-rev: 0x20
cbl: 4
app-sw-rev: CP000116BBA
boot-sw-rev: CP000014BAD
flash: 3
app-m_name: Voyager 1450g
boot-m_name: Voyager 1450g
app-p_name: 1450g
boot-p_name: 1450g
boot-time: 16:56:02
boot-date: Oct 16 2014
app-time: 08:49:30
app-date: Mar 25 2019
app-compat: 289
boot-compat: 288
csum: 0x6986
ನಾವು ಈ ಡೇಟಾವನ್ನು dump.pcap ನಲ್ಲಿ ನೋಡುತ್ತೇವೆ.
ಗ್ರೇಟ್! ಸಿಸ್ಟಮ್ ಬಾರ್ಕೋಡ್ಗಳನ್ನು ಹೆಕ್ಸ್ಗೆ ಪರಿವರ್ತಿಸಿ. ಅಷ್ಟೆ, ತರಬೇತಿ ಕಾರ್ಯವು ಸಿದ್ಧವಾಗಿದೆ.
ಫರ್ಮ್ವೇರ್ ಬಗ್ಗೆ ಏನು? ಎಲ್ಲವೂ ಒಂದೇ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ.
ಮಿನುಗುವ ಪ್ರಕ್ರಿಯೆಯ ಸಂಪೂರ್ಣ ಡಂಪ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡ ನಂತರ, ನಾವು ವ್ಯವಹರಿಸುತ್ತಿರುವುದನ್ನು ನಾವು ಸ್ಥೂಲವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. XMODEM ಕುರಿತು ಒಂದು ಲೇಖನ ಇಲ್ಲಿದೆ, ಈ ಸಂವಹನವು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ತುಂಬಾ ಸಹಾಯಕವಾಗಿದೆ, ಆದರೂ ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ:
ಡಂಪ್ ಅನ್ನು ನೋಡುವಾಗ, ಫ್ರೇಮ್ ಗಾತ್ರ 1024 ಮತ್ತು URB-ಡೇಟಾ ಗಾತ್ರ 64 ಎಂದು ನೀವು ನೋಡಬಹುದು.
ಆದ್ದರಿಂದ - 1024/64 - ನಾವು ಒಂದು ಬ್ಲಾಕ್ನಲ್ಲಿ 16 ಸಾಲುಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಫರ್ಮ್ವೇರ್ ಫೈಲ್ ಅನ್ನು ಒಂದು ಸಮಯದಲ್ಲಿ 1 ಅಕ್ಷರವನ್ನು ಓದಿ ಮತ್ತು ಬ್ಲಾಕ್ ಅನ್ನು ರೂಪಿಸುತ್ತೇವೆ. ವಿಶೇಷ ಅಕ್ಷರಗಳು fd1e3 + ಬ್ಲಾಕ್ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಬ್ಲಾಕ್ನಲ್ಲಿ 02 ಸಾಲನ್ನು ಪೂರಕಗೊಳಿಸುವುದು.
ಮುಂದಿನ 14 ಸಾಲುಗಳು fd25 + ನೊಂದಿಗೆ ಪೂರಕವಾಗಿದೆ, XMODEM.calc_crc() ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ನ ಚೆಕ್ಸಮ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ ("FF - 1" CSUM ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು) ಮತ್ತು ಕೊನೆಯ, 16 ನೇ ಸಾಲನ್ನು ಪೂರಕಗೊಳಿಸಲಾಗಿದೆ fd3e ಜೊತೆಗೆ.
ಅದು ಇಲ್ಲಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಫರ್ಮ್ವೇರ್ ಫೈಲ್ ಅನ್ನು ಓದಿ, ಬ್ಲಾಕ್ಗಳನ್ನು ಹಿಟ್ ಮಾಡಿ, ಕರ್ನಲ್ನಿಂದ ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತು ಅದನ್ನು ಸಾಧನಕ್ಕೆ ಕಳುಹಿಸಿ. ಆದರೆ ಅದು ಅಷ್ಟು ಸರಳವಲ್ಲ. ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಫರ್ಮ್ವೇರ್ ಮೋಡ್ಗೆ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
ಈ ತಂಡ ಎಲ್ಲಿಂದ ಬಂತು?? ಡಂಪ್ನಿಂದ.
ಆದರೆ 64 ಮಿತಿಯಿಂದಾಗಿ ನಾವು ಸ್ಕ್ಯಾನರ್ಗೆ ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ ಅನ್ನು ಕಳುಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ:
ಸರಿ, NEWAPP ಮಿನುಗುವ ಮೋಡ್ನಲ್ಲಿರುವ ಸ್ಕ್ಯಾನರ್ ಹೆಕ್ಸ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನೀವು ಪ್ರತಿ ಸಾಲಿನ bytes_array ಅನ್ನು ಭಾಷಾಂತರಿಸಬೇಕು
[253, 10, 22, 78, 44, 78, 69, 87, 65, 80, 80, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
ತದನಂತರ ಈ ಡೇಟಾವನ್ನು ಸ್ಕ್ಯಾನರ್ಗೆ ಕಳುಹಿಸಿ.
ನಾವು ಉತ್ತರವನ್ನು ಪಡೆಯುತ್ತೇವೆ:
[2, 1, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
ನೀವು XMODEM ಕುರಿತು ಲೇಖನವನ್ನು ಪರಿಶೀಲಿಸಿದರೆ, ಅದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ: ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ.
ಎಲ್ಲಾ ಬ್ಲಾಕ್ಗಳನ್ನು ವರ್ಗಾಯಿಸಿದ ನಂತರ, ನಾವು ವರ್ಗಾವಣೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತೇವೆ END_TRANSFER = 'xfdx01x04'.
ಸರಿ, ಈ ಬ್ಲಾಕ್ಗಳು ಸಾಮಾನ್ಯ ಜನರಿಗೆ ಯಾವುದೇ ಮಾಹಿತಿಯನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲವಾದ್ದರಿಂದ, ನಾವು ಫರ್ಮ್ವೇರ್ ಅನ್ನು ಹಿಡನ್ ಮೋಡ್ನಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ಮತ್ತು ಒಂದು ವೇಳೆ, ನಾವು tqdm ಮೂಲಕ ಪ್ರಗತಿ ಪಟ್ಟಿಯನ್ನು ಆಯೋಜಿಸುತ್ತೇವೆ.
ವಾಸ್ತವವಾಗಿ, ಇದು ಚಿಕ್ಕ ವಿಷಯಗಳ ವಿಷಯವಾಗಿದೆ. ಚೆಕ್ಔಟ್ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಧಾನಗೊಳಿಸದಂತೆ ಮತ್ತು ಲಾಗಿಂಗ್ ಅನ್ನು ಸೇರಿಸದಂತೆ, ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಸಮಯದಲ್ಲಿ ಸಾಮೂಹಿಕ ಪುನರಾವರ್ತನೆಗಾಗಿ ಸ್ಕ್ರಿಪ್ಟ್ಗಳಲ್ಲಿ ಪರಿಹಾರವನ್ನು ಸುತ್ತಿಕೊಳ್ಳುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ.
ಫಲಿತಾಂಶ
ನಮ್ಮ ತಲೆಯ ಮೇಲೆ ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಶ್ರಮ ಮತ್ತು ಕೂದಲನ್ನು ಕಳೆದ ನಂತರ, ನಮಗೆ ಅಗತ್ಯವಿರುವ ಪರಿಹಾರಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಾವು ಸಮರ್ಥರಾಗಿದ್ದೇವೆ ಮತ್ತು ಗಡುವನ್ನು ಸಹ ಪೂರೈಸಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸ್ಕ್ಯಾನರ್ಗಳನ್ನು ಈಗ ರಿಫ್ಲಾಶ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಕೇಂದ್ರೀಯವಾಗಿ ಮರು ತರಬೇತಿ ನೀಡಲಾಗುತ್ತದೆ, ನಾವು ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿಯಂತ್ರಿಸುತ್ತೇವೆ. ಕಂಪನಿಯು ಸಮಯ ಮತ್ತು ಹಣವನ್ನು ಉಳಿಸಿದೆ ಮತ್ತು ಈ ಪ್ರಕಾರದ ರಿವರ್ಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಉಪಕರಣಗಳಲ್ಲಿ ನಾವು ಅಮೂಲ್ಯವಾದ ಅನುಭವವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ.
ಮೂಲ: www.habr.com